From owner-freebsd-current@freebsd.org Sun Jun 25 01:11:10 2017 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 C1658DA9000 for ; Sun, 25 Jun 2017 01:11:10 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D9DC7E3FB for ; Sun, 25 Jun 2017 01:11:10 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5P18p7c058645 for ; Sat, 24 Jun 2017 18:08:51 -0700 (PDT) (envelope-from null@pozo.com) From: Manfred Antar Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Current amd64 new error or warning from today's current with ruby r320323 Message-Id: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> Date: Sat, 24 Jun 2017 18:08:50 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-96.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5P18p7c058645 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 01:11:10 -0000 New world and kernel r320323 I get a new error or message when using ruby: /usr/local/sbin/portupgrade -av
: warning: pthread_create failed for timer: Resource temporarily unav= ailable, scheduling broken everything works just this message when using ruby. I recompiled ruby , sti= ll same message /usr/local/bin/ruby -v
: warning: pthread_create failed for timer: Resource temporarily unav= ailable, scheduling broken ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] Not sure what=E2=80=99s changed, I noticed some commits to vm stuff, maybe = thats it. Manfred --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 01:24:04 2017 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 9B75ADA961C for ; Sun, 25 Jun 2017 01:24:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 326147EB47 for ; Sun, 25 Jun 2017 01:24:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5P1NxJa075225 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 04:23:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5P1NxJa075225 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5P1NxkX075224; Sun, 25 Jun 2017 04:23:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 04:23:59 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625012359.GS3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 01:24:04 -0000 On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > New world and kernel r320323 > I get a new error or message when using ruby: > > > /usr/local/sbin/portupgrade -av >
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > everything works just this message when using ruby. I recompiled ruby , still same message > > /usr/local/bin/ruby -v >
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. ktrace your failing ruby invocation, then post output of kdump -H somewhere. From owner-freebsd-current@freebsd.org Sun Jun 25 01:50:04 2017 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 74FAAD86165 for ; Sun, 25 Jun 2017 01:50:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5256E7F7B3 for ; Sun, 25 Jun 2017 01:50:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5P1m3EO050817; Sat, 24 Jun 2017 18:48:03 -0700 (PDT) (envelope-from null@pozo.com) From: Manfred Antar Message-Id: <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Date: Sat, 24 Jun 2017 18:48:03 -0700 In-Reply-To: <20170625012359.GS3437@kib.kiev.ua> Cc: FreeBSD Current To: Konstantin Belousov References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5P1m3EO050817 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 01:50:04 -0000 > On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wr= ote: >=20 > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: >> New world and kernel r320323 >> I get a new error or message when using ruby: >>=20 >>=20 >> /usr/local/sbin/portupgrade -av >>
: warning: pthread_create failed for timer: Resource temporarily u= navailable, scheduling broken >>=20 >> everything works just this message when using ruby. I recompiled ruby , = still same message >>=20 >> /usr/local/bin/ruby -v >>
: warning: pthread_create failed for timer: Resource temporarily u= navailable, scheduling broken >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] >>=20 >> Not sure what???s changed, I noticed some commits to vm stuff, maybe tha= ts it. >=20 > ktrace your failing ruby invocation, then post output of kdump -H somewhe= re. >=20 Ok not sure if this is right , but this is what i did: (tmp)4637}ktrace /usr/local/bin/ruby -v
: warning: pthread_create failed for timer: Resource temporarily unav= ailable, scheduling broken ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt you can get kdump.txt at: http://www.pozo.com/kernel/kdump .txt It=E2=80=99s not failing, I don=E2=80=99t think , I can do portupgrade and = it works fine. I just get this new message --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 02:04:47 2017 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 BEFBAD865B8 for ; Sun, 25 Jun 2017 02:04:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 52E557FF21 for ; Sun, 25 Jun 2017 02:04:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5P24gM8084073 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 05:04:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5P24gM8084073 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5P24f8B084072; Sun, 25 Jun 2017 05:04:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 05:04:41 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625020441.GT3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 02:04:47 -0000 On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > > > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > >> New world and kernel r320323 > >> I get a new error or message when using ruby: > >> > >> > >> /usr/local/sbin/portupgrade -av > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >> > >> everything works just this message when using ruby. I recompiled ruby , still same message > >> > >> /usr/local/bin/ruby -v > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > >> > >> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > > > ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > > > Ok not sure if this is right , but this is what i did: > > (tmp)4637}ktrace /usr/local/bin/ruby -v >
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > you can get kdump.txt at: > > http://www.pozo.com/kernel/kdump .txt > > It???s not failing, I don???t think , I can do portupgrade and it works fine. > I just get this new message I see what is going on, but it is somewhat strange that it happens. Do you run ruby in a jail with old (say, stable/10) libthr ? Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in your environment ? Anyway, the rework of the stack grow indeed have incompatibility with the old (pre-11) libthr, which tries to split main thread stack into smaller stacks for the new threads. New stack grow code was specifically designed to prevent this. Some hack would be needed there, to allow reuse of the main stack gap. From owner-freebsd-current@freebsd.org Sun Jun 25 02:10:09 2017 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 55E44D8678E for ; Sun, 25 Jun 2017 02:10:09 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 31EE98009E for ; Sun, 25 Jun 2017 02:10:08 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5P28SHo063458; Sat, 24 Jun 2017 19:08:28 -0700 (PDT) (envelope-from null@pozo.com) From: Manfred Antar Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Date: Sat, 24 Jun 2017 19:08:28 -0700 In-Reply-To: <20170625015504.GX1467@albert.catwhisker.org> Cc: FreeBSD Current To: David Wolfskill References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625015504.GX1467@albert.catwhisker.org> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5P28SHo063458 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 02:10:09 -0000 > On Jun 24, 2017, at 6:55 PM, David Wolfskill wrote: >=20 > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: >> ...=20 >>> ktrace your failing ruby invocation, then post output of kdump -H somew= here. >>>=20 >>=20 >> Ok not sure if this is right , but this is what i did: >>=20 >> (tmp)4637}ktrace /usr/local/bin/ruby -v >=20 > You might want to re-do that, specifying the "-di" flags to ktrace (if > the output fails to include activities from child processes, and tracing > those is of interest). Ok did: ktrace -di /usr/local/bin/ruby -v kdump -H -f ./ktrace.out >kdump-new.txt File is at : http://www.pozo.com/kernel/kdump-new.txt smaller than the first one. Manfred --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 02:20:04 2017 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 A7C52D86AB4 for ; Sun, 25 Jun 2017 02:20:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86528804B3 for ; Sun, 25 Jun 2017 02:20:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5P2JPc8065173; Sat, 24 Jun 2017 19:19:25 -0700 (PDT) (envelope-from null@pozo.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 From: Manfred Antar In-Reply-To: <20170625020441.GT3437@kib.kiev.ua> Date: Sat, 24 Jun 2017 19:19:25 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-102.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD,TW_LR,TW_RW,TW_WX,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5P2JPc8065173 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 02:20:04 -0000 > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wr= ote: >=20 > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: >>=20 >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov = wrote: >>>=20 >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: >>>> New world and kernel r320323 >>>> I get a new error or message when using ruby: >>>>=20 >>>>=20 >>>> /usr/local/sbin/portupgrade -av >>>>
: warning: pthread_create failed for timer: Resource temporarily= unavailable, scheduling broken >>>>=20 >>>> everything works just this message when using ruby. I recompiled ruby = , still same message >>>>=20 >>>> /usr/local/bin/ruby -v >>>>
: warning: pthread_create failed for timer: Resource temporarily= unavailable, scheduling broken >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] >>>>=20 >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe t= hats it. >>>=20 >>> ktrace your failing ruby invocation, then post output of kdump -H somew= here. >>>=20 >>=20 >> Ok not sure if this is right , but this is what i did: >>=20 >> (tmp)4637}ktrace /usr/local/bin/ruby -v >>
: warning: pthread_create failed for timer: Resource temporarily u= navailable, scheduling broken >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] >>=20 >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt >>=20 >> you can get kdump.txt at: >>=20 >> http://www.pozo.com/kernel/kdump .txt >>=20 >> It???s not failing, I don???t think , I can do portupgrade and it works = fine. >> I just get this new message >=20 > I see what is going on, but it is somewhat strange that it happens. >=20 > Do you run ruby in a jail with old (say, stable/10) libthr ? > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > your environment ? >=20 > Anyway, the rework of the stack grow indeed have incompatibility with the > old (pre-11) libthr, which tries to split main thread stack into smaller > stacks for the new threads. New stack grow code was specifically designed > to prevent this. Some hack would be needed there, to allow reuse of > the main stack gap. >=20 Not running any jails all libraries are current as of today locate libthr. |xargs ls -l -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../= lib/libthr.so.3 ldd /usr/local/bin/ruby -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so= .2 -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8= .0.1 /usr/local/bin/ruby: libruby23.so.23 =3D> /usr/local/lib/libruby23.so.23 (0x800a00000) libelf.so.2 =3D> /lib/libelf.so.2 (0x800e9d000) libunwind.so.8 =3D> /usr/local/lib/libunwind.so.8 (0x8010b5000) libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x8012ce000) libprocstat.so.1 =3D> /usr/lib/libprocstat.so.1 (0x8014d1000) libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x8016db000) libm.so.5 =3D> /lib/libm.so.5 (0x8018f9000) libthr.so.3 =3D> /lib/libthr.so.3 (0x801b26000) libc.so.7 =3D> /lib/libc.so.7 (0x801d4e000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x802335000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x80254b000) libkvm.so.7 =3D> /lib/libkvm.so.7 (0x802774000) libutil.so.9 =3D> /lib/libutil.so.9 (0x802982000) no LIBPTHREAD_SPLITSTACK_MAIN set anywhere This is a fresh buildworld - installworld from noon today California time. here are env in make.conf: DEFAULT_VERSIONS=3D mysql=3D5.7 apache=3D2.4 python2=3D2.7 python3=3D3.4 ru= by=3D2.3 perl5=3D5.24 php=3D5.6 tcltk=3D8.6 samba=3D4.4 ssl=3Dbase ncurses= =3Dbase MALLOC_PRODUCTION=3Dyes WITH_BDB_VERSION=3D5 env in src.conf: WITHOUT_DYNAMICROOT=3Dyes=20 WITHOUT_UNBOUND=3Dyes WITHOUT_CASPER=3Dyes WITHOUT_CAPSICUM=3Dyes WITHOUT_DMAGENT=3Dyes WITHOUT_PROFILE=3Dyes WITHOUT_TESTS=3Dyes WITHOUT_KERNEL_SYMBOLS=3Dyes WITHOUT_DEBUG_FILES=3D1 WITHOUT_LIB32=3Dyes INSTALL_NODEBUG=3Dyes # Don't die on warnings NO_WERROR=3D WERROR=3D KERNCONF=3Dpozo WITH_CCACHE_BUILD=3Dyes Manfred --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 10:54:25 2017 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 A5018D8E73E for ; Sun, 25 Jun 2017 10:54:25 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward10j.cmail.yandex.net (forward10j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6166966DC2 for ; Sun, 25 Jun 2017 10:54:25 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [IPv6:2a02:6b8:0:2519::121]) by forward10j.cmail.yandex.net (Yandex) with ESMTP id C844E213E9 for ; Sun, 25 Jun 2017 13:54:20 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id ADC1D63C0EE1 for ; Sun, 25 Jun 2017 13:54:20 +0300 (MSK) Received: by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id TMsj1u8386-sJxSlHRH; Sun, 25 Jun 2017 13:54:19 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1498388059; bh=dB+Xz0Fx0/+WHesckwNYgfbGooaTCGyPRkeIsb9wlCk=; h=To:From:Subject:Message-ID:Date; b=p6Zr2ZE9XR+LZPp3giesH7MM3lHMHsAaoZo7x6bpOS874EhQo6fPvsdMoewosfSCa isYLsHwsLnd8BbVtbBBUtiAxtxBjg1OmQ6vp52h8mqcnvEElqHMVejqQOu1U3ODILK bYvY66d9RuVY6B6eOGP21RsnxoYcsDUjnOwkNpbU= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0 To: freebsd-current@FreeBSD.org From: Boris Samorodov Subject: r320307 -> r320324: kernel does not load Message-ID: Date: Sun, 25 Jun 2017 13:54:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 10:54:25 -0000 Hi All, I use self-built base packages for system updates. The jump from r320307 to r320324 leads to fatal trap 12 at the very beginning: https://goo.gl/Pgujga (sorry for the poor photo quality) Revert to r320307, and the system boots fine. -- WBR, bsam From owner-freebsd-current@freebsd.org Sun Jun 25 11:11:27 2017 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 8B298D8EC79 for ; Sun, 25 Jun 2017 11:11:27 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2m.cmail.yandex.net (forward2m.cmail.yandex.net [IPv6:2a02:6b8:b030::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48A1F67304; Sun, 25 Jun 2017 11:11:27 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward2m.cmail.yandex.net (Yandex) with ESMTP id 34B7120F0C; Sun, 25 Jun 2017 14:11:24 +0300 (MSK) Received: from smtp3o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 8486329408AC; Sun, 25 Jun 2017 14:11:22 +0300 (MSK) Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id yYo5lrWCOp-BMgWCQTv; Sun, 25 Jun 2017 14:11:22 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1498389082; bh=x4jY+9wSIIquEbnDTQR4u1defygbithU/HhuSIyNsRU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=J7y6BcM4kzmQrso/6QB7/l/KXpL5/LrDff8u6t9nCh3OrdAOFnyWzrDEQ4KN/e95/ 9Rd86BAZCZCgtRjRN6ocyHoOxp6tCikmEH5jnqLV7FxUegbKy6ED/sRiORyDKdcG3d n2dehvm+rNIgTrfsI1EjpTdsAm1qVD7ntD2CJW4c= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: r320307 -> r320324: kernel does not load To: freebsd-current@freebsd.org, kib@FreeBSD.org References: From: Boris Samorodov Message-ID: <512eb5ee-65d1-2b9e-689c-7a54d00bad10@passap.ru> Date: Sun, 25 Jun 2017 14:11:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 11:11:27 -0000 (cc: kib@) Hi Kostik, FYI: I've looked though last source changes and it looks like your commit(s) may be related. 25.06.2017 13:54, Boris Samorodov пишет: > Hi All, > > I use self-built base packages for system updates. The jump from > r320307 to r320324 leads to fatal trap 12 at the very beginning: > https://goo.gl/Pgujga (sorry for the poor photo quality) > > Revert to r320307, and the system boots fine. -- WBR, bsam From owner-freebsd-current@freebsd.org Sun Jun 25 12:07:33 2017 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 2B321D90453 for ; Sun, 25 Jun 2017 12:07:33 +0000 (UTC) (envelope-from david@catwhisker.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 1335C68E5B for ; Sun, 25 Jun 2017 12:07:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0F4AAD90452; Sun, 25 Jun 2017 12:07:33 +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 0D2D7D90451 for ; Sun, 25 Jun 2017 12:07:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 C4FD668E5A for ; Sun, 25 Jun 2017 12:07:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5PC7VaD002325 for ; Sun, 25 Jun 2017 12:07:31 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5PC7Vbg002324 for current@freebsd.org; Sun, 25 Jun 2017 05:07:31 -0700 (PDT) (envelope-from david) Date: Sun, 25 Jun 2017 05:07:31 -0700 From: David Wolfskill To: current@freebsd.org Subject: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625120731.GE1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9l24NVCWtSuIVIod" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 12:07:33 -0000 --9l24NVCWtSuIVIod Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Both on laptop and build machine; fortunately for me, the latter has a serial console, so: ______ ____ _____ _____ =20 | ____| | _ \ / ____| __ \=20 | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/ ``` ` s` `.....---.......--.``` -/ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DWelcome to FreeBSD=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ +o .--` /y:` +. | | yo`:. :o `+- | 1. Boot Multi User [Enter] | y/ -/` -o/ | 2. Boot [S]ingle User | .- ::/sy+:. | 3. [Esc]ape to loader prompt | / `-- / | 4. Reboot | `: :` | | `: :` | Options: | / / | 5. [K]ernel: kernel (1 of 2) | .- -. | 6. Configure Boot [O]ptions... | -- -. | | `:` `:` | | .-- `--. | | .---.....----.=20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ =20 /boot/kernel/kernel text=3D0x14dea68 data=3D0x146b38+0x567b68 syms=3D[0x8+0= x16cae8+0x8+0x186331] /boot/entropy size=3D0x1000 /boot/kernel/filemon.ko size 0xa128 at 0x2282000 loading required module 'kernel' module 'kernel' exists but with wrong version Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Table 'FACP' at 0xde3c1b98 Table 'APIC' at 0xde3c1ca8 APIC: Found table at 0xde3c1ca8 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 4: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 1 ACPI ID 5: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 6: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 7: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 8: enabled SMP: Added CPU 7 (AP) Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #385 r320324M/320326:1200035: Sun Jun 25 04:51:08 PDT= 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM = 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xde3c1b98 Table 'APIC' at 0xde3c1ca8 Table 'FPDT' at 0xde3c1d40 Table 'ASF!' at 0xde3c1d88 Table 'SLIC' at 0xde3c1e30 Table 'SSDT' at 0xde3c1fa8 Table 'SSDT' at 0xde3c24e8 Table 'MCFG' at 0xde3c2fc0 Table 'HPET' at 0xde3c3000 Table 'SSDT' at 0xde3c3038 Table 'SSDT' at 0xde3c33a8 Table 'MSDM' at 0xde3c6688 Table 'DMAR' at 0xde3c66e0 ACPI: No SRAT table found kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x10000000020 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80d585a4 stack pointer =3D 0x28:0xffffffff82290a30 frame pointer =3D 0x28:0xffffffff82290a60 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 () [ thread pid 0 tid 0 ] Stopped at vm_map_lookup_entry+0x24: cmpq %r15,0x20(%rbx) db> bt Tracing pid 0 tid 0 td 0xffffffff81e9e860 vm_map_lookup_entry() at vm_map_lookup_entry+0x24/frame 0xffffffff82290a60 vm_map_insert() at vm_map_insert+0x10b/frame 0xffffffff82290b00 kmem_init() at kmem_init+0x72/frame 0xffffffff82290b30 vm_mem_init() at vm_mem_init+0x46/frame 0xffffffff82290b50 mi_startup() at mi_startup+0x9c/frame 0xffffffff82290b70 btext() at btext+0x2c db>=20 (The laptop seems to have repeated the: loading required module 'kernel' module 'kernel' exists but with wrong version sequence a few times, based on the video I got of it.) The "saving grace" is that the panic happens before the file systems are mounted.... :-} Unloading the (r320324) kernel and loading the r320307 kernel succeeds (at least enough to mount file systems). Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --9l24NVCWtSuIVIod Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZT6eDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X9nwIALErF/L/2fOlY7/LBUm74UDF qHmv9LWEa3Q/fpMFgP2ebv38VamVidW+rRSQzfh9D5IupK3+HNs8tC5ZQtOSoWwd gw+1DT4yeJKPNvmbdQJyUXU3e2z1sup81qOz1PrNPqmnPJuCJ3UuVX2thq/yRRaB 0eJ1zAjGYBlpiCsSgd8mm040nDuEO83Sfch3DgyYWF2DLfgtGSA/VfW2KqwW2Gt2 29U7raE8KHdNPcTxVSggqw8goP+ohggPUbtECykVUQBGZ2G7oVQ15spblwbkK77/ Kk1IgVxBRA7ON9/J7WmgM71dP9ShlDTwsv21C7kKBUiH+/+9J7DeRgj88Vi+RQk= =kTHF -----END PGP SIGNATURE----- --9l24NVCWtSuIVIod-- From owner-freebsd-current@freebsd.org Sun Jun 25 12:32:39 2017 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 07A8FD90B6D for ; Sun, 25 Jun 2017 12:32:39 +0000 (UTC) (envelope-from kostikbel@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 E24FC6A81C for ; Sun, 25 Jun 2017 12:32:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DE903D90B6C; Sun, 25 Jun 2017 12:32:38 +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 DE0EAD90B6B for ; Sun, 25 Jun 2017 12:32:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 73E0F6A81B for ; Sun, 25 Jun 2017 12:32:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PCWQtL021610 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 15:32:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PCWQtL021610 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PCWQwo021609; Sun, 25 Jun 2017 15:32:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 15:32:26 +0300 From: Konstantin Belousov To: Boris Samorodov , David Wolfskill , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625123226.GV3437@kib.kiev.ua> References: <20170625120731.GE1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170625120731.GE1241@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 12:32:39 -0000 On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10000000020 This is clearly an impossible address. Did you built the kernel with NO_CLEAN ? If yes, try the full build, perhaps even after removing all previous kernel objects. The layout of the struct vm_map_entry was changed, the faulted address is somewhat consistent with ABI mismatch. > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80d585a4 > stack pointer = 0x28:0xffffffff82290a30 > frame pointer = 0x28:0xffffffff82290a60 > 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 vm_map_lookup_entry+0x24: cmpq %r15,0x20(%rbx) > db> bt > Tracing pid 0 tid 0 td 0xffffffff81e9e860 > vm_map_lookup_entry() at vm_map_lookup_entry+0x24/frame 0xffffffff82290a60 > vm_map_insert() at vm_map_insert+0x10b/frame 0xffffffff82290b00 > kmem_init() at kmem_init+0x72/frame 0xffffffff82290b30 > vm_mem_init() at vm_mem_init+0x46/frame 0xffffffff82290b50 > mi_startup() at mi_startup+0x9c/frame 0xffffffff82290b70 > btext() at btext+0x2c > db> > > > (The laptop seems to have repeated the: > > loading required module 'kernel' > module 'kernel' exists but with wrong version > > sequence a few times, based on the video I got of it.) > > > The "saving grace" is that the panic happens before the file systems > are mounted.... :-} > > Unloading the (r320324) kernel and loading the r320307 kernel > succeeds (at least enough to mount file systems). > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Trump (et al.): Hiding information doesn't prove its falsity. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Sun Jun 25 12:47:50 2017 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 9F202D90E25 for ; Sun, 25 Jun 2017 12:47:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 85B6B6AC44 for ; Sun, 25 Jun 2017 12:47:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 81C27D90E24; Sun, 25 Jun 2017 12:47:50 +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 7F5C0D90E23 for ; Sun, 25 Jun 2017 12:47:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 27D9D6AC43 for ; Sun, 25 Jun 2017 12:47:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5PClmBM003537; Sun, 25 Jun 2017 12:47:48 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5PClm4U003536; Sun, 25 Jun 2017 05:47:48 -0700 (PDT) (envelope-from david) Date: Sun, 25 Jun 2017 05:47:48 -0700 From: David Wolfskill To: Konstantin Belousov Cc: Boris Samorodov , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625124748.GT1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , Boris Samorodov , current@freebsd.org References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rBVNTu5JXDAWzN2S" Content-Disposition: inline In-Reply-To: <20170625123226.GV3437@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 12:47:50 -0000 --rBVNTu5JXDAWzN2S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x10000000020 > This is clearly an impossible address. >=20 > Did you built the kernel with NO_CLEAN ? If yes, try the full build, > perhaps even after removing all previous kernel objects. No; I stopped using NO_CLEAN by 12 March 2016, in favor of filemon and WITH_FAST_DEPEND. I have been doing daily builds & smoke-tests of head/amd64 since then. (Well, I was also doing them before then, as well....) > The layout of the struct vm_map_entry was changed, the faulted address > is somewhat consistent with ABI mismatch. Kinky. :-} > .... Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --rBVNTu5JXDAWzN2S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZT7D0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X/84H/3P/vu4lqAXmtLeXEafFtxjP hx0wd2uFSLMGw8eNVjN9xt6WqCeH1efKz+3vtwdYwb7tMfkUBIXoDLr0B/1EEa8A KTgFwP3WsI4HsmEkNc9M6r9vdLgZh8IH9BGLpHo5lGWi70KK4VY/WyO4jTcxkBmO 1nM35Qb9AWPGdlLEflqZ4CqEw4+C/lTMODFYQslgaHCSYXP9aXInHHbijM/oyIN5 7TOWrwcyhTSZtXVC3Wpxo15i9mXoXa1uMhuxfbPVCwQcMVQNyXtA9a0ACOW8OMp5 WzQUeWQ4l8/exB8OZk+Wc0QyTKBbpDaFIe4zGRHr0ioexCIvSYCHfkBUt+A3qqU= =SCNn -----END PGP SIGNATURE----- --rBVNTu5JXDAWzN2S-- From owner-freebsd-current@freebsd.org Sun Jun 25 12:52:33 2017 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 03562D910AF for ; Sun, 25 Jun 2017 12:52:33 +0000 (UTC) (envelope-from kostikbel@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 DD19B6E06A for ; Sun, 25 Jun 2017 12:52:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DC17CD910AE; Sun, 25 Jun 2017 12:52:32 +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 DB9AAD910AD for ; Sun, 25 Jun 2017 12:52:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 7170F6E068 for ; Sun, 25 Jun 2017 12:52:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PCqNc2026025 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 15:52:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PCqNc2026025 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PCqNT9026024; Sun, 25 Jun 2017 15:52:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 15:52:23 +0300 From: Konstantin Belousov To: David Wolfskill , Boris Samorodov , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625125223.GX3437@kib.kiev.ua> References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> <20170625124748.GT1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170625124748.GT1241@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 12:52:33 -0000 On Sun, Jun 25, 2017 at 05:47:48AM -0700, David Wolfskill wrote: > On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote: > > On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x10000000020 > > This is clearly an impossible address. > > > > Did you built the kernel with NO_CLEAN ? If yes, try the full build, > > perhaps even after removing all previous kernel objects. > > No; I stopped using NO_CLEAN by 12 March 2016, in favor of filemon and > WITH_FAST_DEPEND. I have been doing daily builds & smoke-tests of > head/amd64 since then. (Well, I was also doing them before then, > as well....) > > > The layout of the struct vm_map_entry was changed, the faulted address > > is somewhat consistent with ABI mismatch. > > Kinky. :-} Do you use any third-party modules ? From owner-freebsd-current@freebsd.org Sun Jun 25 13:05:23 2017 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 E0FD5D912F8 for ; Sun, 25 Jun 2017 13:05:23 +0000 (UTC) (envelope-from david@catwhisker.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 C72516E458 for ; Sun, 25 Jun 2017 13:05:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id C3634D912F7; Sun, 25 Jun 2017 13:05:23 +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 C2FCFD912F6 for ; Sun, 25 Jun 2017 13:05:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 758976E457 for ; Sun, 25 Jun 2017 13:05:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5PD5MFL003646; Sun, 25 Jun 2017 13:05:22 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5PD5LlN003645; Sun, 25 Jun 2017 06:05:21 -0700 (PDT) (envelope-from david) Date: Sun, 25 Jun 2017 06:05:21 -0700 From: David Wolfskill To: Konstantin Belousov Cc: Boris Samorodov , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625130521.GU1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , Boris Samorodov , current@freebsd.org References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> <20170625124748.GT1241@albert.catwhisker.org> <20170625125223.GX3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6wUvnnXCCq76soZt" Content-Disposition: inline In-Reply-To: <20170625125223.GX3437@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 13:05:24 -0000 --6wUvnnXCCq76soZt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote: > ... > > > The layout of the struct vm_map_entry was changed, the faulted address > > > is somewhat consistent with ABI mismatch. > >=20 > > Kinky. :-} > Do you use any third-party modules ? On the laptop, I use x11/nvidia-driver-340; on the build machine, no. I think we should focus on the build machine -- it runs a GENERIC kernel without ports (3rd-party) modules. Here are a few relevant files: # cat /etc/src.conf WITHOUT_DEBUG_FILES=3D1 WITH_ELFCOPY_AS_OBJCOPY=3D1 # #cat /etc/src-env.conf=20 WITH_META_MODE=3Dyes # #cat /etc/make.conf SENDMAIL_MC=3D/etc/mail/client.mc # added by use.perl 2009-11-07 21:19:31 PERL_VERSION=3D5.12.1 WITH_PKGNG=3D YES # #cat /boot/loader.conf=20 console=3D"comconsole,vidconsole" # A comma separated list of console(s) comconsole_pcidev=3D"4:0:0" comconsole_speed=3D"9600" filemon_load=3D"YES" #=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6wUvnnXCCq76soZt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZT7URXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XjcAH/24+RYalk3q09SpTDGZmAjk0 LLfnzpVRgh2vyDzcfXBSffP8nRgodk8Tv9t6nDKWXWxkyvSkE1mzM6K37+09zLkt suInAbnQ8UJmO0qO4lyu3Sook1OqQa2RLHG3AmKHrK7TPaQMM745HjybQ/8Z/Eb5 GWtUoK7ywmp6HaavIWANCZu051UD92NTS5i6GLoBX1Pd4EiNAqjsl2ZQHxeMg0Py 4Wu4PhxV8CsrOng9GsjVODfLtwZdMGJMzDFvA4YwLppuCjWR3y238XG1N+xLeNbm t73mEWBJ/ZzfEmOKbaiLcTXfPQBpqQyaJghHhs65yF7DtYE9jdX9l2K8San6s7k= =NNI5 -----END PGP SIGNATURE----- --6wUvnnXCCq76soZt-- From owner-freebsd-current@freebsd.org Sun Jun 25 13:21:26 2017 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 E83EED915B0 for ; Sun, 25 Jun 2017 13:21:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CD6986EA92 for ; Sun, 25 Jun 2017 13:21:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C90E1D915AF; Sun, 25 Jun 2017 13:21:26 +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 C63D2D915AE for ; Sun, 25 Jun 2017 13:21:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4E1496EA90 for ; Sun, 25 Jun 2017 13:21:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PDLGVX032634 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 16:21:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PDLGVX032634 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PDLG1C032633; Sun, 25 Jun 2017 16:21:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 16:21:16 +0300 From: Konstantin Belousov To: David Wolfskill , Boris Samorodov , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625132116.GY3437@kib.kiev.ua> References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> <20170625124748.GT1241@albert.catwhisker.org> <20170625125223.GX3437@kib.kiev.ua> <20170625130521.GU1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170625130521.GU1241@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 13:21:27 -0000 On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote: > On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote: > > ... > > > > The layout of the struct vm_map_entry was changed, the faulted address > > > > is somewhat consistent with ABI mismatch. > > > > > > Kinky. :-} > > Do you use any third-party modules ? > > On the laptop, I use x11/nvidia-driver-340; on the build machine, no. > > I think we should focus on the build machine -- it runs a GENERIC kernel > without ports (3rd-party) modules. Ok. > > #cat /etc/src-env.conf > WITH_META_MODE=yes So can you _remove_ all kernel object files and rebuild anew with the clean build dir, please ? From owner-freebsd-current@freebsd.org Sun Jun 25 13:41:41 2017 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 7FCBDD91E1D for ; Sun, 25 Jun 2017 13:41:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 0C2E76F450 for ; Sun, 25 Jun 2017 13:41:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PDfYQd037071 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 16:41:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PDfYQd037071 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PDfY6Q037070; Sun, 25 Jun 2017 16:41:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 16:41:34 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625134133.GA3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 13:41:41 -0000 On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wrote: > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > >> > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > >>> > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > >>>> New world and kernel r320323 > >>>> I get a new error or message when using ruby: > >>>> > >>>> > >>>> /usr/local/sbin/portupgrade -av > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >>>> > >>>> everything works just this message when using ruby. I recompiled ruby , still same message > >>>> > >>>> /usr/local/bin/ruby -v > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > >>>> > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > >>> > >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. > >>> > >> > >> Ok not sure if this is right , but this is what i did: > >> > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > >> > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > >> > >> you can get kdump.txt at: > >> > >> http://www.pozo.com/kernel/kdump .txt > >> > >> It???s not failing, I don???t think , I can do portupgrade and it works fine. > >> I just get this new message > > > > I see what is going on, but it is somewhat strange that it happens. > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > your environment ? > > > > Anyway, the rework of the stack grow indeed have incompatibility with the > > old (pre-11) libthr, which tries to split main thread stack into smaller > > stacks for the new threads. New stack grow code was specifically designed > > to prevent this. Some hack would be needed there, to allow reuse of > > the main stack gap. > > > > Not running any jails > all libraries are current as of today > locate libthr. |xargs ls -l > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > ldd /usr/local/bin/ruby > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2 > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1 > > /usr/local/bin/ruby: > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a00000) > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) > libm.so.5 => /lib/libm.so.5 (0x8018f9000) > libthr.so.3 => /lib/libthr.so.3 (0x801b26000) > libc.so.7 => /lib/libc.so.7 (0x801d4e000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000) > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000) > libutil.so.9 => /lib/libutil.so.9 (0x802982000) > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere > > This is a fresh buildworld - installworld from noon today California time. > > here are env in make.conf: > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base > MALLOC_PRODUCTION=yes > WITH_BDB_VERSION=5 > > env in src.conf: > WITHOUT_DYNAMICROOT=yes > WITHOUT_UNBOUND=yes > WITHOUT_CASPER=yes > WITHOUT_CAPSICUM=yes > WITHOUT_DMAGENT=yes > WITHOUT_PROFILE=yes > WITHOUT_TESTS=yes > WITHOUT_KERNEL_SYMBOLS=yes > WITHOUT_DEBUG_FILES=1 > WITHOUT_LIB32=yes > INSTALL_NODEBUG=yes > > # Don't die on warnings > NO_WERROR= > WERROR= > KERNCONF=pozo > WITH_CCACHE_BUILD=yes Weird, I do not see where such behaviour could come from. I mean, the behaviour of the libthr, assuming that the failing call is from libthr and not from the ruby. Anyway, please try the following. Note that this might be not the final fix, but I am interesting in seeing whether it fixed the issue for you. I want to see the kdump output from ktrace _without_ -di, same as in your first trace. diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2 index 3be81c6582a..ca4d6307c44 100644 --- a/lib/libc/sys/mprotect.2 +++ b/lib/libc/sys/mprotect.2 @@ -28,7 +28,7 @@ .\" @(#)mprotect.2 8.1 (Berkeley) 6/9/93 .\" $FreeBSD$ .\" -.Dd August 3, 2016 +.Dd June 24, 2017 .Dt MPROTECT 2 .Os .Sh NAME @@ -80,10 +80,24 @@ and arguments is not valid. .It Bq Er EACCES The calling process was not allowed to change -the protection to the value specified by -the +the protection to the value specified by the .Fa prot argument. +.It Bq Er ENOMEM +The virtual address range specified by the +.Fa addr +and +.Fa len +arguments specify one or more pages which are not mapped. +.It Bq Er ENOMEM +The +.Fa prot +argument specifies +.Dv PROT_WRITE +on a +.Dv MAP_PRIVATE +mapping, and it would require more swap space than the system is able to +supply for the private pages. .El .Sh SEE ALSO .Xr madvise 2 , diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 39cf303eaa0..b311b54d0f0 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1490,11 +1490,11 @@ vm_map_fixed(vm_map_t map, vm_object_t object, vm_ooffset_t offset, * If object is non-NULL, ref count must be bumped by caller * prior to making call to account for the new entry. */ -int -vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, - vm_offset_t *addr, /* IN/OUT */ - vm_size_t length, vm_offset_t max_addr, int find_space, - vm_prot_t prot, vm_prot_t max, int cow) +static int +vm_map_find1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, + vm_offset_t *addr, /* IN/OUT */ + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, + vm_prot_t max, int cow) { vm_offset_t alignment, initial_addr, start; int result; @@ -1556,6 +1556,26 @@ again: return (result); } +int +vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, + vm_offset_t *addr, /* IN/OUT */ + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, + vm_prot_t max, int cow) +{ + int rv; + bool hinted; + + hinted = *addr != 0; + for (;;) { + rv = vm_map_find1(map, object, offset, addr, length, max_addr, + find_space, prot, max, cow); + if (rv != KERN_NO_SPACE || !hinted) + return (rv); + *addr = 0; + hinted = false; + } +} + /* * vm_map_simplify_entry: * @@ -1970,7 +1990,7 @@ vm_map_pmap_enter(vm_map_t map, vm_offset_t addr, vm_prot_t prot, */ int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, - vm_prot_t new_prot, boolean_t set_max) + vm_prot_t new_prot, boolean_t set_max) { vm_map_entry_t current, entry; vm_object_t obj; @@ -1995,7 +2015,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, if (vm_map_lookup_entry(map, start, &entry)) { vm_map_clip_start(map, entry, start); } else { - entry = entry->next; + vm_map_unlock(map); + return (KERN_INVALID_ADDRESS); } /* @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, */ for (current = entry; current != &map->header && current->start < end; current = current->next) { + if ((current->eflags & MAP_ENTRY_GUARD) != 0) + continue; if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { vm_map_unlock(map); return (KERN_INVALID_ARGUMENT); @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, vm_map_unlock(map); return (KERN_PROTECTION_FAILURE); } + if (current->end < end && (current->next == &map->header || + current->next->start > current->end)) { + vm_map_unlock(map); + return (KERN_INVALID_ADDRESS); + } } /* @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end, * If VM_MAP_WIRE_HOLESOK was specified, skip this check. */ next_entry: - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) && - (entry->end < end && (entry->next == &map->header || - entry->next->start > entry->end))) { + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 && + entry->end < end && (entry->next == &map->header || + entry->next->start > entry->end)) { end = entry->end; rv = KERN_INVALID_ADDRESS; goto done; diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index 4d8f6ad9ed7..09912250d52 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t size, int prot) case KERN_PROTECTION_FAILURE: return (EACCES); case KERN_RESOURCE_SHORTAGE: + case KERN_INVALID_ADDRESS: return (ENOMEM); } return (EINVAL); From owner-freebsd-current@freebsd.org Sun Jun 25 14:09:41 2017 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 2E91ED92297 for ; Sun, 25 Jun 2017 14:09:41 +0000 (UTC) (envelope-from david@catwhisker.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 133246FC95 for ; Sun, 25 Jun 2017 14:09:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0F734D92296; Sun, 25 Jun 2017 14:09:41 +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 0EED4D92295 for ; Sun, 25 Jun 2017 14:09:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 C39706FC94 for ; Sun, 25 Jun 2017 14:09:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5PE9cTO004312; Sun, 25 Jun 2017 14:09:38 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5PE9ctC004311; Sun, 25 Jun 2017 07:09:38 -0700 (PDT) (envelope-from david) Date: Sun, 25 Jun 2017 07:09:38 -0700 From: David Wolfskill To: Konstantin Belousov Cc: Boris Samorodov , current@freebsd.org Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 Message-ID: <20170625140938.GW1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , Boris Samorodov , current@freebsd.org References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> <20170625124748.GT1241@albert.catwhisker.org> <20170625125223.GX3437@kib.kiev.ua> <20170625130521.GU1241@albert.catwhisker.org> <20170625132116.GY3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3wyj3Xt2kUWLNC5K" Content-Disposition: inline In-Reply-To: <20170625132116.GY3437@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 14:09:41 -0000 --3wyj3Xt2kUWLNC5K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2017 at 04:21:16PM +0300, Konstantin Belousov wrote: > ... > > #cat /etc/src-env.conf=20 > > WITH_META_MODE=3Dyes >=20 > So can you _remove_ all kernel object files and rebuild anew with the > clean build dir, please ? OK; that seems to have resulted in a kernel that boots to multi-user mode without incident: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #386 r3= 20324M/320326:1200035: Sun Jun 25 06:36:19 PDT 2017 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 To remove any possible ambiguity, here is what I did. (Note that head is on slice 4; recent stable/11 is on slice 1; when booted =66rom slice 1, slice 4's / is mounted on /S4.) * Rebooted from slice 1 (stable/11). * cd /S4/usr/obj * cp -p usr/src/sys/GENERIC/version /tmp * rm -fr usr/src/sys/GENERIC * mkdir !$ * mv /tmp/version !$/ * cd /S4/boot * cp -pr kernel.old kernel.save * mv kernel{,.panic} * mv kernel{.old,} * Rebooted from slice 4 (head@r320307) * setenv TMPDIR /tmp &&\ id &&\ mount &&\ cd /usr/src &&\ uname -a &&\ date &&\ make -j16 buildkernel &&\ date &&\ rm -fr /boot/modules.old &&\ cp -pr /boot/modules{,.old} &&\ make installkernel &&\ date * shutdown -r now * Sent this message. :-) Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3wyj3Xt2kUWLNC5K Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZT8QiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XVQsIALqUQPHVpJ0tWjQmVBB94bgD TE+y/7WOEawsLBLzEox/XnyCDQShK2YcaJWs5L4GoRBaCepzwmGFskK6Zi9sZWmV +mkiGInnuwqgDBEv9JGSGhk/KvdtJz3n+9PMcoHNS7Fg1u99L77f8EPS9WR/QHxm Lb+rUqTxDHskgJFR6Zk031+OQDB0C8QER5mMFwc657vXhKccCVYQfZsAGB8DZJZG IlYdwHvi3ViA2gvBEzKhcMMMEpK9GFIRNrTlsCMCgzWXZwpUFqP7Su5MQXY11cfD E5DnVtlM4P7AsJUDHhxfOhoOU9Iqk7Xpdol98tQeFQOOtBfzM0tXH/MJW6UlKBs= =TRDW -----END PGP SIGNATURE----- --3wyj3Xt2kUWLNC5K-- From owner-freebsd-current@freebsd.org Sun Jun 25 15:18:30 2017 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 C5842D93A2B for ; Sun, 25 Jun 2017 15:18:30 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67F327325D for ; Sun, 25 Jun 2017 15:18:30 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PFII4t001273 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 17:18:18 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PFIIe2001270 for ; Sun, 25 Jun 2017 17:18:18 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 17:18:18 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: <20170625134133.GA3437@kib.kiev.ua> Message-ID: References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 15:18:30 -0000 On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wrote: > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > >> > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > >>> > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > >>>> New world and kernel r320323 > > >>>> I get a new error or message when using ruby: > > >>>> > > >>>> > > >>>> /usr/local/sbin/portupgrade -av > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > >>>> > > >>>> everything works just this message when using ruby. I recompiled ruby , still same message > > >>>> > > >>>> /usr/local/bin/ruby -v > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > >>>> > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > >>> > > >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > >>> > > >> > > >> Ok not sure if this is right , but this is what i did: > > >> > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > >> > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > >> > > >> you can get kdump.txt at: > > >> > > >> http://www.pozo.com/kernel/kdump .txt > > >> > > >> It???s not failing, I don???t think , I can do portupgrade and it works fine. > > >> I just get this new message > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > your environment ? > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with the > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > stacks for the new threads. New stack grow code was specifically designed > > > to prevent this. Some hack would be needed there, to allow reuse of > > > the main stack gap. > > > > > > > Not running any jails > > all libraries are current as of today > > locate libthr. |xargs ls -l > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > > > ldd /usr/local/bin/ruby > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2 > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1 > > > > /usr/local/bin/ruby: > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a00000) > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) > > libm.so.5 => /lib/libm.so.5 (0x8018f9000) > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000) > > libc.so.7 => /lib/libc.so.7 (0x801d4e000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000) > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000) > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000) > > libutil.so.9 => /lib/libutil.so.9 (0x802982000) > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere > > > > This is a fresh buildworld - installworld from noon today California time. > > > > here are env in make.conf: > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base > > MALLOC_PRODUCTION=yes > > WITH_BDB_VERSION=5 > > > > env in src.conf: > > WITHOUT_DYNAMICROOT=yes > > WITHOUT_UNBOUND=yes > > WITHOUT_CASPER=yes > > WITHOUT_CAPSICUM=yes > > WITHOUT_DMAGENT=yes > > WITHOUT_PROFILE=yes > > WITHOUT_TESTS=yes > > WITHOUT_KERNEL_SYMBOLS=yes > > WITHOUT_DEBUG_FILES=1 > > WITHOUT_LIB32=yes > > INSTALL_NODEBUG=yes > > > > # Don't die on warnings > > NO_WERROR= > > WERROR= > > KERNCONF=pozo > > WITH_CCACHE_BUILD=yes > > Weird, I do not see where such behaviour could come from. I mean, > the behaviour of the libthr, assuming that the failing call is from > libthr and not from the ruby. > > Anyway, please try the following. Note that this might be not the final > fix, but I am interesting in seeing whether it fixed the issue for you. > I want to see the kdump output from ktrace _without_ -di, same as in > your first trace. > > diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2 > index 3be81c6582a..ca4d6307c44 100644 > --- a/lib/libc/sys/mprotect.2 > +++ b/lib/libc/sys/mprotect.2 > @@ -28,7 +28,7 @@ > .\" @(#)mprotect.2 8.1 (Berkeley) 6/9/93 > .\" $FreeBSD$ > .\" > -.Dd August 3, 2016 > +.Dd June 24, 2017 > .Dt MPROTECT 2 > .Os > .Sh NAME > @@ -80,10 +80,24 @@ and > arguments is not valid. > .It Bq Er EACCES > The calling process was not allowed to change > -the protection to the value specified by > -the > +the protection to the value specified by the > .Fa prot > argument. > +.It Bq Er ENOMEM > +The virtual address range specified by the > +.Fa addr > +and > +.Fa len > +arguments specify one or more pages which are not mapped. > +.It Bq Er ENOMEM > +The > +.Fa prot > +argument specifies > +.Dv PROT_WRITE > +on a > +.Dv MAP_PRIVATE > +mapping, and it would require more swap space than the system is able to > +supply for the private pages. > .El > .Sh SEE ALSO > .Xr madvise 2 , > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 39cf303eaa0..b311b54d0f0 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1490,11 +1490,11 @@ vm_map_fixed(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > * If object is non-NULL, ref count must be bumped by caller > * prior to making call to account for the new entry. > */ > -int > -vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > - vm_offset_t *addr, /* IN/OUT */ > - vm_size_t length, vm_offset_t max_addr, int find_space, > - vm_prot_t prot, vm_prot_t max, int cow) > +static int > +vm_map_find1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > + vm_offset_t *addr, /* IN/OUT */ > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > + vm_prot_t max, int cow) > { > vm_offset_t alignment, initial_addr, start; > int result; > @@ -1556,6 +1556,26 @@ again: > return (result); > } > > +int > +vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > + vm_offset_t *addr, /* IN/OUT */ > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > + vm_prot_t max, int cow) > +{ > + int rv; > + bool hinted; > + > + hinted = *addr != 0; > + for (;;) { > + rv = vm_map_find1(map, object, offset, addr, length, max_addr, > + find_space, prot, max, cow); > + if (rv != KERN_NO_SPACE || !hinted) > + return (rv); > + *addr = 0; > + hinted = false; > + } > +} > + > /* > * vm_map_simplify_entry: > * > @@ -1970,7 +1990,7 @@ vm_map_pmap_enter(vm_map_t map, vm_offset_t addr, vm_prot_t prot, > */ > int > vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > - vm_prot_t new_prot, boolean_t set_max) > + vm_prot_t new_prot, boolean_t set_max) > { > vm_map_entry_t current, entry; > vm_object_t obj; > @@ -1995,7 +2015,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > if (vm_map_lookup_entry(map, start, &entry)) { > vm_map_clip_start(map, entry, start); > } else { > - entry = entry->next; > + vm_map_unlock(map); > + return (KERN_INVALID_ADDRESS); > } > > /* > @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > */ > for (current = entry; current != &map->header && current->start < end; > current = current->next) { > + if ((current->eflags & MAP_ENTRY_GUARD) != 0) > + continue; > if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { > vm_map_unlock(map); > return (KERN_INVALID_ARGUMENT); > @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > vm_map_unlock(map); > return (KERN_PROTECTION_FAILURE); > } > + if (current->end < end && (current->next == &map->header || > + current->next->start > current->end)) { > + vm_map_unlock(map); > + return (KERN_INVALID_ADDRESS); > + } > } > > /* > @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end, > * If VM_MAP_WIRE_HOLESOK was specified, skip this check. > */ > next_entry: > - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) && > - (entry->end < end && (entry->next == &map->header || > - entry->next->start > entry->end))) { > + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 && > + entry->end < end && (entry->next == &map->header || > + entry->next->start > entry->end)) { > end = entry->end; > rv = KERN_INVALID_ADDRESS; > goto done; > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > index 4d8f6ad9ed7..09912250d52 100644 > --- a/sys/vm/vm_mmap.c > +++ b/sys/vm/vm_mmap.c > @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t size, int prot) > case KERN_PROTECTION_FAILURE: > return (EACCES); > case KERN_RESOURCE_SHORTAGE: > + case KERN_INVALID_ADDRESS: > return (ENOMEM); > } > return (EINVAL); I'm seeing similar fallout on r320327, built from scratch while running r320293: Script started on Sun Jun 25 17:03:41 2017 # uname -aKU FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST 2017 root@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64 1200035 1200035 # /sbin/zfs mount -va Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) Abort trap (core dumped) # ls -l /lib/libthr* -r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3 # ls -l /usr/lib/libthr* -r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so -> ../../lib/libthr.so.3 -r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a -r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so -> libthread_db.so.3 -r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3 -r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a # ldd /sbin/zfs /sbin/zfs: libjail.so.1 => /lib/libjail.so.1 (0x800247000) libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000) libuutil.so.2 => /lib/libuutil.so.2 (0x800269000) libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000) libzfs.so.3 => /lib/libzfs.so.3 (0x800281000) libc.so.7 => /lib/libc.so.7 (0x8002cd000) libmd.so.6 => /lib/libmd.so.6 (0x8006d1000) libumem.so.2 => /lib/libumem.so.2 (0x8006eb000) libutil.so.9 => /lib/libutil.so.9 (0x8006f0000) libm.so.5 => /lib/libm.so.5 (0x800706000) libavl.so.2 => /lib/libavl.so.2 (0x800736000) libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000) libgeom.so.5 => /lib/libgeom.so.5 (0x800770000) libz.so.6 => /lib/libz.so.6 (0x800779000) libthr.so.3 => /lib/libthr.so.3 (0x800793000) libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000) # ls -l /sbin/zfs -r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs # exit Script done on Sun Jun 25 17:04:32 2017 Although not relevant for this case, neither /usr/lib/libthr.a, nor /usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor /usr/lib/libthread_db_p.a has been updated by installworld, nor removed by delete-old-libs, in a very long time. Anything else I can contribute? I'll try your patch and see if I can get any further. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 15:56:18 2017 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 D5A59D947D4 for ; Sun, 25 Jun 2017 15:56:18 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 798D274553 for ; Sun, 25 Jun 2017 15:56:18 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PFu95h001449 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 17:56:09 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PFu9Fx001446 for ; Sun, 25 Jun 2017 17:56:09 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 17:56:09 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: Message-ID: References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 15:56:18 -0000 On Sun, 25 Jun 2017 17:18+0200, Trond Endrestl wrote: > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wrote: > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > >> > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > > >>> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > >>>> New world and kernel r320323 > > > >>>> I get a new error or message when using ruby: > > > >>>> > > > >>>> > > > >>>> /usr/local/sbin/portupgrade -av > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > >>>> > > > >>>> everything works just this message when using ruby. I recompiled ruby , still same message > > > >>>> > > > >>>> /usr/local/bin/ruby -v > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >>>> > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > > >>> > > > >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > > >>> > > > >> > > > >> Ok not sure if this is right , but this is what i did: > > > >> > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >> > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > >> > > > >> you can get kdump.txt at: > > > >> > > > >> http://www.pozo.com/kernel/kdump .txt > > > >> > > > >> It???s not failing, I don???t think , I can do portupgrade and it works fine. > > > >> I just get this new message > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > your environment ? > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with the > > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > > stacks for the new threads. New stack grow code was specifically designed > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > the main stack gap. > > > > > > > > > > Not running any jails > > > all libraries are current as of today > > > locate libthr. |xargs ls -l > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > > > > > ldd /usr/local/bin/ruby > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2 > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1 > > > > > > /usr/local/bin/ruby: > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a00000) > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) > > > libm.so.5 => /lib/libm.so.5 (0x8018f9000) > > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000) > > > libc.so.7 => /lib/libc.so.7 (0x801d4e000) > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000) > > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000) > > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000) > > > libutil.so.9 => /lib/libutil.so.9 (0x802982000) > > > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere > > > > > > This is a fresh buildworld - installworld from noon today California time. > > > > > > here are env in make.conf: > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base > > > MALLOC_PRODUCTION=yes > > > WITH_BDB_VERSION=5 > > > > > > env in src.conf: > > > WITHOUT_DYNAMICROOT=yes > > > WITHOUT_UNBOUND=yes > > > WITHOUT_CASPER=yes > > > WITHOUT_CAPSICUM=yes > > > WITHOUT_DMAGENT=yes > > > WITHOUT_PROFILE=yes > > > WITHOUT_TESTS=yes > > > WITHOUT_KERNEL_SYMBOLS=yes > > > WITHOUT_DEBUG_FILES=1 > > > WITHOUT_LIB32=yes > > > INSTALL_NODEBUG=yes > > > > > > # Don't die on warnings > > > NO_WERROR= > > > WERROR= > > > KERNCONF=pozo > > > WITH_CCACHE_BUILD=yes > > > > Weird, I do not see where such behaviour could come from. I mean, > > the behaviour of the libthr, assuming that the failing call is from > > libthr and not from the ruby. > > > > Anyway, please try the following. Note that this might be not the final > > fix, but I am interesting in seeing whether it fixed the issue for you. > > I want to see the kdump output from ktrace _without_ -di, same as in > > your first trace. > > > > diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2 > > index 3be81c6582a..ca4d6307c44 100644 > > --- a/lib/libc/sys/mprotect.2 > > +++ b/lib/libc/sys/mprotect.2 > > @@ -28,7 +28,7 @@ > > .\" @(#)mprotect.2 8.1 (Berkeley) 6/9/93 > > .\" $FreeBSD$ > > .\" > > -.Dd August 3, 2016 > > +.Dd June 24, 2017 > > .Dt MPROTECT 2 > > .Os > > .Sh NAME > > @@ -80,10 +80,24 @@ and > > arguments is not valid. > > .It Bq Er EACCES > > The calling process was not allowed to change > > -the protection to the value specified by > > -the > > +the protection to the value specified by the > > .Fa prot > > argument. > > +.It Bq Er ENOMEM > > +The virtual address range specified by the > > +.Fa addr > > +and > > +.Fa len > > +arguments specify one or more pages which are not mapped. > > +.It Bq Er ENOMEM > > +The > > +.Fa prot > > +argument specifies > > +.Dv PROT_WRITE > > +on a > > +.Dv MAP_PRIVATE > > +mapping, and it would require more swap space than the system is able to > > +supply for the private pages. > > .El > > .Sh SEE ALSO > > .Xr madvise 2 , > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > > index 39cf303eaa0..b311b54d0f0 100644 > > --- a/sys/vm/vm_map.c > > +++ b/sys/vm/vm_map.c > > @@ -1490,11 +1490,11 @@ vm_map_fixed(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > * If object is non-NULL, ref count must be bumped by caller > > * prior to making call to account for the new entry. > > */ > > -int > > -vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > - vm_offset_t *addr, /* IN/OUT */ > > - vm_size_t length, vm_offset_t max_addr, int find_space, > > - vm_prot_t prot, vm_prot_t max, int cow) > > +static int > > +vm_map_find1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > + vm_offset_t *addr, /* IN/OUT */ > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > + vm_prot_t max, int cow) > > { > > vm_offset_t alignment, initial_addr, start; > > int result; > > @@ -1556,6 +1556,26 @@ again: > > return (result); > > } > > > > +int > > +vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > + vm_offset_t *addr, /* IN/OUT */ > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > + vm_prot_t max, int cow) > > +{ > > + int rv; > > + bool hinted; > > + > > + hinted = *addr != 0; > > + for (;;) { > > + rv = vm_map_find1(map, object, offset, addr, length, max_addr, > > + find_space, prot, max, cow); > > + if (rv != KERN_NO_SPACE || !hinted) > > + return (rv); > > + *addr = 0; > > + hinted = false; > > + } > > +} > > + > > /* > > * vm_map_simplify_entry: > > * > > @@ -1970,7 +1990,7 @@ vm_map_pmap_enter(vm_map_t map, vm_offset_t addr, vm_prot_t prot, > > */ > > int > > vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > - vm_prot_t new_prot, boolean_t set_max) > > + vm_prot_t new_prot, boolean_t set_max) > > { > > vm_map_entry_t current, entry; > > vm_object_t obj; > > @@ -1995,7 +2015,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > if (vm_map_lookup_entry(map, start, &entry)) { > > vm_map_clip_start(map, entry, start); > > } else { > > - entry = entry->next; > > + vm_map_unlock(map); > > + return (KERN_INVALID_ADDRESS); > > } > > > > /* > > @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > */ > > for (current = entry; current != &map->header && current->start < end; > > current = current->next) { > > + if ((current->eflags & MAP_ENTRY_GUARD) != 0) > > + continue; > > if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { > > vm_map_unlock(map); > > return (KERN_INVALID_ARGUMENT); > > @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > vm_map_unlock(map); > > return (KERN_PROTECTION_FAILURE); > > } > > + if (current->end < end && (current->next == &map->header || > > + current->next->start > current->end)) { > > + vm_map_unlock(map); > > + return (KERN_INVALID_ADDRESS); > > + } > > } > > > > /* > > @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end, > > * If VM_MAP_WIRE_HOLESOK was specified, skip this check. > > */ > > next_entry: > > - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) && > > - (entry->end < end && (entry->next == &map->header || > > - entry->next->start > entry->end))) { > > + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 && > > + entry->end < end && (entry->next == &map->header || > > + entry->next->start > entry->end)) { > > end = entry->end; > > rv = KERN_INVALID_ADDRESS; > > goto done; > > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > > index 4d8f6ad9ed7..09912250d52 100644 > > --- a/sys/vm/vm_mmap.c > > +++ b/sys/vm/vm_mmap.c > > @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t size, int prot) > > case KERN_PROTECTION_FAILURE: > > return (EACCES); > > case KERN_RESOURCE_SHORTAGE: > > + case KERN_INVALID_ADDRESS: > > return (ENOMEM); > > } > > return (EINVAL); > > I'm seeing similar fallout on r320327, built from scratch while > running r320293: > > Script started on Sun Jun 25 17:03:41 2017 > # uname -aKU > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST 2017 root@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64 1200035 1200035 > # /sbin/zfs mount -va > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) > Abort trap (core dumped) > # ls -l /lib/libthr* > -r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3 > # ls -l /usr/lib/libthr* > -r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a > lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > -r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a > -r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a > lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so -> libthread_db.so.3 > -r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3 > -r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a > # ldd /sbin/zfs > /sbin/zfs: > libjail.so.1 => /lib/libjail.so.1 (0x800247000) > libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000) > libuutil.so.2 => /lib/libuutil.so.2 (0x800269000) > libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000) > libzfs.so.3 => /lib/libzfs.so.3 (0x800281000) > libc.so.7 => /lib/libc.so.7 (0x8002cd000) > libmd.so.6 => /lib/libmd.so.6 (0x8006d1000) > libumem.so.2 => /lib/libumem.so.2 (0x8006eb000) > libutil.so.9 => /lib/libutil.so.9 (0x8006f0000) > libm.so.5 => /lib/libm.so.5 (0x800706000) > libavl.so.2 => /lib/libavl.so.2 (0x800736000) > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000) > libgeom.so.5 => /lib/libgeom.so.5 (0x800770000) > libz.so.6 => /lib/libz.so.6 (0x800779000) > libthr.so.3 => /lib/libthr.so.3 (0x800793000) > libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000) > # ls -l /sbin/zfs > -r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs > # exit > > Script done on Sun Jun 25 17:04:32 2017 > > Although not relevant for this case, neither /usr/lib/libthr.a, nor > /usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor > /usr/lib/libthread_db_p.a has been updated by installworld, nor > removed by delete-old-libs, in a very long time. > > Anything else I can contribute? I'll try your patch and see if I can > get any further. Partial success! Your patch brought me past the libthr issue with /sbin/zfs. Like the OP, portupgrade (and ruby22) complains about unable to create a timer thread. I shall attempt to rebuild lang/ruby22 and emulators/virtualbox-ose-additions-nox11. I think I'll switch to ruby23 while I'm at it. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 16:09:08 2017 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 E92F3D94B6F for ; Sun, 25 Jun 2017 16:09:08 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8761B74BFB for ; Sun, 25 Jun 2017 16:09:08 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PG8xTZ001512 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 18:08:59 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PG8xc2001509 for ; Sun, 25 Jun 2017 18:08:59 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 18:08:59 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: Message-ID: References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 16:09:09 -0000 On Sun, 25 Jun 2017 17:56+0200, Trond Endrestl wrote: > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestl wrote: > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wrote: > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > >> > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > > > >>> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > >>>> New world and kernel r320323 > > > > >>>> I get a new error or message when using ruby: > > > > >>>> > > > > >>>> > > > > >>>> /usr/local/sbin/portupgrade -av > > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > >>>> > > > > >>>> everything works just this message when using ruby. I recompiled ruby , still same message > > > > >>>> > > > > >>>> /usr/local/bin/ruby -v > > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >>>> > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > > > >>> > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > > > >>> > > > > >> > > > > >> Ok not sure if this is right , but this is what i did: > > > > >> > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >> > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > >> > > > > >> you can get kdump.txt at: > > > > >> > > > > >> http://www.pozo.com/kernel/kdump .txt > > > > >> > > > > >> It???s not failing, I don???t think , I can do portupgrade and it works fine. > > > > >> I just get this new message > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > > your environment ? > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with the > > > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > > > stacks for the new threads. New stack grow code was specifically designed > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > the main stack gap. > > > > > > > > > > > > > Not running any jails > > > > all libraries are current as of today > > > > locate libthr. |xargs ls -l > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > > > > > > > ldd /usr/local/bin/ruby > > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2 > > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1 > > > > > > > > /usr/local/bin/ruby: > > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a00000) > > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) > > > > libm.so.5 => /lib/libm.so.5 (0x8018f9000) > > > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000) > > > > libc.so.7 => /lib/libc.so.7 (0x801d4e000) > > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000) > > > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000) > > > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000) > > > > libutil.so.9 => /lib/libutil.so.9 (0x802982000) > > > > > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere > > > > > > > > This is a fresh buildworld - installworld from noon today California time. > > > > > > > > here are env in make.conf: > > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base > > > > MALLOC_PRODUCTION=yes > > > > WITH_BDB_VERSION=5 > > > > > > > > env in src.conf: > > > > WITHOUT_DYNAMICROOT=yes > > > > WITHOUT_UNBOUND=yes > > > > WITHOUT_CASPER=yes > > > > WITHOUT_CAPSICUM=yes > > > > WITHOUT_DMAGENT=yes > > > > WITHOUT_PROFILE=yes > > > > WITHOUT_TESTS=yes > > > > WITHOUT_KERNEL_SYMBOLS=yes > > > > WITHOUT_DEBUG_FILES=1 > > > > WITHOUT_LIB32=yes > > > > INSTALL_NODEBUG=yes > > > > > > > > # Don't die on warnings > > > > NO_WERROR= > > > > WERROR= > > > > KERNCONF=pozo > > > > WITH_CCACHE_BUILD=yes > > > > > > Weird, I do not see where such behaviour could come from. I mean, > > > the behaviour of the libthr, assuming that the failing call is from > > > libthr and not from the ruby. > > > > > > Anyway, please try the following. Note that this might be not the final > > > fix, but I am interesting in seeing whether it fixed the issue for you. > > > I want to see the kdump output from ktrace _without_ -di, same as in > > > your first trace. > > > > > > diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2 > > > index 3be81c6582a..ca4d6307c44 100644 > > > --- a/lib/libc/sys/mprotect.2 > > > +++ b/lib/libc/sys/mprotect.2 > > > @@ -28,7 +28,7 @@ > > > .\" @(#)mprotect.2 8.1 (Berkeley) 6/9/93 > > > .\" $FreeBSD$ > > > .\" > > > -.Dd August 3, 2016 > > > +.Dd June 24, 2017 > > > .Dt MPROTECT 2 > > > .Os > > > .Sh NAME > > > @@ -80,10 +80,24 @@ and > > > arguments is not valid. > > > .It Bq Er EACCES > > > The calling process was not allowed to change > > > -the protection to the value specified by > > > -the > > > +the protection to the value specified by the > > > .Fa prot > > > argument. > > > +.It Bq Er ENOMEM > > > +The virtual address range specified by the > > > +.Fa addr > > > +and > > > +.Fa len > > > +arguments specify one or more pages which are not mapped. > > > +.It Bq Er ENOMEM > > > +The > > > +.Fa prot > > > +argument specifies > > > +.Dv PROT_WRITE > > > +on a > > > +.Dv MAP_PRIVATE > > > +mapping, and it would require more swap space than the system is able to > > > +supply for the private pages. > > > .El > > > .Sh SEE ALSO > > > .Xr madvise 2 , > > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > > > index 39cf303eaa0..b311b54d0f0 100644 > > > --- a/sys/vm/vm_map.c > > > +++ b/sys/vm/vm_map.c > > > @@ -1490,11 +1490,11 @@ vm_map_fixed(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > * If object is non-NULL, ref count must be bumped by caller > > > * prior to making call to account for the new entry. > > > */ > > > -int > > > -vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > - vm_offset_t *addr, /* IN/OUT */ > > > - vm_size_t length, vm_offset_t max_addr, int find_space, > > > - vm_prot_t prot, vm_prot_t max, int cow) > > > +static int > > > +vm_map_find1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > + vm_offset_t *addr, /* IN/OUT */ > > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > > + vm_prot_t max, int cow) > > > { > > > vm_offset_t alignment, initial_addr, start; > > > int result; > > > @@ -1556,6 +1556,26 @@ again: > > > return (result); > > > } > > > > > > +int > > > +vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > + vm_offset_t *addr, /* IN/OUT */ > > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > > + vm_prot_t max, int cow) > > > +{ > > > + int rv; > > > + bool hinted; > > > + > > > + hinted = *addr != 0; > > > + for (;;) { > > > + rv = vm_map_find1(map, object, offset, addr, length, max_addr, > > > + find_space, prot, max, cow); > > > + if (rv != KERN_NO_SPACE || !hinted) > > > + return (rv); > > > + *addr = 0; > > > + hinted = false; > > > + } > > > +} > > > + > > > /* > > > * vm_map_simplify_entry: > > > * > > > @@ -1970,7 +1990,7 @@ vm_map_pmap_enter(vm_map_t map, vm_offset_t addr, vm_prot_t prot, > > > */ > > > int > > > vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > - vm_prot_t new_prot, boolean_t set_max) > > > + vm_prot_t new_prot, boolean_t set_max) > > > { > > > vm_map_entry_t current, entry; > > > vm_object_t obj; > > > @@ -1995,7 +2015,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > if (vm_map_lookup_entry(map, start, &entry)) { > > > vm_map_clip_start(map, entry, start); > > > } else { > > > - entry = entry->next; > > > + vm_map_unlock(map); > > > + return (KERN_INVALID_ADDRESS); > > > } > > > > > > /* > > > @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > */ > > > for (current = entry; current != &map->header && current->start < end; > > > current = current->next) { > > > + if ((current->eflags & MAP_ENTRY_GUARD) != 0) > > > + continue; > > > if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { > > > vm_map_unlock(map); > > > return (KERN_INVALID_ARGUMENT); > > > @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > vm_map_unlock(map); > > > return (KERN_PROTECTION_FAILURE); > > > } > > > + if (current->end < end && (current->next == &map->header || > > > + current->next->start > current->end)) { > > > + vm_map_unlock(map); > > > + return (KERN_INVALID_ADDRESS); > > > + } > > > } > > > > > > /* > > > @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > * If VM_MAP_WIRE_HOLESOK was specified, skip this check. > > > */ > > > next_entry: > > > - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) && > > > - (entry->end < end && (entry->next == &map->header || > > > - entry->next->start > entry->end))) { > > > + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 && > > > + entry->end < end && (entry->next == &map->header || > > > + entry->next->start > entry->end)) { > > > end = entry->end; > > > rv = KERN_INVALID_ADDRESS; > > > goto done; > > > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > > > index 4d8f6ad9ed7..09912250d52 100644 > > > --- a/sys/vm/vm_mmap.c > > > +++ b/sys/vm/vm_mmap.c > > > @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t size, int prot) > > > case KERN_PROTECTION_FAILURE: > > > return (EACCES); > > > case KERN_RESOURCE_SHORTAGE: > > > + case KERN_INVALID_ADDRESS: > > > return (ENOMEM); > > > } > > > return (EINVAL); > > > > I'm seeing similar fallout on r320327, built from scratch while > > running r320293: > > > > Script started on Sun Jun 25 17:03:41 2017 > > # uname -aKU > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST 2017 root@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64 1200035 1200035 > > # /sbin/zfs mount -va > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) > > Abort trap (core dumped) > > # ls -l /lib/libthr* > > -r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3 > > # ls -l /usr/lib/libthr* > > -r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a > > lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > -r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a > > -r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a > > lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so -> libthread_db.so.3 > > -r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3 > > -r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a > > # ldd /sbin/zfs > > /sbin/zfs: > > libjail.so.1 => /lib/libjail.so.1 (0x800247000) > > libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000) > > libuutil.so.2 => /lib/libuutil.so.2 (0x800269000) > > libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000) > > libzfs.so.3 => /lib/libzfs.so.3 (0x800281000) > > libc.so.7 => /lib/libc.so.7 (0x8002cd000) > > libmd.so.6 => /lib/libmd.so.6 (0x8006d1000) > > libumem.so.2 => /lib/libumem.so.2 (0x8006eb000) > > libutil.so.9 => /lib/libutil.so.9 (0x8006f0000) > > libm.so.5 => /lib/libm.so.5 (0x800706000) > > libavl.so.2 => /lib/libavl.so.2 (0x800736000) > > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000) > > libgeom.so.5 => /lib/libgeom.so.5 (0x800770000) > > libz.so.6 => /lib/libz.so.6 (0x800779000) > > libthr.so.3 => /lib/libthr.so.3 (0x800793000) > > libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000) > > # ls -l /sbin/zfs > > -r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs > > # exit > > > > Script done on Sun Jun 25 17:04:32 2017 > > > > Although not relevant for this case, neither /usr/lib/libthr.a, nor > > /usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor > > /usr/lib/libthread_db_p.a has been updated by installworld, nor > > removed by delete-old-libs, in a very long time. > > > > Anything else I can contribute? I'll try your patch and see if I can > > get any further. > > Partial success! Your patch brought me past the libthr issue with > /sbin/zfs. > > Like the OP, portupgrade (and ruby22) complains about unable to create > a timer thread. I shall attempt to rebuild lang/ruby22 and > emulators/virtualbox-ose-additions-nox11. I think I'll switch to > ruby23 while I'm at it. The newly built portupgrade and ruby23 are limping away with:
: warning: pthread_create failed for time: Resource temporarily unavailable, scheduling broken At least I can get emulators/virtualbox-ose-additions-nox11 up to speed. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 16:15:28 2017 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 7531ED94D80 for ; Sun, 25 Jun 2017 16:15:28 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1740374FBA for ; Sun, 25 Jun 2017 16:15:27 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PGFJUO001561 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 18:15:19 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PGFICC001558 for ; Sun, 25 Jun 2017 18:15:18 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 18:15:18 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: Message-ID: References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 16:15:28 -0000 On Sun, 25 Jun 2017 18:08+0200, Trond Endrestl wrote: > On Sun, 25 Jun 2017 17:56+0200, Trond Endrestl wrote: > > > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestl wrote: > > > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov wrote: > > > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > > >> > > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > > > > >>> > > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > > >>>> New world and kernel r320323 > > > > > >>>> I get a new error or message when using ruby: > > > > > >>>> > > > > > >>>> > > > > > >>>> /usr/local/sbin/portupgrade -av > > > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > > >>>> > > > > > >>>> everything works just this message when using ruby. I recompiled ruby , still same message > > > > > >>>> > > > > > >>>> /usr/local/bin/ruby -v > > > > > >>>>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >>>> > > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > > > > >>> > > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > > > > >>> > > > > > >> > > > > > >> Ok not sure if this is right , but this is what i did: > > > > > >> > > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >> > > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > > >> > > > > > >> you can get kdump.txt at: > > > > > >> > > > > > >> http://www.pozo.com/kernel/kdump .txt > > > > > >> > > > > > >> It???s not failing, I don???t think , I can do portupgrade and it works fine. > > > > > >> I just get this new message > > > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > > > your environment ? > > > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with the > > > > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > > > > stacks for the new threads. New stack grow code was specifically designed > > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > > the main stack gap. > > > > > > > > > > > > > > > > Not running any jails > > > > > all libraries are current as of today > > > > > locate libthr. |xargs ls -l > > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > > > > > > > > > ldd /usr/local/bin/ruby > > > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2 > > > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1 > > > > > > > > > > /usr/local/bin/ruby: > > > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a00000) > > > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) > > > > > libm.so.5 => /lib/libm.so.5 (0x8018f9000) > > > > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000) > > > > > libc.so.7 => /lib/libc.so.7 (0x801d4e000) > > > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000) > > > > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000) > > > > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000) > > > > > libutil.so.9 => /lib/libutil.so.9 (0x802982000) > > > > > > > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere > > > > > > > > > > This is a fresh buildworld - installworld from noon today California time. > > > > > > > > > > here are env in make.conf: > > > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base > > > > > MALLOC_PRODUCTION=yes > > > > > WITH_BDB_VERSION=5 > > > > > > > > > > env in src.conf: > > > > > WITHOUT_DYNAMICROOT=yes > > > > > WITHOUT_UNBOUND=yes > > > > > WITHOUT_CASPER=yes > > > > > WITHOUT_CAPSICUM=yes > > > > > WITHOUT_DMAGENT=yes > > > > > WITHOUT_PROFILE=yes > > > > > WITHOUT_TESTS=yes > > > > > WITHOUT_KERNEL_SYMBOLS=yes > > > > > WITHOUT_DEBUG_FILES=1 > > > > > WITHOUT_LIB32=yes > > > > > INSTALL_NODEBUG=yes > > > > > > > > > > # Don't die on warnings > > > > > NO_WERROR= > > > > > WERROR= > > > > > KERNCONF=pozo > > > > > WITH_CCACHE_BUILD=yes > > > > > > > > Weird, I do not see where such behaviour could come from. I mean, > > > > the behaviour of the libthr, assuming that the failing call is from > > > > libthr and not from the ruby. > > > > > > > > Anyway, please try the following. Note that this might be not the final > > > > fix, but I am interesting in seeing whether it fixed the issue for you. > > > > I want to see the kdump output from ktrace _without_ -di, same as in > > > > your first trace. > > > > > > > > diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2 > > > > index 3be81c6582a..ca4d6307c44 100644 > > > > --- a/lib/libc/sys/mprotect.2 > > > > +++ b/lib/libc/sys/mprotect.2 > > > > @@ -28,7 +28,7 @@ > > > > .\" @(#)mprotect.2 8.1 (Berkeley) 6/9/93 > > > > .\" $FreeBSD$ > > > > .\" > > > > -.Dd August 3, 2016 > > > > +.Dd June 24, 2017 > > > > .Dt MPROTECT 2 > > > > .Os > > > > .Sh NAME > > > > @@ -80,10 +80,24 @@ and > > > > arguments is not valid. > > > > .It Bq Er EACCES > > > > The calling process was not allowed to change > > > > -the protection to the value specified by > > > > -the > > > > +the protection to the value specified by the > > > > .Fa prot > > > > argument. > > > > +.It Bq Er ENOMEM > > > > +The virtual address range specified by the > > > > +.Fa addr > > > > +and > > > > +.Fa len > > > > +arguments specify one or more pages which are not mapped. > > > > +.It Bq Er ENOMEM > > > > +The > > > > +.Fa prot > > > > +argument specifies > > > > +.Dv PROT_WRITE > > > > +on a > > > > +.Dv MAP_PRIVATE > > > > +mapping, and it would require more swap space than the system is able to > > > > +supply for the private pages. > > > > .El > > > > .Sh SEE ALSO > > > > .Xr madvise 2 , > > > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > > > > index 39cf303eaa0..b311b54d0f0 100644 > > > > --- a/sys/vm/vm_map.c > > > > +++ b/sys/vm/vm_map.c > > > > @@ -1490,11 +1490,11 @@ vm_map_fixed(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > > * If object is non-NULL, ref count must be bumped by caller > > > > * prior to making call to account for the new entry. > > > > */ > > > > -int > > > > -vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > > - vm_offset_t *addr, /* IN/OUT */ > > > > - vm_size_t length, vm_offset_t max_addr, int find_space, > > > > - vm_prot_t prot, vm_prot_t max, int cow) > > > > +static int > > > > +vm_map_find1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > > + vm_offset_t *addr, /* IN/OUT */ > > > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > > > + vm_prot_t max, int cow) > > > > { > > > > vm_offset_t alignment, initial_addr, start; > > > > int result; > > > > @@ -1556,6 +1556,26 @@ again: > > > > return (result); > > > > } > > > > > > > > +int > > > > +vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > > > + vm_offset_t *addr, /* IN/OUT */ > > > > + vm_size_t length, vm_offset_t max_addr, int find_space, vm_prot_t prot, > > > > + vm_prot_t max, int cow) > > > > +{ > > > > + int rv; > > > > + bool hinted; > > > > + > > > > + hinted = *addr != 0; > > > > + for (;;) { > > > > + rv = vm_map_find1(map, object, offset, addr, length, max_addr, > > > > + find_space, prot, max, cow); > > > > + if (rv != KERN_NO_SPACE || !hinted) > > > > + return (rv); > > > > + *addr = 0; > > > > + hinted = false; > > > > + } > > > > +} > > > > + > > > > /* > > > > * vm_map_simplify_entry: > > > > * > > > > @@ -1970,7 +1990,7 @@ vm_map_pmap_enter(vm_map_t map, vm_offset_t addr, vm_prot_t prot, > > > > */ > > > > int > > > > vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > > - vm_prot_t new_prot, boolean_t set_max) > > > > + vm_prot_t new_prot, boolean_t set_max) > > > > { > > > > vm_map_entry_t current, entry; > > > > vm_object_t obj; > > > > @@ -1995,7 +2015,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > > if (vm_map_lookup_entry(map, start, &entry)) { > > > > vm_map_clip_start(map, entry, start); > > > > } else { > > > > - entry = entry->next; > > > > + vm_map_unlock(map); > > > > + return (KERN_INVALID_ADDRESS); > > > > } > > > > > > > > /* > > > > @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > > */ > > > > for (current = entry; current != &map->header && current->start < end; > > > > current = current->next) { > > > > + if ((current->eflags & MAP_ENTRY_GUARD) != 0) > > > > + continue; > > > > if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { > > > > vm_map_unlock(map); > > > > return (KERN_INVALID_ARGUMENT); > > > > @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > > vm_map_unlock(map); > > > > return (KERN_PROTECTION_FAILURE); > > > > } > > > > + if (current->end < end && (current->next == &map->header || > > > > + current->next->start > current->end)) { > > > > + vm_map_unlock(map); > > > > + return (KERN_INVALID_ADDRESS); > > > > + } > > > > } > > > > > > > > /* > > > > @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end, > > > > * If VM_MAP_WIRE_HOLESOK was specified, skip this check. > > > > */ > > > > next_entry: > > > > - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) && > > > > - (entry->end < end && (entry->next == &map->header || > > > > - entry->next->start > entry->end))) { > > > > + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 && > > > > + entry->end < end && (entry->next == &map->header || > > > > + entry->next->start > entry->end)) { > > > > end = entry->end; > > > > rv = KERN_INVALID_ADDRESS; > > > > goto done; > > > > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > > > > index 4d8f6ad9ed7..09912250d52 100644 > > > > --- a/sys/vm/vm_mmap.c > > > > +++ b/sys/vm/vm_mmap.c > > > > @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t size, int prot) > > > > case KERN_PROTECTION_FAILURE: > > > > return (EACCES); > > > > case KERN_RESOURCE_SHORTAGE: > > > > + case KERN_INVALID_ADDRESS: > > > > return (ENOMEM); > > > > } > > > > return (EINVAL); > > > > > > I'm seeing similar fallout on r320327, built from scratch while > > > running r320293: > > > > > > Script started on Sun Jun 25 17:03:41 2017 > > > # uname -aKU > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST 2017 root@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64 1200035 1200035 > > > # /sbin/zfs mount -va > > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) > > > Abort trap (core dumped) > > > # ls -l /lib/libthr* > > > -r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3 > > > # ls -l /usr/lib/libthr* > > > -r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a > > > lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so -> ../../lib/libthr.so.3 > > > -r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a > > > -r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a > > > lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so -> libthread_db.so.3 > > > -r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3 > > > -r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a > > > # ldd /sbin/zfs > > > /sbin/zfs: > > > libjail.so.1 => /lib/libjail.so.1 (0x800247000) > > > libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000) > > > libuutil.so.2 => /lib/libuutil.so.2 (0x800269000) > > > libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000) > > > libzfs.so.3 => /lib/libzfs.so.3 (0x800281000) > > > libc.so.7 => /lib/libc.so.7 (0x8002cd000) > > > libmd.so.6 => /lib/libmd.so.6 (0x8006d1000) > > > libumem.so.2 => /lib/libumem.so.2 (0x8006eb000) > > > libutil.so.9 => /lib/libutil.so.9 (0x8006f0000) > > > libm.so.5 => /lib/libm.so.5 (0x800706000) > > > libavl.so.2 => /lib/libavl.so.2 (0x800736000) > > > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000) > > > libgeom.so.5 => /lib/libgeom.so.5 (0x800770000) > > > libz.so.6 => /lib/libz.so.6 (0x800779000) > > > libthr.so.3 => /lib/libthr.so.3 (0x800793000) > > > libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000) > > > # ls -l /sbin/zfs > > > -r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs > > > # exit > > > > > > Script done on Sun Jun 25 17:04:32 2017 > > > > > > Although not relevant for this case, neither /usr/lib/libthr.a, nor > > > /usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor > > > /usr/lib/libthread_db_p.a has been updated by installworld, nor > > > removed by delete-old-libs, in a very long time. > > > > > > Anything else I can contribute? I'll try your patch and see if I can > > > get any further. > > > > Partial success! Your patch brought me past the libthr issue with > > /sbin/zfs. > > > > Like the OP, portupgrade (and ruby22) complains about unable to create > > a timer thread. I shall attempt to rebuild lang/ruby22 and > > emulators/virtualbox-ose-additions-nox11. I think I'll switch to > > ruby23 while I'm at it. > > The newly built portupgrade and ruby23 are limping away with: > >
: warning: pthread_create failed for time: Resource temporarily unavailable, scheduling broken > > At least I can get emulators/virtualbox-ose-additions-nox11 up to > speed. Or maybe I'm not so lucky, since ar dumped core while linking RuntimeGuestR3 and RuntimeGuestR3Shared. I'll stop posting while you get this sorted out. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 16:41:22 2017 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 1FBD0D953B7 for ; Sun, 25 Jun 2017 16:41:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 9B12075C7A for ; Sun, 25 Jun 2017 16:41:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PGfFh9076887 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 19:41:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PGfFh9076887 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PGfFv2076886; Sun, 25 Jun 2017 19:41:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 19:41:15 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625164115.GD3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 16:41:22 -0000 On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov wrote: > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > >> maybe message got reformatted in mail program (mac mail). > >> could you send me a tar file of the patch? > >> also not sure if ???patch -p1 >> > >> you could cc root@pozo.com , that way i have copy on freebsd box and on mac. > > > > https://people.freebsd.org/~kib/misc/vm2.1.patch > > OK patched and built new kernel \ > rebooted, > same ruby message. So it must be a ruby thing. > new kdump.txt at http://www.pozo.com/kernel/kdump.txt > > also i???ll put a copy of my kernel config in same directory: > > http://www.pozo.com/kernel/pozo > > only one module is being loaded at boot: > (kernel)4908}kldstat > Id Refs Address Size Name > 1 5 0xffffffff80200000 10380a8 kernel > 2 1 0xffffffff8123a000 e13f50 nvidia.ko > > I can disable nvidia if it helps as I really only access this machine over the net or serial console. > No need, I understood why MAP_STACK failed in this case, thanks to the ktrace log. This is indeed something ruby-specific, or rather, triggered by ruby special use of libthr. It is not related to the main stack split. It seems that ruby requested very small stack for a new thread, only 5 pages in size. This size caused the stack gap to be correctly calculated as having zero size, because the whole stack is allocated by initial grow. But then there is no space for the guard page, which caused mapping failure for it, and overall stack mapping failure. Try this. https://people.freebsd.org/~kib/misc/vm2.2.patch From owner-freebsd-current@freebsd.org Sun Jun 25 17:11:41 2017 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 6D88BD95DCA for ; Sun, 25 Jun 2017 17:11:41 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B752769E2 for ; Sun, 25 Jun 2017 17:11:41 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5PH98WQ029483; Sun, 25 Jun 2017 10:09:08 -0700 (PDT) (envelope-from null@pozo.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 From: Manfred Antar In-Reply-To: <20170625164115.GD3437@kib.kiev.ua> Date: Sun, 25 Jun 2017 10:09:07 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6579B80B-5581-4EBC-895F-5E7ED1D33641@pozo.com> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-102.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_62,RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5PH98WQ029483 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 17:11:41 -0000 > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov wr= ote: >=20 > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: >>=20 >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov = wrote: >>>=20 >>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: >>>> maybe message got reformatted in mail program (mac mail). >>>> could you send me a tar file of the patch? >>>> also not sure if ???patch -p1 >>>=20 >>>> you could cc root@pozo.com , that way i have co= py on freebsd box and on mac. >>>=20 >>> https://people.freebsd.org/~kib/misc/vm2.1.patch >>=20 >> OK patched and built new kernel \ >> rebooted, >> same ruby message. So it must be a ruby thing. >> new kdump.txt at http://www.pozo.com/kernel/kdump.txt >>=20 >> also i???ll put a copy of my kernel config in same directory: >>=20 >> http://www.pozo.com/kernel/pozo >>=20 >> only one module is being loaded at boot: >> (kernel)4908}kldstat >> Id Refs Address Size Name >> 1 5 0xffffffff80200000 10380a8 kernel >> 2 1 0xffffffff8123a000 e13f50 nvidia.ko=20 >>=20 >> I can disable nvidia if it helps as I really only access this machine ov= er the net or serial console. >>=20 > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main stack > split. >=20 > It seems that ruby requested very small stack for a new thread, only 5 > pages in size. This size caused the stack gap to be correctly calculated > as having zero size, because the whole stack is allocated by initial grow. > But then there is no space for the guard page, which caused mapping failu= re > for it, and overall stack mapping failure. >=20 > Try this. > https://people.freebsd.org/~kib/misc/vm2.2.patch Seems to have worked: (~)4933}ruby -v ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] (~)4934} No more message. Do you want new ktrace ? Thanks Manfred --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 17:22:06 2017 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 A3CA3D961AB for ; Sun, 25 Jun 2017 17:22:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 31F8777358 for ; Sun, 25 Jun 2017 17:22:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PHLiWt085669 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 20:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PHLiWt085669 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PHLidX085668; Sun, 25 Jun 2017 20:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 20:21:44 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625172144.GE3437@kib.kiev.ua> References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <6579B80B-5581-4EBC-895F-5E7ED1D33641@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6579B80B-5581-4EBC-895F-5E7ED1D33641@pozo.com> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 17:22:06 -0000 On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov wrote: > > > > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > >> > >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov wrote: > >>> > >>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > >>>> maybe message got reformatted in mail program (mac mail). > >>>> could you send me a tar file of the patch? > >>>> also not sure if ???patch -p1 >>>> > >>>> you could cc root@pozo.com , that way i have copy on freebsd box and on mac. > >>> > >>> https://people.freebsd.org/~kib/misc/vm2.1.patch > >> > >> OK patched and built new kernel \ > >> rebooted, > >> same ruby message. So it must be a ruby thing. > >> new kdump.txt at http://www.pozo.com/kernel/kdump.txt > >> > >> also i???ll put a copy of my kernel config in same directory: > >> > >> http://www.pozo.com/kernel/pozo > >> > >> only one module is being loaded at boot: > >> (kernel)4908}kldstat > >> Id Refs Address Size Name > >> 1 5 0xffffffff80200000 10380a8 kernel > >> 2 1 0xffffffff8123a000 e13f50 nvidia.ko > >> > >> I can disable nvidia if it helps as I really only access this machine over the net or serial console. > >> > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed something ruby-specific, or rather, triggered > > by ruby special use of libthr. It is not related to the main stack > > split. > > > > It seems that ruby requested very small stack for a new thread, only 5 > > pages in size. This size caused the stack gap to be correctly calculated > > as having zero size, because the whole stack is allocated by initial grow. > > But then there is no space for the guard page, which caused mapping failure > > for it, and overall stack mapping failure. > > > > Try this. > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > Seems to have worked: > > (~)4933}ruby -v > ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > (~)4934} > > No more message. Do you want new ktrace ? Thanks for testing. You might post the trace. From owner-freebsd-current@freebsd.org Sun Jun 25 17:36:39 2017 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 95873D96425 for ; Sun, 25 Jun 2017 17:36:39 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A82C7787F for ; Sun, 25 Jun 2017 17:36:39 +0000 (UTC) (envelope-from null@pozo.com) Received: from 50-197-129-138-static.hfc.comcastbusiness.net (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v5PHYPkG000168; Sun, 25 Jun 2017 10:34:25 -0700 (PDT) (envelope-from null@pozo.com) From: Manfred Antar Message-Id: <2BB1817F-A1CF-44A9-8520-332E2D565EAB@pozo.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Date: Sun, 25 Jun 2017 10:34:25 -0700 In-Reply-To: <20170625172144.GE3437@kib.kiev.ua> Cc: FreeBSD Current To: Konstantin Belousov References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <6579B80B-5581-4EBC-895F-5E7ED1D33641@pozo.com> <20170625172144.GE3437@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-102.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE,J_CHICKENPOX_62,RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v5PHYPkG000168 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 17:36:39 -0000 > On Jun 25, 2017, at 10:21 AM, Konstantin Belousov w= rote: >=20 > On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote: >>=20 >>> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov = wrote: >>>=20 >>> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: >>>>=20 >>>>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov wrote: >>>>>=20 >>>>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: >>>>>> maybe message got reformatted in mail program (mac mail). >>>>>> could you send me a tar file of the patch? >>>>>> also not sure if ???patch -p1 >>>>>=20 >>>>>> you could cc root@pozo.com , that way i have = copy on freebsd box and on mac. >>>>>=20 >>>>> https://people.freebsd.org/~kib/misc/vm2.1.patch >>>>=20 >>>> OK patched and built new kernel \ >>>> rebooted, >>>> same ruby message. So it must be a ruby thing. >>>> new kdump.txt at http://www.pozo.com/kernel/kdump.txt >>>>=20 >>>> also i???ll put a copy of my kernel config in same directory: >>>>=20 >>>> http://www.pozo.com/kernel/pozo >>>>=20 >>>> only one module is being loaded at boot: >>>> (kernel)4908}kldstat >>>> Id Refs Address Size Name >>>> 1 5 0xffffffff80200000 10380a8 kernel >>>> 2 1 0xffffffff8123a000 e13f50 nvidia.ko=20 >>>>=20 >>>> I can disable nvidia if it helps as I really only access this machine = over the net or serial console. >>>>=20 >>> No need, I understood why MAP_STACK failed in this case, thanks to the >>> ktrace log. This is indeed something ruby-specific, or rather, triggered >>> by ruby special use of libthr. It is not related to the main stack >>> split. >>>=20 >>> It seems that ruby requested very small stack for a new thread, only 5 >>> pages in size. This size caused the stack gap to be correctly calculat= ed >>> as having zero size, because the whole stack is allocated by initial gr= ow. >>> But then there is no space for the guard page, which caused mapping fai= lure >>> for it, and overall stack mapping failure. >>>=20 >>> Try this. >>> https://people.freebsd.org/~kib/misc/vm2.2.patch >>=20 >> Seems to have worked: >>=20 >> (~)4933}ruby -v >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] >> (~)4934} >>=20 >> No more message. Do you want new ktrace ? >=20 > Thanks for testing. You might post the trace. New trace at : http://www.pozo.com/kernel/kdump-working.txt Thanks --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sun Jun 25 17:56:25 2017 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 7FDA7D96878 for ; Sun, 25 Jun 2017 17:56:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BA1178040 for ; Sun, 25 Jun 2017 17:56:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.26] (cpe-23-242-94-236.socal.res.rr.com [23.242.94.236]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 55d63e68 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Sun, 25 Jun 2017 10:56:23 -0700 (PDT) To: freebsd-current@freebsd.org From: Pete Wright Subject: Skylake/Kabylake Intel Bug? Message-ID: Date: Sun, 25 Jun 2017 10:56:23 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 17:56:25 -0000 Came across this post today via HN regarding a issue with Hyperthreading causing unpredictable behavior on these CPU's https://lists.debian.org/debian-devel/2017/06/msg00308.html I really wish there was more info on this in the email, for example examples of programs being effected by this bug. Anywho - was wondering if any devs here had more info on this issue and could provide better context? Cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sun Jun 25 18:51:32 2017 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 16746D97826 for ; Sun, 25 Jun 2017 18:51:32 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B121D79A00 for ; Sun, 25 Jun 2017 18:51:31 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PIp9wD002236 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 20:51:09 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PIp7B9002231; Sun, 25 Jun 2017 20:51:07 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 20:51:07 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Konstantin Belousov cc: Manfred Antar , FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: <20170625164115.GD3437@kib.kiev.ua> Message-ID: References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 18:51:32 -0000 On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov wrote: > > > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > > >> maybe message got reformatted in mail program (mac mail). > > >> could you send me a tar file of the patch? > > >> also not sure if ???patch -p1 > >> > > >> you could cc root@pozo.com , that way i have copy on freebsd box and on mac. > > > > > > https://people.freebsd.org/~kib/misc/vm2.1.patch > > > > OK patched and built new kernel \ > > rebooted, > > same ruby message. So it must be a ruby thing. > > new kdump.txt at http://www.pozo.com/kernel/kdump.txt > > > > also i???ll put a copy of my kernel config in same directory: > > > > http://www.pozo.com/kernel/pozo > > > > only one module is being loaded at boot: > > (kernel)4908}kldstat > > Id Refs Address Size Name > > 1 5 0xffffffff80200000 10380a8 kernel > > 2 1 0xffffffff8123a000 e13f50 nvidia.ko > > > > I can disable nvidia if it helps as I really only access this machine over the net or serial console. > > > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main stack > split. > > It seems that ruby requested very small stack for a new thread, only 5 > pages in size. This size caused the stack gap to be correctly calculated > as having zero size, because the whole stack is allocated by initial grow. > But then there is no space for the guard page, which caused mapping failure > for it, and overall stack mapping failure. > > Try this. > https://people.freebsd.org/~kib/misc/vm2.2.patch This patch made ruby23 happy on my end. Can't say the same for emacs-nox11 or temacs while building the former. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 18:55:20 2017 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 9D016D979EB for ; Sun, 25 Jun 2017 18:55:20 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FFC479C27 for ; Sun, 25 Jun 2017 18:55:20 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PItCtk002278 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 20:55:12 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PItCeQ002275 for ; Sun, 25 Jun 2017 20:55:12 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 20:55:12 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Has gdb been disconnected from make installworld? Message-ID: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 18:55:20 -0000 I was at bit surprised to see gdb missing from /usr/bin this evening. The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. This is on base/head r320329. Do we need to add WITH_GDB=yes to our src.conf files? -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 19:04:06 2017 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 A9654D97DCE for ; Sun, 25 Jun 2017 19:04:06 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B4AB7A1D6 for ; Sun, 25 Jun 2017 19:04:06 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5PJ3wnt002361 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 25 Jun 2017 21:03:58 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5PJ3w9G002358 for ; Sun, 25 Jun 2017 21:03:58 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 25 Jun 2017 21:03:58 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: Has gdb been disconnected from make installworld? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 19:04:06 -0000 On Sun, 25 Jun 2017 20:55+0200, Trond Endrestl wrote: > I was at bit surprised to see gdb missing from /usr/bin this evening. > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. > > This is on base/head r320329. > > Do we need to add WITH_GDB=yes to our src.conf files? Ah, they wound up in /usr/libexec. Still, that's an odd place for user software. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Sun Jun 25 19:06:03 2017 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 0019ED97EF8 for ; Sun, 25 Jun 2017 19:06:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 7FF997A361 for ; Sun, 25 Jun 2017 19:06:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5PJ5iGJ008544 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 22:05:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5PJ5iGJ008544 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5PJ5i49008542; Sun, 25 Jun 2017 22:05:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 22:05:44 +0300 From: Konstantin Belousov To: Trond Endrest?l Cc: Manfred Antar , FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625190544.GH3437@kib.kiev.ua> References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 25 Jun 2017 19:06:03 -0000 On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > This patch made ruby23 happy on my end. Can't say the same for > emacs-nox11 or temacs while building the former. What exactly do you mean ? Explain the behaviour and show the ktrace log. From owner-freebsd-current@freebsd.org Sun Jun 25 19:07:33 2017 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 A20F4D97FD2 for ; Sun, 25 Jun 2017 19:07:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 532077A4B3 for ; Sun, 25 Jun 2017 19:07:33 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-807ff70000004226-55-595009ecb629 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 99.DB.16934.CE900595; Sun, 25 Jun 2017 15:07:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5PJ7Noo026537; Sun, 25 Jun 2017 15:07:24 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5PJ7Jh3016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jun 2017 15:07:22 -0400 Date: Sun, 25 Jun 2017 14:07:19 -0500 From: Benjamin Kaduk To: Trond =?iso-8859-1?Q?Endrest=F8l?= Cc: FreeBSD current Subject: Re: Has gdb been disconnected from make installworld? Message-ID: <20170625190719.GD17840@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT133LGRBp0DCf2WLOmw9MFm/bhByY PCasf8PmMePTfJYApigum5TUnMyy1CJ9uwSujBeP97EVfOGqOPDqJlMD4zOOLkYODgkBE4kv +xW6GLk4hAQWM0ncevCABcLZyChx78kPKOcqk8Sbq03sXYycHCwCqhKPJl1kBrHZBFQkGrov M4NMEhHwkehfGggSZhYwlLh9oJcNxBYWsJP4eugnI4jNC7TsbO8ksDFCAuUStx51sEHEBSVO znzCAtGrI7Fz6x02kJHMAtISy/9xQITlJZq3zgbbyingCLTpOthIUQFlib+H77FMYBSchWTS LCSTZiFMmoVk0gJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6Fnq5mSV6qSmlmxjBAe2iuoNx zl+vQ4wCHIxKPLwBa/0ihVgTy4orcw8xSnIwKYnyNvr7RwrxJeWnVGYkFmfEF5XmpBYfYpTg YFYS4Y39BZTjTUmsrEotyodJSXOwKInzims0RggJpCeWpGanphakFsFkZTg4lCR4azkCIoUE i1LTUyvSMnNKENJMHJwgw3mAhmc8BBleXJCYW5yZDpE/xagoJc67jh2oWQAkkVGaB9cLSjgS 2ftrXjGKA70izOvPBlTFA0xWcN2vgAYzAQ2escYHZHBJIkJKqoGxUfPP+xOiEal3f3OFNUpG 2jrcdT6zzLPTeM4xDrW/fBxb5vBcnLGke011QO7vAyFhy8+V3Wd856i4uG/ai93/ChbO2fzm 6fW+kojoK71RjMvdNi3f/z7qasq54rVP/oq8OOqrFBbGG2nWvXbq/kmyssrRAf8LXvYdmXd3 7o3j8f1Wy4yU/i2NVmIpzkg01GIuKk4EAMgqcSgTAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 19:07:33 -0000 On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestl wrote: > On Sun, 25 Jun 2017 20:55+0200, Trond Endrestl wrote: > > > I was at bit surprised to see gdb missing from /usr/bin this evening. > > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. > > > > This is on base/head r320329. > > > > Do we need to add WITH_GDB=yes to our src.conf files? > > Ah, they wound up in /usr/libexec. Still, that's an odd place for user > software. ----------------------------------------------------------------------- r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec. When this option is enabled, only gdb and kgdb are installed to /usr/libexec for use by crashinfo(8). Other bits of GDB such as gdbserver and gdbtui are not installed. For this option to be effective, GDB must be enabled. Rework r317094 to re-enable GDB on all platforms but enable GDB_LIBEXEC on platforms for which the GDB in ports is a superset of functionality. Reviewed by: emaste, kib Suggested by: kib Relnotes: yes Differential Revision: https://reviews.freebsd.org/D10449 ----------------------------------------------------------------------- Note specifically that the GDB in ports is a substantial improvement in functionality on amd64. -Ben From owner-freebsd-current@freebsd.org Sun Jun 25 19:33:03 2017 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 05F9AD98A4F for ; Sun, 25 Jun 2017 19:33:03 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id DB8D57B627 for ; Sun, 25 Jun 2017 19:33:02 +0000 (UTC) (envelope-from bsam@passap.ru) Received: by mailman.ysv.freebsd.org (Postfix) id D807CD98A4E; Sun, 25 Jun 2017 19:33:02 +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 D5E90D98A4D for ; Sun, 25 Jun 2017 19:33:02 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward4o.cmail.yandex.net (forward4o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::289]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89BC07B626 for ; Sun, 25 Jun 2017 19:33:02 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward4o.cmail.yandex.net (Yandex) with ESMTP id 8E59720C5B; Sun, 25 Jun 2017 22:32:50 +0300 (MSK) Received: from smtp3o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 0F34D2940C36; Sun, 25 Jun 2017 22:32:48 +0300 (MSK) Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id m8o8banZ4e-Wlgi2Rk1; Sun, 25 Jun 2017 22:32:48 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1498419168; bh=RnLJcKIhBouHBTmsthpJBfHDe7w3jVyoEjkBE0eHly8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=SE+fUsvAGdTCIsBHhTVwHwiARnC6SqUMnbDiXmS3f4VFs8qYd0zFET3G6GLBV4Vbm Jss6nx5OSkY7wd9oTyEqAiuISLvlXMOZ6qS0UudofHQsA/bjKokXxeOBwhwYXIfStK lkPhovTge6ctgt8KAspTJrBVgEAo9OGwpCBtS6nc= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324 To: Konstantin Belousov , David Wolfskill , current@freebsd.org References: <20170625120731.GE1241@albert.catwhisker.org> <20170625123226.GV3437@kib.kiev.ua> <20170625124748.GT1241@albert.catwhisker.org> <20170625125223.GX3437@kib.kiev.ua> <20170625130521.GU1241@albert.catwhisker.org> <20170625132116.GY3437@kib.kiev.ua> From: Boris Samorodov Message-ID: <5f2c1716-cbc4-2b39-78f3-51cadd0747ad@passap.ru> Date: Sun, 25 Jun 2017 22:32:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170625132116.GY3437@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 19:33:03 -0000 25.06.2017 16:21, Konstantin Belousov пишет: > On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote: >> On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote: >>> ... >>>>> The layout of the struct vm_map_entry was changed, the faulted address >>>>> is somewhat consistent with ABI mismatch. >>>> >>>> Kinky. :-} >>> Do you use any third-party modules ? >> >> On the laptop, I use x11/nvidia-driver-340; on the build machine, no. >> >> I think we should focus on the build machine -- it runs a GENERIC kernel >> without ports (3rd-party) modules. > Ok. > >> >> #cat /etc/src-env.conf >> WITH_META_MODE=yes > > So can you _remove_ all kernel object files and rebuild anew with the > clean build dir, please ? I also use WITH_META_MODE=yes. And full rebuild helped here too. Thank you. -- WBR, bsam From owner-freebsd-current@freebsd.org Sun Jun 25 22:04:29 2017 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 38FB0D9B3A8 for ; Sun, 25 Jun 2017 22:04:29 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wilcox-tech.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 228077F5F7 for ; Sun, 25 Jun 2017 22:04:28 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 5895 invoked from network); 25 Jun 2017 21:53:59 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 25 Jun 2017 21:53:59 -0000 Subject: Re: Skylake/Kabylake Intel Bug? To: freebsd-current@freebsd.org References: From: "A. Wilcox" X-Enigmail-Draft-Status: N1110 Message-ID: <595030E7.1030400@Wilcox-Tech.com> Date: Sun, 25 Jun 2017 16:53:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oWrui7sighJOoOaDG4ciP7MC2HroSsFJr" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Jun 2017 22:04:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oWrui7sighJOoOaDG4ciP7MC2HroSsFJr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 25/06/17 12:56, Pete Wright wrote: > Came across this post today via HN regarding a issue with Hyperthreadin= g > causing unpredictable behavior on these CPU's >=20 > https://lists.debian.org/debian-devel/2017/06/msg00308.html >=20 > I really wish there was more info on this in the email, for example > examples of programs being effected by this bug. Anywho - was wonderin= g > if any devs here had more info on this issue and could provide better > context? >=20 > Cheers, >=20 > -pete >=20 The linked OCaml issue goes quite in-depth with the mechanisms behind this bug and the risks behind not patching the microcode: https://caml.inria.fr/mantis/view.php?id=3D7452 Basically, if a HyperThreaded core is running a tight loop accessing %rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads of the same physical core, it can corrupt/poison L1d cache. AIUI, OCaml manages to generate this code by manipulating tagged memory addresses and the corresponding tag (the address is in %rax, and the tag is at %ah). I'd really love to see if this affects write-through-no-allocate cache or only write-behind, but I haven't seen any program besides OCaml actually manage to get GCC to generate the insn pattern that is needed, and I don't have a Skylake or Kaby Lake CPU to test with anyway. Fun little hardware bug. Hope this helps you, --arw --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --oWrui7sighJOoOaDG4ciP7MC2HroSsFJr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZUDDoAAoJEMspy1GSK50UjTwP/RY1Vm2PsJcVFVrMccqPHVJZ PxvYL6KZrZOj4yfSIJYpB3LAPlrsIqhy6oxWEvF+2aP3FHlIIvswY4v3mAwlNQhc xlwrLQDf1kQARBsVdlGx0Y8jd8SO9Ux2UdHPh7fLqzkGgg0MmRvQH9phfG43CDRk C8qfhgGhwDy2e+RoQ0WahBGhnKtkkVxXB/NEdkouPG5eS9q4nkxBaFuc3IRQOhTh okpaDvHDWVIHt8t68fZKKM2uUm4x8Qpis6iE1LdyzTRNAebmZisIqqvdbDGb4zTb P0rxpKIMQWRBlqbfpTkguy24zXKv5410bxP28bKRGSa6JntkXNB+Wo8bunRWyaQI x0LT2XlpamX2AO9ngjaxjaXgFEVR6+HnyJ3c5tg+WBqI0lWHY71903nYOxkNqKS5 7rIro4DOprursSnusIGxHUV5cinvNGJRBssmA/ZMD6XNRx0xi5EiX8/yQYZEY7zr f2m7VOE0J3GvYZuBaGoMynDYAhehs5voN82VMqYz+AiCI4SNyOHKskJY/Wz/gZIB oKy54jRK14ztnUDTl4tOsvgBBihtoIyzqZlDDYHZ3ThJ6W9D2DQcC44c4scfQww7 6nXks8G9gkpG5DrzfKpsqR5ncppjSssJK+fKQESt8JB9ImRV2YXGAA1YP5fL0V0q cfhi60uHC/EMI01soStK =LCro -----END PGP SIGNATURE----- --oWrui7sighJOoOaDG4ciP7MC2HroSsFJr-- From owner-freebsd-current@freebsd.org Mon Jun 26 00:31:37 2017 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 55004D9D6A2 for ; Mon, 26 Jun 2017 00:31:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 DA2358328E for ; Mon, 26 Jun 2017 00:31:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr0-x22e.google.com with SMTP id 77so131817854wrb.1 for ; Sun, 25 Jun 2017 17:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=DIGHp8JL4GQHyntrwmAKRv8fj04sqtx/ABMYEwD7fz8=; b=GaY782eJjrStaZhwmJKJbfmYnMDnFfGPWU5BnRGAXjGQFbyRCG3GaL9xo7Uiefr4KO USdhfkRW9j6mT/QdAA4xvqYZgOJRlzRtJOKgZ/G2k7d4WSQsUlzILJSJKHsCOowzg+Li fI/pWtRjoobE7HnSIasgjQz58qbZHKyQn6EZcn8GfMfCmekE9V6ztU8hDmQvQaX8XsSO iWt3AFDLGSiO08OeUS/lXstgYvp/HKnxHsVS6JUytDJ+o7cz+5wsv/cIz1Zp5E/uBcIo g3BwR3nyo3L+TnYZY1fYH3U6yoHKjfiVkF41uZuMknI7ERCjjpMXcflyYFTm4GVQhS0x tJiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=DIGHp8JL4GQHyntrwmAKRv8fj04sqtx/ABMYEwD7fz8=; b=SOk/dvk8AAKhnWpl5VOq9YE1Mx2Z+ohwCC31PbFGV8MllIbAhx31GfVE0bqVFyU+AG 4jIQEhmKw/OEnyeAYP5g4eLYFNszUFiSIYzmRyZLD8kesez7smL6oXaOPE1gqYNqAKDg /YW/y7aRHsoW9Wbi9h0cVGK0sggn3xN0ld3gI+pvl+wdtFUATMHMSticIaeWMBZuddKC toUH3qs8qWKVPj5L75c/8ZhadObuYE4+u40M4PzEzIDFEH3caM9ulATPtwqek1YHP3tI P3QYtgPjzFmRxagSEPLhC6BM+0naTkGG4SEnPYFI5AbiEgZSXddYkmdSH1idv6sYh+40 d69Q== X-Gm-Message-State: AKS2vOy/ZQXWqn8RYYpdSnuLHYsgTjQNrAcGC7MHdL6ZAEo7cajAYoUs VrUDwXkwPq8u2zvUF4BsvoGR+rjnhtk+tpR+YxwtR/PtWoSSQSOsd0BrtD+hDk3v/Vr+B6sqrZP Y/9Nq+VoRgKNuxcxb+VmSCOv7wW/DkuYa/VF/GBeOg2nhVK2TP0lRb2IzhZjkdWj9JWt+FQp+Kg == X-Received: by 10.28.52.15 with SMTP id b15mr11525022wma.123.1498437094903; Sun, 25 Jun 2017 17:31:34 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id v13sm14749895wmd.5.2017.06.25.17.31.31 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 25 Jun 2017 17:31:34 -0700 (PDT) Date: Sun, 25 Jun 2017 20:31:29 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Subject: ZFS ABD Panic Message-ID: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uqlkfgnbl4hiplwz" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 00:31:37 -0000 --uqlkfgnbl4hiplwz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is on the latest HardenedBSD 12-CURRENT on one of my servers: [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0xfffff803= b7d4e810 with sleeping prohibited [141] cpuid =3D 5 [141] time =3D 1498436043 [141] KDB: stack backtrace: [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 0002fc8b0 [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fcaa0 [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfffffe000= 02fcb20 [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe00002fcb= 70 [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002fcba0 [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcbf0 pool: rpool state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 mfid0p3 ONLINE 0 0 0 mfid1p3 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 mfid2 ONLINE 0 0 0 mfid3 ONLINE 0 0 0 errors: No known data errors Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --uqlkfgnbl4hiplwz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAllQVd8ACgkQaoRlj1JF bu6b5Q//Umj3q6sMpP9MdlDX+hVXwLJNxRT5AE43EzJ7i3MwkAHIjbjzhxQtCnZv H5mXtDo0JsUDKJfEDtTwZEB8gq1KSwqkcSjt4AffotUnmGXwbKsOvvrJy5RQUFFQ JPPK7SSsguivMvmv8lLVN18zD0aonukYqA6YkvNZdFfgXu6KjAOA8CHI7g0lSq/B gdJIm4gaoVhE5ESUW53F01qNgtYxSfnMe7zvaa9+BpZqEvB3aXpHdpoDne0l0w7n V9e3BsAske3iotA2V0oll/n7Tc0WpkqkLemubHvwkp6GcKIxa470aKBoDnLkNQZl taZgTyb2iNmV25mVcVMRbmAU91+0hDBq0yVPo0yiYedCgPQKGkWIVOFhYfRhuT82 C3chn73dyPnjm0GE9KN4qOp4tY8tX9+O6VwRHPR+PywjdQfDorMGUi1+bQQgInfW m+a0rH0Bj/A3a8YNBlEsAdv5MVtv/ILGjZiBpgc5fkEm8ENVmQ4QEemZeFjhrzHe cwa1ekASGBO19Yx03vkVtTIBKQtmJoNDxdX9Z7lyZ5Cu/tkjMTCaPfcwTldjG66e LI6gKxcD0HX2dOs+FcKrA8NRy1Ps5OwP6aNfBqVj2kGeoONMIV2GpL3tvcgYky6i EP3wfI2ZpzvAi4Od38I1BUrB65LrZ0RMFIT4u07fMTQ/bmmJ5xQ= =loTb -----END PGP SIGNATURE----- --uqlkfgnbl4hiplwz-- From owner-freebsd-current@freebsd.org Mon Jun 26 01:22:06 2017 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 BB444D9E339 for ; Mon, 26 Jun 2017 01:22:06 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5442845D3 for ; Mon, 26 Jun 2017 01:22:06 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.26] (cpe-23-242-94-236.socal.res.rr.com [23.242.94.236]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 74611906 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Sun, 25 Jun 2017 18:22:05 -0700 (PDT) Subject: Re: Skylake/Kabylake Intel Bug? To: freebsd-current@freebsd.org References: <595030E7.1030400@Wilcox-Tech.com> From: Pete Wright Message-ID: <06aeb24f-c725-52c8-5746-fca40c588a20@nomadlogic.org> Date: Sun, 25 Jun 2017 18:22:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <595030E7.1030400@Wilcox-Tech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 01:22:06 -0000 On 06/25/2017 14:53, A. Wilcox wrote: > On 25/06/17 12:56, Pete Wright wrote: >> Came across this post today via HN regarding a issue with Hyperthreading >> causing unpredictable behavior on these CPU's >> >> https://lists.debian.org/debian-devel/2017/06/msg00308.html >> >> I really wish there was more info on this in the email, for example >> examples of programs being effected by this bug. Anywho - was wondering >> if any devs here had more info on this issue and could provide better >> context? >> >> Cheers, >> >> -pete >> > The linked OCaml issue goes quite in-depth with the mechanisms behind > this bug and the risks behind not patching the microcode: > > https://caml.inria.fr/mantis/view.php?id=7452 > > > Basically, if a HyperThreaded core is running a tight loop accessing > %rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads > of the same physical core, it can corrupt/poison L1d cache. > > AIUI, OCaml manages to generate this code by manipulating tagged memory > addresses and the corresponding tag (the address is in %rax, and the tag > is at %ah). > > I'd really love to see if this affects write-through-no-allocate cache > or only write-behind, but I haven't seen any program besides OCaml > actually manage to get GCC to generate the insn pattern that is needed, > and I don't have a Skylake or Kaby Lake CPU to test with anyway. > > > Fun little hardware bug. > > > Hope this helps you, > --arw Thanks this is really helpful! From the dire warning of the debian thread I was worried this was a very easy to run into runtime issue. Certainly sounds pretty darn serious, but having context at least gives me something to keep any eye out for as a syadmin - this def seems like a potentially interesting attack surface (as most CPU bugs tend to be) :) i've got a couple effected CPUs that i use for dev purposes - might see if i can reproduce on my end just for shits and giggles. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Jun 26 03:46:02 2017 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 881EADA067F for ; Mon, 26 Jun 2017 03:46:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 111EB64647 for ; Mon, 26 Jun 2017 03:46:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id k67so134243379wrc.2 for ; Sun, 25 Jun 2017 20:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0iJXsk293xuS+PGlpxGWluhJwSAWNv0RsKAZfwPtc+k=; b=SCgYpHkvxA1PLicKxrnvCLocvFkm1IGul/DY7odhJOwF63DpozZo/WrZcTkv6Ntk8d QxU2JiyWFJrPBIzpGMDN8nmHen3zVVNh0vXTdT9M4T2vCNvsfWd+/sBSrdOaqmQbIIez f0Rv22rHt8npBuSeJK7awezKbySeN9wVYy9lqJc0Qgg0nZ16DZZcu6L1v0d4YUtTNMvb wOhk6swmf46lxNSTkacZXJ+Ll/JjsJARPNFO8Ik4/0zSX6docld4QuocwyrUKsSdYhPs SiP1rFMcWZp9BlnMOchWarcWViVmksFLmgDsplKBpEaZ6CnSqMHenzvl36NR56T364Nb 6RVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0iJXsk293xuS+PGlpxGWluhJwSAWNv0RsKAZfwPtc+k=; b=BQKWIugoaOdDWlTM7JTtBUOSpv75X3ZcHiEDT49v7Q3kalA2CnoOFrLIdt5OVBNz6n PIU2YMspGdoca+yUkQXrtuoOnCA7UW7lCX7GSCWTepla9QkhwZOgYYr/2e11xAiIIrcb yKshHNiUo+gRAzVfrwHyslI2PgZ7W7vdQ8MyHKR6RrxKu4LBq7LPDIilIjctICY3YW+l f6z3+3J2LpY9u/MXi8kis4Zc3AaYBXNAEVVIGQ+BwYNvwTFN3SbxO39OvbOhPvcgsCzx FypDeqaxeFEMH3W+6SC2et5n+j5SSAkl7Sq+ee/dYTYV0L1W1dCp1vzv5NujtXS+6QFl 7RBw== X-Gm-Message-State: AKS2vOwRqW+7ykqfJNfib/+EJhFZtcNBrqxi/SVALf5eSdWv9/hcwP8x 9DBa8iBCB3bwkTzXlmpNZpsaLXGtNw== X-Received: by 10.223.134.117 with SMTP id 50mr12938941wrw.62.1498448760653; Sun, 25 Jun 2017 20:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.183.138 with HTTP; Sun, 25 Jun 2017 20:45:59 -0700 (PDT) In-Reply-To: <89.F1.03057.D331E495@dnvrco-omsmta02> References: <78.25.03057.F5ADD495@dnvrco-omsmta02> <89.F1.03057.D331E495@dnvrco-omsmta02> From: Adrian Chadd Date: Sun, 25 Jun 2017 20:45:59 -0700 Message-ID: Subject: Re: Ports still broken by ino64? To: Thomas Mueller Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 03:46:02 -0000 Hi, valgrind broke as part of the ino64 work :( -a From owner-freebsd-current@freebsd.org Mon Jun 26 03:59:23 2017 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 5B81BDA08A6 for ; Mon, 26 Jun 2017 03:59:23 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 CC09864AD6; Mon, 26 Jun 2017 03:59:22 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-695ff70000003819-84-5950869566f6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id F5.F8.14361.59680595; Sun, 25 Jun 2017 23:59:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5Q3xGA4032421; Sun, 25 Jun 2017 23:59:16 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5Q3xBSm015133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jun 2017 23:59:14 -0400 Date: Sun, 25 Jun 2017 22:59:12 -0500 From: Benjamin Kaduk To: Adrian Chadd , Renato Botelho Cc: Sean Bruno , freebsd-current Subject: Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11 Message-ID: <20170626035911.GA68391@kduck.kaduk.org> References: <1c1e5c6f-35e5-ca14-2e23-5e33d86a5266@FreeBSD.org> <0e951324-7ec9-445d-06d0-64682cea6da4@FreeBSD.org> <20170624042246.GX39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170624042246.GX39245@kduck.kaduk.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT153aFhBpMHcTv8Xzj3wWc958YLJY dOk1o0VP7wlGBxaPGZ/ms3jsnHWXPYApissmJTUnsyy1SN8ugSujd9URxoIXzBWtu5ewNDA2 MncxcnJICJhIrP52ngXEFhJYzCRxdJ1KFyMXkL2RUeLbuxnsEM5VJok3Z+4yglSxCKhK7N1x mB3EZhNQk3i8t5kVxBYR8JVY+X8DmM0sEC0x5eMbJhBbWCBB4vqZhWDbeIG2rd/fCzV0GrPE 21WfoRKCEidnPmGBaNaSuPHvJVAzB5AtLbH8HwdImFPAVOLX17dgN4gKKEv8PXyPZQKjwCwk 3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjOHBdVHcwzvnr dYhRgINRiYc3wzIgUog1say4MvcQoyQHk5Iob6O/f6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed6uSqBy3pTEyqrUonyYlDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCd28rUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8HO1IMOLCxJzizPTIfKnGHU5mj5s+cIkxJKXn5cqJc57vQWoSACk KKM0D24OKOFIZO+vecUoDvSWMO9UkHU8wGQFN+kV0BImoCUz1viALClJREhJNTBGcTDXHMw4 ynH0jMoB/bptWY5TSqTO/K1y57vgWLDx2qZN1aUbl9fLMevFbv74cb3N/KDGh57MeY9lbn1W Z3u9WI/jzUthdhGTeXfPO+nsNb3aedy10LtpYdbW3T+ZHquYlXxeERVfMHXyCYWu5uexN679 inZU7pj7rLXxdOSEWy7Cd6b7OF5RYinOSDTUYi4qTgQA0+NUDRMDAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 03:59:23 -0000 On Fri, Jun 23, 2017 at 11:22:46PM -0500, Benjamin Kaduk wrote: > I fixed the rc.conf snippet in the handbook in r50399. > I lost track of the rest of the thread as to what needs to be > changed in the actual command examples in lagg.4 and/or the > handbook, though. To be clear, that is: one of you please supply the correct commands to execute this configuration manually (i.e., not via rc.conf), or the rest of the documentation is unlikely to get updated. Thanks, Ben From owner-freebsd-current@freebsd.org Mon Jun 26 05:30:57 2017 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 E3FB2DA1BFD for ; Mon, 26 Jun 2017 05:30:57 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.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 CEC0E6689F for ; Mon, 26 Jun 2017 05:30:57 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id CAE07DA1BFC; Mon, 26 Jun 2017 05:30:57 +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 CA522DA1BFB for ; Mon, 26 Jun 2017 05:30:57 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9045E6689E for ; Mon, 26 Jun 2017 05:30:57 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dPMbt-0006tg-VP for current@freebsd.org; Mon, 26 Jun 2017 07:30:54 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dPMbt-0001uQ-UM for current@freebsd.org; Mon, 26 Jun 2017 07:30:53 +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); for ; Mon, 26 Jun 2017 05:30:53 GMT From: "Jeffrey Bouquet" To: "current" Subject: status of and/or url to check base packages repo somewhere? Date: Sun, 25 Jun 2017 22:30:53 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 05:30:58 -0000 As the Subject: is there a canonical url to check, and a procedure in pla= ce yet, to,=20 for instance, if one cannot buildworld on 12.0-CURRENT, to access the packa= ge .txz or=20 whatever and 'pkg fetch ... pkg add ...' which would substitute for the bu= ildworld=20 cycle? Also, one would be rebooted into a GENERIC kernel, ... and other de= tails ? .... =20=20= From owner-freebsd-current@freebsd.org Mon Jun 26 05:45:04 2017 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 A41CBDA20A7 for ; Mon, 26 Jun 2017 05:45:04 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 81BC56715D for ; Mon, 26 Jun 2017 05:45:03 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:54002] helo=localhost) by dnvrco-omsmta01 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 50/A5-03935-85F90595; Mon, 26 Jun 2017 05:44:57 +0000 Date: Mon, 26 Jun 2017 05:44:52 +0000 Message-ID: <50.A5.03935.85F90595@dnvrco-omsmta01> From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Ports still broken by ino64? References: <78.25.03057.F5ADD495@dnvrco-omsmta02> <89.F1.03057.D331E495@dnvrco-omsmta02> X-RR-Connecting-IP: 107.14.64.6:25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 05:45:04 -0000 from Adrian Chadd: > valgrind broke as part of the ino64 work :( Valgrind was not on my mind! Your post sent me to ls -d /usr/ports/*/val* to find valgrind, and then read the pkg-descr. One less tool for getting debugging information when something crashes? Tom From owner-freebsd-current@freebsd.org Mon Jun 26 07:52:34 2017 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 4C7D1DA3E66 for ; Mon, 26 Jun 2017 07:52:34 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E42276E6DF for ; Mon, 26 Jun 2017 07:52:33 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5Q7qNqN036229 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 26 Jun 2017 09:52:23 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5Q7qNQA036226 for ; Mon, 26 Jun 2017 09:52:23 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Mon, 26 Jun 2017 09:52:23 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: Has gdb been disconnected from make installworld? In-Reply-To: <20170625190719.GD17840@kduck.kaduk.org> Message-ID: References: <20170625190719.GD17840@kduck.kaduk.org> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 07:52:34 -0000 On Sun, 25 Jun 2017 14:07-0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestl wrote: > > > Ah, they wound up in /usr/libexec. Still, that's an odd place for user > > software. > > ----------------------------------------------------------------------- > r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines > > Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec. > > When this option is enabled, only gdb and kgdb are installed to > /usr/libexec for use by crashinfo(8). Other bits of GDB such as > gdbserver and gdbtui are not installed. For this option to be > effective, GDB must be enabled. > > Rework r317094 to re-enable GDB on all platforms but enable > GDB_LIBEXEC on platforms for which the GDB in ports is a superset of > functionality. > > Reviewed by: emaste, kib > Suggested by: kib > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D10449 > ----------------------------------------------------------------------- > > > Note specifically that the GDB in ports is a substantial improvement in > functionality on amd64. > > -Ben Good to know. Thanks. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Mon Jun 26 08:08:48 2017 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 3D6C1DA4281 for ; Mon, 26 Jun 2017 08:08:48 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 EC9186ECAB for ; Mon, 26 Jun 2017 08:08:47 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-ua0-x230.google.com with SMTP id j53so63245189uaa.2 for ; Mon, 26 Jun 2017 01:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QXDoLnAPjNzglBwIUzPxqKnd3PGggFk+QBWsXGq5JJ0=; b=MJJEAkDVLfJp8ROvMOQeJKGQQPLWlh8VaGPSj5JZt7YS/swYXJ76AFhxKD/EsM9OaI ta6fSNIo2qXE0ZTv/F2cs24UHygLnUlrXjomHl7FdLyyA7A9TXimETPcwQppNM6AEr3h 0Vphs49SNuln9v8IwmXYmFH9jNTlYaISt06HUkOGRKpUH6eexgy3LCrmexKrbiwbDauC wnLi6em/X6bOornhB+g2jAgKEktcmy9os6jnpkXrdRqxcGPHyKqEg2awP3kIAL8et9Bh qoiDdEM5PeXrgjdeBgmK/cMvvfHMkIXJJ8FCSUscnEj+bwjR7VcsvBDnbi3HB3iuJT1g KLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QXDoLnAPjNzglBwIUzPxqKnd3PGggFk+QBWsXGq5JJ0=; b=j8gprlz5JcLLqgR/U4nVXLI0Y34rR5jDm5mhH7RFgiRDXOPZN66MkC6CIYFSEC9AAk KZEx2hJ4l36kqFi9NMkjnrurm3m3HN3o6u0bA15Awthj74Urshu1+vZUt5u2Qnwk7xd7 fKoK8LkbWpYB7dWVt+tGZswqt1A+FsFRev52JnOSHYcgjjt75I+wW1Ik9NGkKgauXtxO iwxeb8qUgWj5reSISQ68Vmfhsly9azJByeeR3oOxYrmdd68En66rGdSbL2G8TKfY4owz 6IXvKJVNYhh7vrAV9kdZUK+BKyNF8Fl3nXEah2Q09q1950Lb+gtr1bjNRC6Lf1sPVwEV HynA== X-Gm-Message-State: AKS2vOxxWZm2B/FR0avbVpYalPt/O6u2zyIiw/DnVR9rqV+CEOcR3CT1 nx6ZUb4tgXXTzkXlc7bbN/DHfN0cEp0s X-Received: by 10.176.17.239 with SMTP id q47mr13027030uac.29.1498464527013; Mon, 26 Jun 2017 01:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.36.195 with HTTP; Mon, 26 Jun 2017 01:08:46 -0700 (PDT) In-Reply-To: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> From: Oliver Pinter Date: Mon, 26 Jun 2017 10:08:46 +0200 Message-ID: Subject: Re: ZFS ABD Panic To: Shawn Webb Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 08:08:48 -0000 On Monday, June 26, 2017, Shawn Webb wrote: > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan > 0xfffff803b7d4e810 with sleeping prohibited > [141] cpuid = 5 > [141] time = 1498436043 > [141] KDB: stack backtrace: > [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00002fc8b0 > [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 > [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 > [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 > [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fcaa0 > [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 > [141] refcount_remove_many() at refcount_remove_many+0x2a/frame > 0xfffffe00002fcb20 > [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 > [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame > 0xfffffe00002fcb70 > [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002fcba0 > [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 > [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 > [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcbf0 > > pool: rpool > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > rpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > mfid0p3 ONLINE 0 0 0 > mfid1p3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > mfid2 ONLINE 0 0 0 > mfid3 ONLINE 0 0 0 > > errors: No known data errors What's the corresponding git note? > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-current@freebsd.org Mon Jun 26 08:35:31 2017 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 1EB09DA4786 for ; Mon, 26 Jun 2017 08:35:31 +0000 (UTC) (envelope-from o.hartmann@walstatt.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 001B26F6B3 for ; Mon, 26 Jun 2017 08:35:30 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id F31A8DA4785; Mon, 26 Jun 2017 08:35:30 +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 F0FB8DA4783 for ; Mon, 26 Jun 2017 08:35:30 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FA5C6F6B2 for ; Mon, 26 Jun 2017 08:35:29 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MAloF-1dbH7A3GGZ-00BsI9; Mon, 26 Jun 2017 10:29:55 +0200 Date: Mon, 26 Jun 2017 10:29:47 +0200 From: "O. Hartmann" To: current@freebsd.org Cc: David Wolfskill , Boris Samorodov , Konstantin Belousov Subject: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170625120731.GE1241@albert.catwhisker.org> References: <20170625120731.GE1241@albert.catwhisker.org> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cVQnWl2h9IcH7SFdQ8JTwFPiMradkCPBT3NHg+Mw6Ie7voeVrH5 D2cZmGcNaBMzgUmXr4PwD2N+lkQ4HoiOXuVI0Np8GwXTvrnLbmoQP8VyqEswmO9rOj0vdp7 Xruqv19JwRGo5iyHEVxRmX8p+fiR6+qRNOAXhkP/8Z5QpvTkKG0GtwUfDdMc8aoKM6HmBml ljJW5zudjXz7MeKLlKTow== X-UI-Out-Filterresults: notjunk:1;V01:K0:1kquu7xfLuo=:5pgUDKOwGuM6j7aJ9GJGXk W0M1CUp/bqxZuLlM017Dw+3A1l970lC2x4l9gg6CKynDf9U+sFJcMBf3yfyuQWfS81VbKskaa U6RMQyRFFcpQnypBjYp9wtKdMfmWU6wzidP5oLI4l12U8UPzEHGj7SYYoa0rm2v4oaaOFUkUa E9adSCHm2CCo4OYANRSBagUTDjVUV9+O+LLOxbdaOP36HdNn2c9/BQMfGIF2feLUYeuObI/TE 6XLEnIOxpGQ6d7jFYZ50cUBC5DKSa2d4lMLbTYbubo+D1aj7K/HQ6F/m7Jhxjxmg9ZElfnIPe 2BuaPEQqUZnKWsa6jJ+CWNMLWFXvTMFyRIwcj3MTKRrRvbRXUzF2iKqPS7y6zzG3dCzZ0lhO7 6t7d10TERhMvim3gaxasqzDbbaRUfEW0eYjDp6pPUIXS7vcYTVCQGO3k0LROpgLAmd3bWWISX likLDQrV5Bl8oQvUMA1fKl43VdnFM3Ug9UnC6ODYR2j8tIcAj5DAnracn11U4eQnxMWFkdxiq vjGPBp6r/q91GPsTnaQcDUw4oXdbOOFWJuWlr6eRwhbGByeYXxn2YU8146OQnLus7+4CH9bIW B37Lzy1pywF462gwDvjb5Ruy15h5JrOwCkkkPFMUWEkSIaFGYb5joa0YD1Bm16SKb8/hxd5Id dfbFxfa40TY2bdjoqFRZeUPHdSww/2Oe5vo0FcbMlHXDs2pxV3SrsvyrIKMCiJCuaRqBLI88F uGH4CSUD7/gjkvHLnHO2SS3t0cpYgPgKB63GVm7rtn0ccu9EqVmN+0KB09Lu18qJFtfePSzA1 v3gHr+n X-Mailman-Approved-At: Mon, 26 Jun 2017 10:58:58 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 08:35:31 -0000 Over the past week we did not update several 12-CURRENT running development hosts, so today is the first day of performing this task. First I hit the very same problem David Wolfskill reported earlier, a fatal trap 12, but fowllowing the thread, I did as advised: removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all over the place) and recompiling world and kernel. Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the INO64 update hasn't performed so far starting from r319971, I installed the kernel, rebooted the box in single user mode (this time smoothly), did a mergemaster and tried to do "make installworld" - but the box instantanously bails out: [...] Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthread/thr_init.c pid 60 (cc) uid0: exited on signal 6 ... [...] That way, I obviously can not install a world :-( What is wrong here? Is the problem resovable? Kind regards, Oliver From owner-freebsd-current@freebsd.org Mon Jun 26 11:22:54 2017 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 70B9CDA76FA for ; Mon, 26 Jun 2017 11:22:54 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 09D0474392 for ; Mon, 26 Jun 2017 11:22:53 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x235.google.com with SMTP id b184so4800872wme.1 for ; Mon, 26 Jun 2017 04:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=CDPq6+wZbVUmroG+bV3OOEU7KWf2ruBAMfq/w+s1E6c=; b=fjgKxk6fiL2YX6uJzfJZtpvp9uM1ZuYAlj07CLHqqOFYQljmw4lYMOrmZB+5ByQmrG UzJiRL4tE4s21c5PzlEdd/orbQ/HdlJhGDREZ31wV6zbMs/eJmNC8m3sycRatCxJ5VDu wGEQLZnwbAWeFJ+Rb3FKJHAyW1HPoVm174hXvquo2uaciaxVmJwGKYLYUsqez2F4CwHj Y6ls3PcVHVNzRyv3HPqmNhhsn0hFsOQfgTMjPpZ7hBIV9YTYgx0UCHKQXN+2jBehcG2m wHArl8g56hRLIRj5/JfIZ31Q0uHl705dtyiEzCZttn2G/cSoFkfgtR6TB1k73BoXlRV1 B20Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=CDPq6+wZbVUmroG+bV3OOEU7KWf2ruBAMfq/w+s1E6c=; b=aDb4YEL5VRtVmOG7vpySeRtmV17rkM6Kd0uk/criIlLjm7hllJLopoV23Faz2xkQYo hRa7sDAVtkrM9BVk+M7N9/quDnFEWswqAOsTGREnBXVtnMHAxX7LUoIJvBWQe6+qiu6/ DjDB/s4ecEbxXXEOLyTcGiaQf41rDJo77qUcd32tVXAxwqovf96swCICaM8IpFaaKMJ0 /ip2Vg2EutrLcSDd3UMGDwR5WZ81K4PDyWlLhdbnMJv7/bxd8f2pnqjdrLIfG+eEJnFg 1TOMZd7YwG2xAilzRl79paFHRpERbAo5GbgPggh2AKkSmTQAN5XnhkIQT51ZjrlbLfTH kmoQ== X-Gm-Message-State: AKS2vOwT8AGOzgR1+lIVI5HQunnvk0wLlKNCPn+8uTaqghxLY0+a/aLG Ez0EKZ/KtbQWfJL6O3vT5g== X-Received: by 10.28.93.197 with SMTP id r188mr2899338wmb.44.1498476171684; Mon, 26 Jun 2017 04:22:51 -0700 (PDT) Received: from [10.10.1.111] ([185.97.61.15]) by smtp.gmail.com with ESMTPSA id n131sm8601170wmg.11.2017.06.26.04.22.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 04:22:50 -0700 (PDT) Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' To: freebsd-current@freebsd.org References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> From: Steven Hartland Message-ID: <6bd6a816-dbe4-1abf-f01b-da3afb03930c@multiplay.co.uk> Date: Mon, 26 Jun 2017 12:22:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:22:54 -0000 Is this related to kib's additional fix over the weekend? https://svnweb.freebsd.org/changeset/base/320344 Regards Steve On 26/06/2017 09:29, O. Hartmann wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > completely (we use filemon/WITH_META_MODE=YES all over the place) and > recompiling world and kernel. > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... > > [...] > > That way, I obviously can not install a world :-( > > What is wrong here? Is the problem resovable? > > Kind regards, > > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 26 11:26:16 2017 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 F20FEDA77F4 for ; Mon, 26 Jun 2017 11:26:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CB0B3744FD for ; Mon, 26 Jun 2017 11:26:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C75EEDA77F3; Mon, 26 Jun 2017 11:26:16 +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 C6F70DA77F2 for ; Mon, 26 Jun 2017 11:26:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 5C39C744FC for ; Mon, 26 Jun 2017 11:26:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x244.google.com with SMTP id z45so29133734wrb.2 for ; Mon, 26 Jun 2017 04:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=4kQTmXRwfGGfucPqdvjpNHAP5nHxWP3D3uUgAvnF9+8=; b=gzzkJiVc8zOmc2r4Ns3iSDtUOTbRZ8GAswy2Ghn8xLucSJ+Zz/2mOoY9ReWMgQ3Yoz zEe5bvRSk/2fkQw5glLt9nRQjf5qnc5eijdfKXSxplrC8AWX0luhY2VDn1kY+WMTDftY 7Q2sgS8qXfL/+WfQ1oyTIKySXJKZlBc8fYcMKRPi2zGBEqdNn4B1Qts0wKUh8ZK5A/+4 nXBQRu4+/qZ/s9Dd2VHTMJZXJIcDwhXTyfkH8q2qkZ6Ijnk3c+oHhhvYLqiXAtAVdG0c XbTDUi6RuyftavkB4HitHm+E3vfBvl9Jybnjqsqwo98hQs2ecobJa4w9+kw5fF3UZCLL hrrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=4kQTmXRwfGGfucPqdvjpNHAP5nHxWP3D3uUgAvnF9+8=; b=SNqYVBodLUn4i1/oQtn2UhunlDpItWi9TZwHOLQK1dIeGsvUjBSO4Nd1QrBsVmzobn WiKKUXP64YvXhAz7+RMRKSlqePb1nqUhs9HoEgFxiXlZzZiFC07N+32CbFIuxSf/+w2+ lWK5olD8lTcbtaYbelThGssA9gt4gW69H7VF0IKTBgG5dYzIPILSy7osllEVQ4XBuJqf qIvdj+fiq0uMkJ6feEnu72PBLmYcz0PkAinuAmFscmFv50mIkFTk9+2/+4OJ32arfxv5 gvv0rvh6cbdx49dDmQNc8sWEXcynUFMM9Wh4iM+NldAyIDVnmnRSsloN3nTMfCvNkkef 8kWA== X-Gm-Message-State: AKS2vOzMuUDZlYR/WBTHEAp07NdiLy8diAr5qAvLdIsILyaI8LMitR9z 0ATR8iT/OyehJje0 X-Received: by 10.223.153.165 with SMTP id y34mr13149479wrb.41.1498476374683; Mon, 26 Jun 2017 04:26:14 -0700 (PDT) Received: from ernst.home (p4FCA6CDA.dip0.t-ipconnect.de. [79.202.108.218]) by smtp.gmail.com with ESMTPSA id f21sm16754625wra.5.2017.06.26.04.26.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Jun 2017 04:26:14 -0700 (PDT) Date: Mon, 26 Jun 2017 13:26:08 +0200 From: Gary Jennejohn To: "O. Hartmann" Cc: current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626132608.03eab0cf@ernst.home> In-Reply-To: <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:26:17 -0000 On Mon, 26 Jun 2017 10:29:47 +0200 "O. Hartmann" wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > completely (we use filemon/WITH_META_MODE=YES all over the place) and > recompiling world and kernel. > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... > > [...] > > That way, I obviously can not install a world :-( > > What is wrong here? Is the problem resovable? > How recent was your last update? Some changes were made just a few hours ago to fix a stack growth problem in threads. Either your source is not up to date, or a new bug was introduced by the intended fix. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Mon Jun 26 11:28:03 2017 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 BC14CDA7932 for ; Mon, 26 Jun 2017 11:28:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CC41746F4 for ; Mon, 26 Jun 2017 11:28:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5QBRqMY037380 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 26 Jun 2017 13:27:53 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5QBRqta037377 for ; Mon, 26 Jun 2017 13:27:52 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Mon, 26 Jun 2017 13:27:52 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' In-Reply-To: <6bd6a816-dbe4-1abf-f01b-da3afb03930c@multiplay.co.uk> Message-ID: References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <6bd6a816-dbe4-1abf-f01b-da3afb03930c@multiplay.co.uk> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:28:03 -0000 On Mon, 26 Jun 2017 12:22+0100, Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 Attempting to run r320348 with no patches applied proved unfruitful earlier today. I had partial success the weekend building r320328 with the vm2.2.patch applied while running r320293. https://people.freebsd.org/~kib/misc/vm2.2.patch You might want to stay at pre-r320316 until the matter is resolved. > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > Kind regards, > > > > Oliver -- Trond. From owner-freebsd-current@freebsd.org Mon Jun 26 11:28:49 2017 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 624F7DA7A6F for ; Mon, 26 Jun 2017 11:28:49 +0000 (UTC) (envelope-from david@catwhisker.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 4745B7488C for ; Mon, 26 Jun 2017 11:28:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4668ADA7A6D; Mon, 26 Jun 2017 11:28:49 +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 45EA5DA7A6C for ; Mon, 26 Jun 2017 11:28:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 EAE7B7488A for ; Mon, 26 Jun 2017 11:28:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5QBSkSo014348; Mon, 26 Jun 2017 11:28:46 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5QBSkfO014347; Mon, 26 Jun 2017 04:28:46 -0700 (PDT) (envelope-from david) Date: Mon, 26 Jun 2017 04:28:46 -0700 From: David Wolfskill To: "O. Hartmann" Cc: current@freebsd.org, Boris Samorodov , Konstantin Belousov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626112846.GK1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "O. Hartmann" , current@freebsd.org, Boris Samorodov , Konstantin Belousov References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C8M3rclghDj+srEw" Content-Disposition: inline In-Reply-To: <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:28:49 -0000 --C8M3rclghDj+srEw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > ... > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and = the > INO64 update hasn't performed so far starting from r319971, I installed t= he > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanou= sly > bails out: >=20 > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... My head update this morning was from r320324 to r320353; I did not encounter the above. (I did, however, encounter an inability to load tmpfs.ko; I will describe that issue in a separate thread.) > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --C8M3rclghDj+srEw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZUO/uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XFTYIALMkJic/hqhzcUz4T/mraNdh dVtcrj7cXcXnX6HCkvmz19LQTWs+iPNViDTmWIIxg85tk6FxTz3S05VjzO/R1nPF Lq0L4xuy3ncs9mWH7fOxvsuuIR2ACQ6l+AE8oolstgeg5fFITPCNTOb9GkarhU8h MkJUr1CHPKH1mu85Xq0wFDJiGE8lngyjHqJrkjC+IypE4Pd+c05aa6Gkdn7fc3ta XMBvZG+x1HVEj7mIondLTwG482FIddWEsDPmKsH3p+Myd7nmS/NIZEek9JQ3Ct5X z+hS4WIrt4xQ8IzGBWFHTJVxotT7BRiqddKHjHMyP0uJkLeCPRcQWz3BQ7lXVVw= =93gw -----END PGP SIGNATURE----- --C8M3rclghDj+srEw-- From owner-freebsd-current@freebsd.org Mon Jun 26 11:31:53 2017 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 1682BDA7C88 for ; Mon, 26 Jun 2017 11:31:53 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 AD90074AE0; Mon, 26 Jun 2017 11:31:52 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id 16so14021807qkg.2; Mon, 26 Jun 2017 04:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JAsdcgc+qbTQWNbJxjf+0ClafSlRQyjGtUzdAK/DnwA=; b=IEoo0xMLD5v9f9ggnuUoBKrh5qhAYYD9IwJhHA8Qifd2ThXgjQzXVgITpPReL5mUy/ CtEXtM00zpw8BsWSfDJpqAS2Mh82YulkFfuS2ItbUYN16gBQEeFBTO6iAUE20BVswvTw On+Kgez4DYh7zROK1fJcREbt56sDGkPT3KQJ/5Exe9apRcf5Eb+jwkpowbppkRy3pQnw l49cj4RXK3HdYBsAUvyqeUN7b9PsMhY36uWrC9j0kp4/C+GElbU+2NXqL4eSnfXiEh3Y wlmxDzjsRPVFjF91XKUTLVpAUYRwL2gmWutWnQBIZZ0kcA+VLzwm+QhMkdVh1qQcrQ+/ 3jrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JAsdcgc+qbTQWNbJxjf+0ClafSlRQyjGtUzdAK/DnwA=; b=NPEjup8H4admPt7OprZqFvyPIVGDN22CShR7SjYpufrINRzFSRILPLW76Vkx0mI586 GkfU2YbdUbnw85s68yspZ7U1Ncf3Dem9JT5SzOxQSMwapVF3RWH/e/QHWyC3mWnFo//g hD4rKN8YBLi5sLP9FaHDyerZ4SgXnww+MU4zEs2H6cVGORLcZJNc6JVp45uHIVPb76ui ABo300ZdnwLab1wKY7ffBTCoVxw6lDrVjsE/44TNcXM/05iiCljqyyJcaIHbW8WyZRzs 0DrKDPqzkScwCCaGtZVCouL6Z+DKOKKihNwhVBCaE1s9rqS9ilqWZD9H3l7DbPiL6hjq tD8A== X-Gm-Message-State: AKS2vOylg6fl+0JAFNh4rwu1wbx5Q97GBh2qxmcaTrr+1QRA62yoA1Tc icM/qrDxWW5PtihQdgs= X-Received: by 10.55.79.198 with SMTP id d189mr21865139qkb.37.1498476711718; Mon, 26 Jun 2017 04:31:51 -0700 (PDT) Received: from mbp-eth.home ([177.53.86.172]) by smtp.gmail.com with ESMTPSA id t11sm8015870qke.69.2017.06.26.04.31.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 04:31:50 -0700 (PDT) Sender: Renato Botelho Subject: Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11 To: Benjamin Kaduk , Adrian Chadd Cc: Sean Bruno , freebsd-current References: <1c1e5c6f-35e5-ca14-2e23-5e33d86a5266@FreeBSD.org> <0e951324-7ec9-445d-06d0-64682cea6da4@FreeBSD.org> <20170624042246.GX39245@kduck.kaduk.org> <20170626035911.GA68391@kduck.kaduk.org> From: Renato Botelho Message-ID: <7eaa28b3-484a-a779-1ab3-dada3d9318f6@FreeBSD.org> Date: Mon, 26 Jun 2017 08:32:03 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170626035911.GA68391@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:31:53 -0000 On 26/06/17 00:59, Benjamin Kaduk wrote: > On Fri, Jun 23, 2017 at 11:22:46PM -0500, Benjamin Kaduk wrote: >> I fixed the rc.conf snippet in the handbook in r50399. >> I lost track of the rest of the thread as to what needs to be >> changed in the actual command examples in lagg.4 and/or the >> handbook, though. > > To be clear, that is: one of you please supply the correct commands > to execute this configuration manually (i.e., not via rc.conf), or the > rest of the documentation is unlikely to get updated. On lagg(4): # ifconfig em0 up # ifconfig create wlan0 wlandev ath0 ssid my_net \ wlanaddr 00:11:22:33:44:55 up # ifconfig lagg0 create # ifconfig lagg0 laggproto failover laggport em0 laggport wlan0 \ 192.168.1.1 netmask 255.255.255.0 On Handbook [1]: Following line should be removed: # ifconfig iwn0 ether 00:21:70:da:ae:37 And the next example command should be changed to: # ifconfig wlan0 create wlandev iwn0 ssid my_router \ wlanaddr 00:21:70:da:ae:37 up The rc.conf block looks fine. Thank you for taking care of it. [1] https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless -- Renato Botelho From owner-freebsd-current@freebsd.org Mon Jun 26 11:44:20 2017 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 BC939DA7F3B for ; Mon, 26 Jun 2017 11:44:20 +0000 (UTC) (envelope-from kostikbel@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 A1C2B75098 for ; Mon, 26 Jun 2017 11:44:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9DD01DA7F38; Mon, 26 Jun 2017 11:44:20 +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 9D21CDA7F37 for ; Mon, 26 Jun 2017 11:44:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3130975097 for ; Mon, 26 Jun 2017 11:44:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5QBiASU028852 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 14:44:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5QBiASU028852 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5QBiACX028851; Mon, 26 Jun 2017 14:44:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Jun 2017 14:44:10 +0300 From: Konstantin Belousov To: "O. Hartmann" Cc: current@freebsd.org, David Wolfskill , Boris Samorodov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626114410.GN3437@kib.kiev.ua> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 26 Jun 2017 11:44:20 -0000 On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > completely (we use filemon/WITH_META_MODE=YES all over the place) and > recompiling world and kernel. > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... It is strange that cc is executed during installworld. Anyway, show ktrace of the failure. From owner-freebsd-current@freebsd.org Mon Jun 26 11:54:44 2017 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 B47DCDA8304 for ; Mon, 26 Jun 2017 11:54:44 +0000 (UTC) (envelope-from david@catwhisker.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 9C4E975608 for ; Mon, 26 Jun 2017 11:54:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 98BFEDA8303; Mon, 26 Jun 2017 11:54:44 +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 9836BDA8302 for ; Mon, 26 Jun 2017 11:54:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 538A375607 for ; Mon, 26 Jun 2017 11:54:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5QBsaaD014582 for ; Mon, 26 Jun 2017 11:54:36 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5QBsaJC014581 for current@freebsd.org; Mon, 26 Jun 2017 04:54:36 -0700 (PDT) (envelope-from david) Date: Mon, 26 Jun 2017 04:54:36 -0700 From: David Wolfskill To: current@freebsd.org Subject: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch" Message-ID: <20170626115436.GL1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xsbw7+pkldUUnFG3" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:54:44 -0000 --Xsbw7+pkldUUnFG3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is amd64: FreeBSD 12.0-CURRENT #386 r320324M/320326:1200035: Sun Jun 25 06:36:19 PDT= 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC = amd64 After a src update to r320353, the last several lines on the serial console from the initial (verbose) reboot are: =2E.. random: harvesting attach, 8 bytes (4 bits) from ukbd0 KLD geom_eli.ko: depends on kernel - not available0010-89d5-003048 or versi= on mismatch linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type 2d326a. SettingGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not ali= gned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes uhub3: 6 ports with 6 removable, self powered GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes random: harvesting attach, 8 bytes (4 bits) from uhub3 hostid: 0xc7455GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes 1dd. No suitablGEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not = aligned on 4096 bytes uhub4: 8 ports with 8 removable, self powered GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes random: harvesting attach, 8 bytes (4 bits) from uhub4 e dump device waGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes ugen0.3: at usbus0 umass0 on uhub2 s found. Startiumass0: on usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x4000 ng file system cumass0:6:0: Attached to scbus6 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? random: harvesting attach, 8 bytes (4 bits) from umass0 pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 hecks: /dev/adapass6: 0s4a: FILE SYSTE Removable Dire= ct AM CLEAN; SKIPPINcG CHECKS /dev/acess SCSI device pass6: Serial Number 20100818841300000 pass6: 40.000MB/s transfers GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SCSI device da0: Serial Number 20100818841300000 da0: 40.000MB/s transfers da0: Attempt to qda0s4a: clean, 6uery device size failed: NOT READY, Medium= not present da0: quirks=3D0x2 (probe0:umass-sim0:0:0:1): Down reving Protocol Version from 2 to 0? da016774 free (3814: Delete methods: GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes pass7 at umass-sim0 bus 0 scbus6 target 0 lun 1 GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes ugen0.4: at usbus0 pass7: Removable Direct Access frags, 76620 b= l SCSI docks, 0.5% fragmevice pass7: Serial Number 20100818841300000 pass7: 40.000MB/s transfers entation) /dev/GEOM: new disk da0 (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? da1 at umass-sim0 bus 0 scbus6 target 0 lun 1 da1: Removable Direct Access SCSI device da1: Serial Number 2010081ada0s1a: FILE SY88413000STEM CLEAN; SKIP00PING CH= ECKS /de da1: 40.000MB/s transfers da1: Attempt to query device v/ada0s1a: cleansize failed: NOT RE, 607665 fr= ee (1ADY, Medium not present da1: quirks=3D0x2 GEOM: new disk da1 da1: Delete825 frags, 75730 methods: p blocks, 0.2% frass8 at umass-sim0 bus 0 scbus6 target 0 lun 2 pass8: Removable Direct Access SCSI device pass8: Serial Number 20100818841300000 pass8: agmentation) /d40.000MB/s transfers da2 at umass-sim0 bus 0 scbus6 target 0 lun 2 da2: Removable Direct Access SCSI device da2: Serial Number 20100818841300000 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not presev/ada0= s1d: FILEent da2: quirks=3D0x2 da2: Delete methods: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL not supported. (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? KIPPING CHECKS pass9 at umass-sim0 bus 0 scbus6 target 0 lun 3 pass9: Removable Direct Access SCSI device pass9: Serial Number 20100818841300000 pass9: 40.000MB/s transfers da3 at umass-sim0 bus 0 scbus6 target 0 lun 3 da3: Removable Direct Access SCSI device da3: Serial Numb/dev/ada0s1d: cler 20100818841300000 da3: 40.000MB/s transfers da3: Attempt toean, 594513 free (56257 frags, 6query device size failed: N= OT READY, Medium not present da3: quirks=3D0x2 da3: Dele7282 blocks, 2.5te methods: (da1:uma% fragmentation)ss-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL no /dev/ada0s2a: t supported. FILE SYSTEM CLEAGEOM: new disk da2 GEOM: new disk da3 (da2:umass-sim0:0:0:2): PREVENT ALLOW MEDIUM REMOVAL not supported. N; SKIPPING CHEC(da3:umass-sim0:0:0:3): PREVENT ALLOW MEDIUMKS /dev/ada0s2a REMOVAL not supported. : clean, 607665 GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes GEOM_PART: partitfree (233 frags,ion 2 on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes GEOM_P 75929 blocks, 0ART: partition 3 on (diskid/DISK-1350095E5057, .0% fr= agmentatioMBR) is not aligned on 4096 bytes n) /dev/ada0s2d: FILE SYSTEM CLEAN; SKIPPING CHGEOM_PART: partition 1 on (disk= id/DISK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partECKS /dev/ada0sition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096= bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes 2d: clean, 594551 free (175 frags, 74297 blocks,G 0.0% fragmentatEOM_PART: = partition 1 on (diskid/DISion) /dev/ada0sK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned3a:= FILE SYSTEM on 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 CLEAN; SKIPPING bytes CHECKS /dev/ada0s3a: clean, 607GEOM_PART: partition 1 on (diskid/DISK-1350095E5057= , MBR) is not aligned 682 free (986 fron 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E50ags, 75837 block57, MBR) i= s not aligned on 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes s, 0.1% fragmentation) /dev/adaGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not al= igned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes 0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not alig= ned on 4096 bytesda0s3d: clean, 6 GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes GEOM_PART: partition 3 01753 free (1513on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes frags, 75030 blocks, 0.1% fragmGEOM_PART: partition 1 on (diskid/DISK-1350= 095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partition 2 on (diskientation) /dev/d/DISK-1350095E5057, MBR) is not aligned on 4096 bytes ada0s4d: FILE SYGEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) i= s not aligned on 4096 bytes STEM CLEAN; SKIPPING CHECKS /deGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned= on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on= 4096 bytes v/ada0s4d: clean, 1280743 free (22743 frags, 157KLD tmpfs.ko: depends on ke= rnel - not availabl250 blocks, 1.0%e or version mismatch lfragmentation) /dev/ada0s4e: Finker_load_file: /boot/kernel/tmpfs.ko - unsupported file t= ype ILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s4e:KLD tmpfs.ko: depends on kernel - not available or version mis= match clean, 6377334 linker_load_file: /boot/kernel/tmpfs.ko - unsupported file = type free (789254 frags, 698510 blocks, 4.9% fragmentation) /dev/ada0s4g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s4g: clean, 10065775 free (2359 frags, 1257927 blocks, 0.0% fragme= ntation) /dev/ada0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s4f: clean, 853073 free (281 frags, 106599 blocks, 0.0% fragmentat= ion) /dev/ada0s4h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s4h: clean, 28275233 free (109769 frags, 3520683 blocks, 0.3% frag= mentation) Mounting local filesystems:mount: tmpfs: Operation not supported by device Mounting /etc/fstab filesystems failed, will retry after root mount hold re= lease mount: tmpfs: Operation not supported by device =2E Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jun 26 11:20:59 init: /bin/sh on /etc/rc terminated abnormally, going to si= ngle user mode Enter full pathname of shell or RETURN for /bin/sh:=20 I then hit Enter and tried to see what I could: # mount /dev/ada0s4a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ada0s1a on /S1 (ufs, local, soft-updates) /dev/ada0s1d on /S1/usr (ufs, local, soft-updates) /dev/ada0s2a on /S2 (ufs, local, soft-updates) /dev/ada0s2d on /S2/usr (ufs, local, soft-updates) /dev/ada0s3a on /S3 (ufs, local, soft-updates) /dev/ada0s3d on /S3/usr (ufs, local, soft-updates) /dev/ada0s4d on /usr (ufs, local, soft-updates) /dev/ada0s4e on /common (ufs, local, soft-updates) /dev/ada0s4g on /local (ufs, local, soft-updates) /dev/ada0s4f on /var (ufs, local, soft-updates) /dev/ada0s4h on /repo (ufs, local, soft-updates) # swapinfo Device 512-blocks Used Avail Capacity # swapon -a KLD geom_eli.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type swapon: /dev/ada0s4b.eli: Invalid parameters #=20 (I have been using encrypted swap for the last few months.) This appears to be an issue with kernel modules in general: # kldstat Id Refs Address Size Name 1 1 0xffffffff80200000 2081550 kernel #=20 This ("freebeast") is not a very "fancy" machine, but I would expect a few more modules than merely the kernel itself. (As noted elsewhere, I have been using filemon & WITH_META_MODE=3Dyes for quite some time.) For comparative information (as of yesterday's verbose boot of head @r320324), please see . Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Xsbw7+pkldUUnFG3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZUPX8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XhpkH/i6BBLm3LMZsvEykeHQcwqNp f6MpvAy0txhZ7czwgwxfd9+8xFQa+JRDOIdqjCttQwlaHDAuz1TMLPohVyTq0vl6 LDfLvjTL8sd0dPW1evaW3Pedf7WhcGcSjJhcIhVO+q7WG7snB/NqwD7FJsriexUI nmqz7PyZ2r7HE4s9A0W+GOdex19qfkS4k4w+0f5Yy8Ep2YCaferymhWbljSI/VVu Ce9CPp5deEsKLPZdjqcydMXsAAYUkyb21UKJ0bcFlJiag0xbsoiUTuafqFESa5Tr W9DP2E+HXDfPfqMtgG8TGET6ccL71YTQ7vleEJajgj6pJH8wxj40nsth0Kf/2hQ= =RBli -----END PGP SIGNATURE----- --Xsbw7+pkldUUnFG3-- From owner-freebsd-current@freebsd.org Mon Jun 26 12:01:03 2017 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 0FA3FDA8A08 for ; Mon, 26 Jun 2017 12:01:03 +0000 (UTC) (envelope-from ohartmann@walstatt.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 E382375B31 for ; Mon, 26 Jun 2017 12:01:02 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id E2D22DA8A06; Mon, 26 Jun 2017 12:01:02 +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 E27DBDA8A05 for ; Mon, 26 Jun 2017 12:01:02 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49F8975B2C for ; Mon, 26 Jun 2017 12:01:01 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGWR2-1dToGr1SaG-00DFsW; Mon, 26 Jun 2017 14:00:53 +0200 Date: Mon, 26 Jun 2017 14:00:48 +0200 From: "O. Hartmann" To: Gary Jennejohn Cc: current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170626132608.03eab0cf@ernst.home> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <20170626132608.03eab0cf@ernst.home> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ymkUFHCgADa06/w2o1aHsKYS95J35odIb40jXv/41PQzqappo6u Zh/CIE1bqTnNbn+5TasR5pcFM/ScLhTZy7m05t875T6XJOD9bmihBW3OBV3XTn5e0N3o6CV dOOVLkuRp+tx9XdoBH0xT8EStFvw/BkoG/Bx3sQS+WyrA3ahB8FLxPgU0VM12OiJbAOkeV+ Dn7NxQ2y9VmDFCBJoTBAQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:qEqZUptGTNY=:bGXQaQfX78MkK3K0KciUxp gFjThC8tCczZal/Loae1RKSAlzKQ3wVJBAN03PCjoK6G3Yz2WqRqGGsOwUgZzE2eW7dD0NcjO jHaNnNrJ4Gp+dsh+QCHZS/V6iGrNYkeZSpfwtKGKhDluICtIGRCi+LTYUIwHumqMfsFnF/DOZ tLeKez5Hyfmq+aOZjL6lRZWaX1T6v7TuILIx9OyL15aJQ0UvldIAsxrnbiutPDHUj9ld6LYOW JXSkvTRAbTaeA6cmf2JltPM9nwIMiuaKmvzuM4lrRTtMhRPurtTluoK+oRICecVpOlDvEvENI oPvTkEUKJWNMkgm7Xn1uTZOXCXC9UD/KU7jNb2Ti1/d+D4X54tyswJWSvEo4lJwIsM/GXswys oHrmThdy694/kxVYmhlUF7AHesiQukYo1qpHCZdCxPKc5PiyL4PeRUweXU6WlOzKRWmA4+aZ5 KkaAHS2eO3wFtwT0+9xZpsHjX3UM+HBAMcrq1Qg1O4w/X02D6wPoEAB5UsdanOAI7vhK/iBFI b9msPP6wdkXvK66+aJrA16ytKAWw3eXIQgmN40/ROXKL7GqKerrSfJAkgPSgyTzWRCmSQbtNn e9G3JmuTlXov4WHMB4oPb6HMa/pAGu8wqIt0A604bI0qxFk897/fcOkjLglVzRQDDgm1jZcv9 YVeMXBuWb0MVcKN68TkO/zuP/arUhhFOjR8SNa+YvHrEd5hL8gO/Fl/eU8gWoTEhrLojOlblF 58eCO3F7StQrUC6CBQOXXf3oRipVB8sLfUtwdPLtQ3dQ5MfZhZadmnd6TMmqIOoxoOmfKLFiU 9VP+ic7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 12:01:03 -0000 On Mon, 26 Jun 2017 13:26:08 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 10:29:47 +0200 > "O. Hartmann" wrote: > > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > How recent was your last update? Some changes were made just a few > hours ago to fix a stack growth problem in threads. Well, what do you mean by "... source is not up to date ..."? Performing an svn update of /usr/src should suffice, shouldn't it? If not, then ... please correct me. I think the sources are up to date as of the moment the bug occured. I consider the sources up to date, it is on the latest updated box r320355. There are so far two variations: one is r319971 -> 320351 as the subject indicates, the second box is r320144 -> 320355. > > Either your source is not up to date, or a new bug was introduced by > the intended fix. > As described earlier, I ran into a coredump by not having built world and kernel from scratch but with filemon. That was r320251. Cleaning (deleting) /usr/obj/* and rebuilding world and kernel and performing the update of the system as required (install the new kernel, boot the new kernel in single user mode) succeeded, but installworld then failed. From owner-freebsd-current@freebsd.org Mon Jun 26 12:06:08 2017 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 5D3D1DA8DC5 for ; Mon, 26 Jun 2017 12:06:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 43B4E75F68 for ; Mon, 26 Jun 2017 12:06:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 40087DA8DC4; Mon, 26 Jun 2017 12:06:08 +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 3F87CDA8DC3 for ; Mon, 26 Jun 2017 12:06:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 C9C0D75F67 for ; Mon, 26 Jun 2017 12:06:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5QC5wn2034295 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 15:05:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5QC5wn2034295 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5QC5wgm034294; Mon, 26 Jun 2017 15:05:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Jun 2017 15:05:58 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch" Message-ID: <20170626120558.GP3437@kib.kiev.ua> References: <20170626115436.GL1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626115436.GL1241@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 26 Jun 2017 12:06:08 -0000 On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > KLD geom_eli.ko: depends on kernel - not available or version mismatch > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > swapon: /dev/ada0s4b.eli: Invalid parameters Again remove all kernel build files and try fresh build. From owner-freebsd-current@freebsd.org Mon Jun 26 12:28:26 2017 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 3BAA3DA9826 for ; Mon, 26 Jun 2017 12:28:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC3C76D64 for ; Mon, 26 Jun 2017 12:28:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0E073DA9825; Mon, 26 Jun 2017 12:28:26 +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 0DA8ADA9824 for ; Mon, 26 Jun 2017 12:28:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 B89FF76D63; Mon, 26 Jun 2017 12:28:25 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5QCSOD4015278; Mon, 26 Jun 2017 12:28:24 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5QCSOB8015277; Mon, 26 Jun 2017 05:28:24 -0700 (PDT) (envelope-from david) Date: Mon, 26 Jun 2017 05:28:24 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch" Message-ID: <20170626122824.GO1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170626115436.GL1241@albert.catwhisker.org> <20170626120558.GP3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XzwO5SPJOYU+7Pos" Content-Disposition: inline In-Reply-To: <20170626120558.GP3437@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 12:28:26 -0000 --XzwO5SPJOYU+7Pos Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > KLD geom_eli.ko: depends on kernel - not available or version mismatch > > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > > swapon: /dev/ada0s4b.eli: Invalid parameters >=20 > Again remove all kernel build files and try fresh build. OK; after clearing /usr/obj/usr/src/sys/GENERIC, then rebuilding the kernel ("make -j16 buildkernel && ... && make installkernel") & rebooting no longer whines about the kmods, and kldstat says: freebeast(12.0-C)[2] kldstat=20 Id Refs Address Size Name 1 25 0xffffffff80200000 2081550 kernel 2 1 0xffffffff82283000 a128 filemon.ko 3 1 0xffffffff82421000 11376 geom_eli.ko 4 1 0xffffffff82433000 fde7 tmpfs.ko 5 1 0xffffffff82443000 4fd4 ng_ubt.ko 6 5 0xffffffff82448000 d0fe netgraph.ko 7 1 0xffffffff82456000 a9f4 ng_hci.ko 8 3 0xffffffff82461000 10e3 ng_bluetooth.ko 9 1 0xffffffff82463000 e41e ng_l2cap.ko 10 1 0xffffffff82472000 1e413 ng_btsocket.ko 11 1 0xffffffff82491000 3d37 ng_socket.ko 12 1 0xffffffff82495000 8884 autofs.ko freebeast(12.0-C)[3]=20 uname output is: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #388 r3= 20353M/320355:1200036: Mon Jun 26 05:18:40 PDT 2017 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 Hmmm..... Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --XzwO5SPJOYU+7Pos Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZUP3oXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XzuwIAMvoUBSx4cH074CHaWHpwOQ6 ObdwDmCjXFte7ocRpS1vHgH5QTvE6PTJtupr1L3QPfZofxwZcKojd8cX0DewZz9m U+Y4qOzO7XjeoBSTfIfhTug8zwuQK1G9QHZUGqwyJ1cNdJ0EooKeIPalfBt5+80U bbpSJblbapCKPjFQIkQyEhlfZD12m70QeBf2xjz5RCC8f2KxHJjqGeC7rZIRtOVa IIs6oMXwLquetRtLXlutu+AG79dx9JaiKDomaqrxTkXRLkg4cvOKUy7A2lo11mvt dI8ZMC9Q6FQoULhNv8o65dBSa9muGXq7L6S1avjiCHN9l+c4ZmL4qbKD0G8aTaA= =EwEj -----END PGP SIGNATURE----- --XzwO5SPJOYU+7Pos-- From owner-freebsd-current@freebsd.org Mon Jun 26 12:30:09 2017 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 D1E4ADA9931 for ; Mon, 26 Jun 2017 12:30:09 +0000 (UTC) (envelope-from kostikbel@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 AE30176EE3 for ; Mon, 26 Jun 2017 12:30:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id AA80BDA992E; Mon, 26 Jun 2017 12:30:09 +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 AA2E4DA992D for ; Mon, 26 Jun 2017 12:30:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3C1E876EDC for ; Mon, 26 Jun 2017 12:30:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5QCTxe0038869 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 15:29:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5QCTxe0038869 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5QCTx8U038868; Mon, 26 Jun 2017 15:29:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Jun 2017 15:29:59 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch" Message-ID: <20170626122959.GR3437@kib.kiev.ua> References: <20170626115436.GL1241@albert.catwhisker.org> <20170626120558.GP3437@kib.kiev.ua> <20170626122824.GO1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626122824.GO1241@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 26 Jun 2017 12:30:09 -0000 On Mon, Jun 26, 2017 at 05:28:24AM -0700, David Wolfskill wrote: > On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > > KLD geom_eli.ko: depends on kernel - not available or version mismatch > > > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > > > swapon: /dev/ada0s4b.eli: Invalid parameters > > > > Again remove all kernel build files and try fresh build. > > OK; after clearing /usr/obj/usr/src/sys/GENERIC, then rebuilding the > kernel ("make -j16 buildkernel && ... && make installkernel") & > rebooting no longer whines about the kmods, and kldstat says: > > freebeast(12.0-C)[2] kldstat > Id Refs Address Size Name > 1 25 0xffffffff80200000 2081550 kernel > 2 1 0xffffffff82283000 a128 filemon.ko > 3 1 0xffffffff82421000 11376 geom_eli.ko > 4 1 0xffffffff82433000 fde7 tmpfs.ko > 5 1 0xffffffff82443000 4fd4 ng_ubt.ko > 6 5 0xffffffff82448000 d0fe netgraph.ko > 7 1 0xffffffff82456000 a9f4 ng_hci.ko > 8 3 0xffffffff82461000 10e3 ng_bluetooth.ko > 9 1 0xffffffff82463000 e41e ng_l2cap.ko > 10 1 0xffffffff82472000 1e413 ng_btsocket.ko > 11 1 0xffffffff82491000 3d37 ng_socket.ko > 12 1 0xffffffff82495000 8884 autofs.ko > freebeast(12.0-C)[3] > > uname output is: > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #388 r320353M/320355:1200036: Mon Jun 26 05:18:40 PDT 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > Hmmm..... As if computer tries to say you, do not use meta mode. From owner-freebsd-current@freebsd.org Mon Jun 26 12:44:20 2017 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 8DD07DA9E65 for ; Mon, 26 Jun 2017 12:44:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7455B77A50 for ; Mon, 26 Jun 2017 12:44:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 70A8CDA9E64; Mon, 26 Jun 2017 12:44:20 +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 702F1DA9E63 for ; Mon, 26 Jun 2017 12:44:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 3D4B477A4F; Mon, 26 Jun 2017 12:44:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5QCiITw015569; Mon, 26 Jun 2017 12:44:18 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5QCiISA015568; Mon, 26 Jun 2017 05:44:18 -0700 (PDT) (envelope-from david) Date: Mon, 26 Jun 2017 05:44:18 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch" Message-ID: <20170626124418.GP1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170626115436.GL1241@albert.catwhisker.org> <20170626120558.GP3437@kib.kiev.ua> <20170626122824.GO1241@albert.catwhisker.org> <20170626122959.GR3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DCmRZ841GpRfzaEr" Content-Disposition: inline In-Reply-To: <20170626122959.GR3437@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 12:44:20 -0000 --DCmRZ841GpRfzaEr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > ... > > Hmmm..... >=20 > As if computer tries to say you, do not use meta mode. For building the kernel, on head as of some commit after r320307 (but by r320324). Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --DCmRZ841GpRfzaEr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZUQGiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XFtsH/AyevuMv4JR3GJVLhFNDJDZ3 dPBYpexXO3jMquMkgbtHM/kUobcznarWaqOcJYQ4ngi6G+zFop3FKD2nwHxXa2fG cxxWw1qxSFX4cfB9LssT/QmsrFtP8OoF85W7NDTzTb3wQFLMbjjrt7rfE788T1+n 8iHnlwHz3dt66PK6l3Spa6pKT7s4oo+CGndqsEL4F24VRJJ0ePZlD6nhgauqRJcc 8VMoQojjVf5vdcNMhvxXK3VvAXTPILTT7jvTeS2MqBBPehQy/7jC38NWQ/KbL0sX xixb77SyZTcJKfwt05ePkO6WV/ygWm81iJ6VuJ0hOasxUTYOKWZL/1hBpbNHRRM= =NrAD -----END PGP SIGNATURE----- --DCmRZ841GpRfzaEr-- From owner-freebsd-current@freebsd.org Mon Jun 26 12:49:02 2017 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 81B17DA9F9B for ; Mon, 26 Jun 2017 12:49:02 +0000 (UTC) (envelope-from gljennjohn@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 5A04F77BDC for ; Mon, 26 Jun 2017 12:49:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 56177DA9F9A; Mon, 26 Jun 2017 12:49:02 +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 558C0DA9F99 for ; Mon, 26 Jun 2017 12:49:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 D8DA177BDB for ; Mon, 26 Jun 2017 12:49:01 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x243.google.com with SMTP id 77so29214744wrb.3 for ; Mon, 26 Jun 2017 05:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=RVw2P5FCiKrWrVqL6IfGTGERBYroNQOji7q3gR1Cvbo=; b=l+MxZY59sg8UmaXdzQZvris8KfgzMN9xnBO+z064Oi52UhxrHlWyOKE+/HbVgWsnEa 4cSgz4kS2aSbDWZB+2OjUpYf3oBbu7thP3UQynqRrrc3AQHoQecEf2/sFc1D7M6usTIq fQPCnrMatrm9LAdjYrPi5S240zjaqRVmqyL5KBwIHeritrdsq3jRRcxGWi/wcUkquFwj 7HNZF4iIGf56TgMiDMFZx0HeZjE+F/mIMXEnjvq2bJ6UZ46H7IFDLKbSlNwhwiuWIAsA bn3oyCRqtYUrckpuCgWfb5A0f0d0xfrth80cpsmwGIaRxQ9Uc3q9Svj3hnHSOVfNGTVF awyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=RVw2P5FCiKrWrVqL6IfGTGERBYroNQOji7q3gR1Cvbo=; b=sF6hlyjY4kr0MnoiBqd1jxZHLAEk+vS4dsznhGkjJ+tcW7yMf6MT6k7CxReEwHGO7s qUZLaE3T4sgMq9rH2GE9Po1YOwN9PilXQvdB+XO+zIwr5LsnEwii55lfB97xbpEMg1wA AFuIj0O5zqxJhh19y9WYQOCWsQPEAXyFxBMq2eU3h5zO+qL/PCf/X1iRKp7jDPxFZs7j Y6UkbnnLSZvqnd0WnQi+82RGkaPhafVqhlfLmfNAeO+EnyymTP3yq3O68WoV4EOq25yO 33YZZLT4xFB7+WCKYsBjQg7Tc/kboU1kFk048rRk1GiMKbO4xC8pFFQ8PpvI4S68RkWv YcXw== X-Gm-Message-State: AKS2vOz2zJOPLlVXkYArRUDpSxVqZj++IcaQxpqaUXbPtFwAMmvH4619 Bnpm3Lla5+tZpg== X-Received: by 10.223.172.183 with SMTP id o52mr9432111wrc.1.1498481340164; Mon, 26 Jun 2017 05:49:00 -0700 (PDT) Received: from ernst.home (p4FCA6CDA.dip0.t-ipconnect.de. [79.202.108.218]) by smtp.gmail.com with ESMTPSA id t70sm32298wmd.1.2017.06.26.05.48.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Jun 2017 05:48:59 -0700 (PDT) Date: Mon, 26 Jun 2017 14:48:58 +0200 From: Gary Jennejohn To: "O. Hartmann" Cc: current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626144858.1b799130@ernst.home> In-Reply-To: <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <20170626132608.03eab0cf@ernst.home> <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 12:49:02 -0000 On Mon, 26 Jun 2017 14:00:48 +0200 "O. Hartmann" wrote: > On Mon, 26 Jun 2017 13:26:08 +0200 > Gary Jennejohn wrote: > > > On Mon, 26 Jun 2017 10:29:47 +0200 > > "O. Hartmann" wrote: > > > > > Over the past week we did not update several 12-CURRENT running development > > > hosts, so today is the first day of performing this task. > > > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > > recompiling world and kernel. > > > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > > INO64 update hasn't performed so far starting from r319971, I installed the > > > kernel, rebooted the box in single user mode (this time smoothly), did a > > > mergemaster and tried to do "make installworld" - but the box instantanously > > > bails out: > > > > > > [...] > > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > > file /usr/src/lib/libthread/thr_init.c > > > pid 60 (cc) uid0: exited on signal 6 ... > > > > > > [...] > > > > > > That way, I obviously can not install a world :-( > > > > > > What is wrong here? Is the problem resovable? > > > > > > > How recent was your last update? Some changes were made just a few > > hours ago to fix a stack growth problem in threads. > > Well, what do you mean by "... source is not up to date ..."? > Performing an svn update of /usr/src should suffice, shouldn't > it? If not, then ... please correct me. I think the sources > are up to date as of the moment the bug occured. > > I consider the sources up to date, it is on the latest updated > box r320355. > You did not explicitly state in the orignal post at which SVN revison your code was. Seems to me that my question was reasonable. Now it's clear that your source should have been up to date. Just for the record, I just booted a kernel from SVN r320357 which immediately resulted in a kernel panic. I had to delete everything under /usr/obj/usr/src/sys to get a working kernel. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Mon Jun 26 13:03:40 2017 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 DA036D8662A for ; Mon, 26 Jun 2017 13:03:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B9740785F0 for ; Mon, 26 Jun 2017 13:03:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id B8AAED86629; Mon, 26 Jun 2017 13:03:40 +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 B7BE5D86627 for ; Mon, 26 Jun 2017 13:03:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36B56785EF for ; Mon, 26 Jun 2017 13:03:39 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MC4R6-1dYJNV230a-008sfd; Mon, 26 Jun 2017 15:03:25 +0200 Date: Mon, 26 Jun 2017 15:03:22 +0200 From: "O. Hartmann" To: Gary Jennejohn Cc: "O. Hartmann" , current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626150322.52e3f4ed@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170626144858.1b799130@ernst.home> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <20170626132608.03eab0cf@ernst.home> <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> <20170626144858.1b799130@ernst.home> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VtOmmYJjAFQuokpWtUINZpG5PnDSB5jlGr5JV7QnmnT7VXhYdaR LFsHFCxKx7XaYSYBL/rTSijdm9bOeZg6/LX+Z5xAvwp4WvqK99iOeWZCMARSDFLNdYoGsvs iII8G/P77KCuZ6EQoRSh2FlWcGH2fA1G/LbDMUh0bMxpNcQk559WbfOBL5u6cYefBwNE6Cz 7xqz6BURgp7ey0Rtmt0AA== X-UI-Out-Filterresults: notjunk:1;V01:K0:a1oL1LEkUOw=:XczbZVIUAkEjnutIsQ8OPJ yUJE6yZvfA5iDR0TTYxmpF84tulre/xNCrfwD9ZzytunGBsug2RKtWy1rq2sbFq9dBejDAjjX KNYxTpPI8mvYixv0WlwNVmnzFmUkJYCP4HWKK+Zijou+gTDY75eWts7rfBK4M1+xELUaLD98R waA1Jww3x2BvH1qsCsagUxMGgyhVT+01RavzKfHqiARLeUFsI0pBPAt3+B1ulRlxhsU6atWYX 1YmtFE4mJuQxjDloSbLfq40mOL42zAU/p9XJoHwkHG4TrKecXf0MZA1FL/y1Nj7r8AgiL68tC 93zkVcJDQJUNI7cVgAxmFcHYWoNVq3Apir8e5HyjAx+VglHF+C45g84jgsNvHgW5I5XrTljIE F8ajuYUxNTuGLX2VyKHScZdAHDty2BSMYsNrxMd8udXEhRryi7qQUXKiKbe0VRx3opIcasfDS thQ0Lhv0Szi/4sR46mMabXtaFwXMzM9Pqe14g6leHoVfUXy9Y4wj5QZN3pGpWTPa4YkgFDT1/ LhRMHC42ciFOhU3AgYdWfQ1KsSZCOy4/r02AmJkd87D6sDpRNVa8+WEqgG8L0NWGw79vWsYBQ LHDMkc+FFyLX6ojgCPtcQguuZoP9EP1aaGaY+Utg9MNf7BIA7Lz97uolI5L2R3bsXoItdrsAn jdOf/MeIt5NMiz50cWtRAFx7ImE+y3FqTdFxOFf9Fc3Fi9CHywiV0EwowYJIx8brN4JcJaGFT cIa1FDRRTK8VfTtgExS5ZLEN+uQ5KcI0Ad+69aPAfkyj67lEME76kEyl3Hq7MqtjORs/C9247 daQdkke X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 13:03:40 -0000 On Mon, 26 Jun 2017 14:48:58 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 14:00:48 +0200 > "O. Hartmann" wrote: > > > On Mon, 26 Jun 2017 13:26:08 +0200 > > Gary Jennejohn wrote: > > > > > On Mon, 26 Jun 2017 10:29:47 +0200 > > > "O. Hartmann" wrote: > > > > > > > Over the past week we did not update several 12-CURRENT running > > > > development hosts, so today is the first day of performing this task. > > > > > > > > First I hit the very same problem David Wolfskill reported earlier, a > > > > fatal trap 12, but fowllowing the thread, I did as advised: > > > > removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all > > > > over the place) and recompiling world and kernel. > > > > > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update > > > > and the INO64 update hasn't performed so far starting from r319971, I > > > > installed the kernel, rebooted the box in single user mode (this time > > > > smoothly), did a mergemaster and tried to do "make installworld" - but > > > > the box instantanously bails out: > > > > > > > > [...] > > > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > > > file /usr/src/lib/libthread/thr_init.c > > > > pid 60 (cc) uid0: exited on signal 6 ... > > > > > > > > [...] > > > > > > > > That way, I obviously can not install a world :-( > > > > > > > > What is wrong here? Is the problem resovable? > > > > > > > > > > How recent was your last update? Some changes were made just a few > > > hours ago to fix a stack growth problem in threads. > > > > Well, what do you mean by "... source is not up to date ..."? > > Performing an svn update of /usr/src should suffice, shouldn't > > it? If not, then ... please correct me. I think the sources > > are up to date as of the moment the bug occured. > > > > I consider the sources up to date, it is on the latest updated > > box r320355. > > > > You did not explicitly state in the orignal post at which SVN > revison your code was. Seems to me that my question was > reasonable. > > Now it's clear that your source should have been up to date. > > Just for the record, I just booted a kernel from SVN r320357 which > immediately resulted in a kernel panic. I had to delete everything > under /usr/obj/usr/src/sys to get a working kernel. That has been made clear earlier in the thread, telling us that NO_CLEAN and/or META_MODE leaves the object tree in a somehow unusable state. Id did so twice this morning. I have to build a kernel with KTRACE capabilities as requested herein, but can perform this not before tomorrow morning. Some people seem to report positive updates, but starting from a later svn revision. So the problem seems to be transitional ... From owner-freebsd-current@freebsd.org Mon Jun 26 13:13:19 2017 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 AF138D86B2C for ; Mon, 26 Jun 2017 13:13:19 +0000 (UTC) (envelope-from gjb@FreeBSD.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 9552878C1B for ; Mon, 26 Jun 2017 13:13:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 94A2AD86B2A; Mon, 26 Jun 2017 13:13:19 +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 94326D86B26 for ; Mon, 26 Jun 2017 13:13:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7A378C1A; Mon, 26 Jun 2017 13:13:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 92A6DF8A4; Mon, 26 Jun 2017 13:13:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 26 Jun 2017 13:13:16 +0000 From: Glen Barber To: Jeffrey Bouquet Cc: current Subject: Re: status of and/or url to check base packages repo somewhere? Message-ID: <20170626131316.GC1974@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-STABLE amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 13:13:19 -0000 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2017 at 10:30:53PM -0700, Jeffrey Bouquet wrote: > As the Subject: is there a canonical url to check, and a procedure in p= lace yet, to,=20 > for instance, if one cannot buildworld on 12.0-CURRENT, to access the pac= kage .txz or=20 > whatever and 'pkg fetch ... pkg add ...' which would substitute for the = buildworld=20 > cycle? Also, one would be rebooted into a GENERIC kernel, ... and other = details ? > .... There is no public repository for base packages as of yet. It is still highly considered a 'beta' feature at this point. A public repository for base packages is one of the requirements to get it out of 'beta', but there are a few outstanding issues elsewhere. Glen --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAllRCGwACgkQAxRYpUeP 4pOWJA//YMzlTEXoeENqWPZ66U62sxj49IoQKsmXt3fYrs5lqa5Y5vVfpDB59E38 0z4swd/yyhYgxr7ytwKrwedz6ECDsgrD+f8NpH4wdAA61+kAegTEzhZwPBZTq6a7 S014dSJNPbcu42aVl/fsXks0qLSBTDBqkZR9fACVmc5zdOwV7ythyvfyDNKdfWG0 9t4VYafAtYU8MFRufdva0wecP2dqZk01AHxSSdDobrU8m5vuY+bsBbFtZYmhPQfu hkWY4CRPXHt1y8bjyn5B+aSvpES7WVXCYzV775QEWr8SNzJxKJOMdL2a8r0l1J7M yB8aogr4GfRl+mWjlH7PINxxbUGlykJROZs9hGl5fsG/mDPGAnZBV1R28SJc2wxk 6mQTA9xpdwvW1b+drrP7jrl2CbfV6c9PfsSd1+d5TUf2Ihdn1UDxSqKb1aGGb7c6 y/iAIIBQgxkK2DayhA28PB1s/xO+Qyvz+9+sZuE7WhyMPKc2Dm1GQU/zqv7y8/IM x6rW686AVfyjju+HsHnY3SGiGwdlGk3Bn3h6DTLLU/3GhcK1r4hT3Q1mcNvGWTG0 eyuf1yeuGQ51a69xJk+KlQFlJMbM3kWSxCUXmHs6VD6yZphu6xAMaw/Jif8+CCbR x0J060Pru4g9MPc7WRU46kNaBr5XRca3Y4mB6cCfM4PQjwZEWis= =IDDS -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-freebsd-current@freebsd.org Mon Jun 26 11:28:09 2017 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 7C375DA7942 for ; Mon, 26 Jun 2017 11:28:09 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C482874712 for ; Mon, 26 Jun 2017 11:28:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MKZLb-1dRN3g2x8x-001w6b; Mon, 26 Jun 2017 13:27:59 +0200 Date: Mon, 26 Jun 2017 13:27:58 +0200 From: "O. Hartmann" To: Steven Hartland Cc: freebsd-current@freebsd.org Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' Message-ID: <20170626132758.7d90ab70@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <6bd6a816-dbe4-1abf-f01b-da3afb03930c@multiplay.co.uk> References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <6bd6a816-dbe4-1abf-f01b-da3afb03930c@multiplay.co.uk> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CRURqGJFEN0ZkWSL74BvoB7w3U9mcDeNBiGIVjS2FMweKf7t/tn 9UrcvFDt7RyOmw8qs4Mfq1PnC9a+LKO0wIzkQg3oeOFM/+cVQbYyKCUqegA0UhneDmjNuXF jhPbiJbEK41j4E8/x6k8iNpxs18TibBrP0tOKXC53grPj3jKhNkjn7scQusqpMjSRGZGnck E/4I0Dq+X9ytTwyXm46ow== X-UI-Out-Filterresults: notjunk:1;V01:K0:/W/SmeKTMbA=:HAJzMugsPxoGhuNRAVP+Wf BdsnJTH/l4fGnK6b1LdKYmSqy1zvo6/XUklk/WAwZ0EVhNka12hL+MMw3ThjX+RDP4c7tqjt6 FWk839iGvFzrM3SX2Gw7TdD6lwRZIq5UCfZXl9yNsGrrAIu5EXgMwSaCUNbsSXtWy/+d37mTV +5NsCxQklLrjz7blvKSPmqxYcoYjnWJHpVOj+RlzgHRDngOt4oHWmWHqiD5mPtWrRoJwdloOo KmB8fYo9UxoB3naO+SMqD0BhH90TxSQZMpjlnzlprYyZdppvm8/NK1tDRMce9AqFx01jGVPxz aZg7P2WCaDEY0yCxFxrHNELqa+xVX3X3a4Vtmtm2aeOOKtXdvfnkqxXNZTw/U3TMsVo1K1bBi /IwD1YEiU50BZipYgQhbiIfT6X9OMlHCTiwGtRy2QhWnmqYo50sb7Q77dfSS/X+hQtRZafKnt /iLBjfY5pIVk42aTaMNrOVgCYNEptxbgujWigK/RvwSXAqghdxaqmAc0/EiuHnEyGZUrRxhzP 4/wxvpHTq05SicvnTIto0qLMgnGCuFzFWY/QAayUYhPzQPBfR8/qaJXYrSl7/HVAMd+7sgBXx p9Hzb2LZ6u5DTUY22NhDilebJgp60eWt/eCheDWjCDAs9jM8vIiNv2ppnzsGNRmuj+CDZeqLy uBmoiUvXrCcAnibH8sJZbTohfL8Y6Cd3eJBlu12ffvd9PbqvdV7tbiH2Mj3b+mifiGUB5Ilhy iJWqaq8VsrGphpEIIrbVjQVRNK1g6AJXzpbVqqYeXWBsduZlrWq6kWm8Lu96v6MejMAYLWDdp YU+OWLs X-Mailman-Approved-At: Mon, 26 Jun 2017 13:52:30 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 11:28:09 -0000 On Mon, 26 Jun 2017 12:22:50 +0100 Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 > > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > Kind regards, > > > > Oliver [...] The very same happens from updating r320144 -> r320355 From owner-freebsd-current@freebsd.org Mon Jun 26 19:53:15 2017 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 E7015D904EA for ; Mon, 26 Jun 2017 19:53:15 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 A67B03580 for ; Mon, 26 Jun 2017 19:53:15 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: by mail-oi0-x230.google.com with SMTP id l83so6694346oif.1 for ; Mon, 26 Jun 2017 12:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s5NNLJJS4ZySQJfJ2BSbeK+qttC+Li5tLZJEkpn30cY=; b=jeOAekhVjW2faE/L1ZUuSRmIpXa8L45/mZP4ro/GzEUQWWkbNu2Zcm7et9tUr+oBI/ WXUuubBZAHkU1I4rvbxWe30UMuFE4OmXA7NmedujL/ouG8ryLQZJoI+r69cUDJ4j9N1v 6uM5IDgbo91UNh+88a1q2mUO6F4CLc+Mcn3khH6v1nG2o4NCjP4xhIvmeUObceo5BlaB 5NaZ6sVX/D5EBxtGytOrjyfLx1rEybUchk6EYnVpptbchPXIjxssAVbTCoynxQVF4QN1 wY/xtQYplDBaiusx1rwi2LLRL1Ont5CpMIQN95DcJwIulVs4tTNhOyVRFr/lesU0/9Ej /Rmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s5NNLJJS4ZySQJfJ2BSbeK+qttC+Li5tLZJEkpn30cY=; b=VJcJEo7EmNPjXEVhEG/KVJJkF4kK9w9s9H+3TBrELvSC5cJoXB/x9aQzHgTE4qkR85 miagpKQQnRi2OLExW1zZ6BT/Rd5Z5Vn6+iurKNOAZy8DqckeGz7jc7hbpZwmHZjBDtIR 2mJb5eqUJVcLe5rp26LSD4hkG3c7dGppLd6iCoXn0aq0n1pdxZUadysbORQ++bz+l+8n hbIRneg1NAUAzB7C67y7n0PCaa31J66JO0v7zI/pH1gzZ9ZPJmSFaNKcbPidB0Uu25DF Xl9KDyczsuhdIRMPoyu9d/lJ/KmLxTDyr4mZIBNxMjRreU/n4V2n4LNOjd9a/SGWe0p4 fgYw== X-Gm-Message-State: AKS2vOx5YReNSNhRYYjOCn3jlIaq8o5H1pJPL4S0nKiP8tEv16l3F0U/ 1rNC249HScA1t4LTlVLEPhVZFcK5WA== X-Received: by 10.202.230.139 with SMTP id d133mr1040357oih.110.1498506794882; Mon, 26 Jun 2017 12:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.20.163 with HTTP; Mon, 26 Jun 2017 12:53:14 -0700 (PDT) In-Reply-To: <20170625164115.GD3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> From: Benjamin Kaduk Date: Mon, 26 Jun 2017 14:53:14 -0500 Message-ID: Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 To: Konstantin Belousov Cc: Manfred Antar , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 19:53:16 -0000 On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov wrote: > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main stack > split. > > It seems that ruby requested very small stack for a new thread, only 5 > pages in size. This size caused the stack gap to be correctly calculated > as having zero size, because the whole stack is allocated by initial grow. > But then there is no space for the guard page, which caused mapping failure > for it, and overall stack mapping failure. > > Try this. > https://people.freebsd.org/~kib/misc/vm2.2.patch > > I managed to get the "Cannot allocate red zone for initial thread" at the start of installworld (doing CC feature detection, IIRC) going from r306247 to r320328. Is it worth trying that patch out? -Ben From owner-freebsd-current@freebsd.org Mon Jun 26 20:25:31 2017 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 901EBD90EB9 for ; Mon, 26 Jun 2017 20:25:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 1C24F646D5 for ; Mon, 26 Jun 2017 20:25:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5QKPOF1044664 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 23:25:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5QKPOF1044664 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5QKPO8U044663; Mon, 26 Jun 2017 23:25:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Jun 2017 23:25:24 +0300 From: Konstantin Belousov To: Benjamin Kaduk Cc: Manfred Antar , FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170626202524.GY3437@kib.kiev.ua> References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 26 Jun 2017 20:25:31 -0000 On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov > wrote: > > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed something ruby-specific, or rather, triggered > > by ruby special use of libthr. It is not related to the main stack > > split. > > > > It seems that ruby requested very small stack for a new thread, only 5 > > pages in size. This size caused the stack gap to be correctly calculated > > as having zero size, because the whole stack is allocated by initial grow. > > But then there is no space for the guard page, which caused mapping failure > > for it, and overall stack mapping failure. > > > > Try this. > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > I managed to get the "Cannot allocate red zone for initial thread" at the > start of installworld (doing CC feature detection, IIRC) going from r306247 > to r320328. > > Is it worth trying that patch out? Ensure that you run a kernel past r320344 and then show me ktrace of the failing process. From owner-freebsd-current@freebsd.org Mon Jun 26 20:34:42 2017 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 32EC1D91688 for ; Mon, 26 Jun 2017 20:34:42 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 ADEDC653AC for ; Mon, 26 Jun 2017 20:34:39 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0FDCB20B9A; Mon, 26 Jun 2017 16:34:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 26 Jun 2017 16:34:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeamland.net; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=aYk3jjNlChJ4fAvJOzpVww0V5EovPZtycUp/wXA/1 Ug=; b=ZF9oVwsOUmJH+Z2WfgAIxOpb394z4pWmrKhDbh7dHPKSVCDPcSDdCHSjQ tNxw2SgcB1Qhg5rOrVi/Bp2q1qhEwlB7Lm08n7so4ttH1wo4vnBhMh0XHmPSnJ6f 4CbMYwfPTrAZt4I1VegJFdXhFhHsrRNgGdV4Y2MBWKCaKbFzCokFoH0hcyfrqkSl a3YUegbm0Wd5szZgWBS760mvkW2bY3+tBz/lDmXnAcCsM+1UFyhQhsAABOiUTELr 0DF+JLBCYkslPB2KU4mA3X7Ud0C90JgZX36eRvPYPrQqgvCmlJivHKwdo88XTBjI S4yAd5d4Sx2qTBse2TvmemxvXoM7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=aYk3jjNlChJ4fAvJOz pVww0V5EovPZtycUp/wXA/1Ug=; b=N6HJQjVSphWZ8+XgvJ5mzVVshaCfJa/Xur s546dP5MmXMjqspgY3F5Z+r6fuv0vtGqyDJne7CBiAmBZ5dL1U/QXX0XfjMY8QZF embzFF1YblDcX2//UsRDB53WxwHhvKe96IWoP+WNMpX8FmMJeM+aC8mK8hEAsAtN ICY7G3YMkvLXHu5CGhK9WXTblEpx0q+ZtdCBKqsF9ZXl/pEhVRLmWdla7MfArKil 7kwXyRB8aHM4npi1dGaQzsc8Ho3ehFYGwzFXAh04XElIAUTaoNKhGUudKDYMCEB3 M07rIeHyGpCwm98g4v1gkm8tW1YXoAgVh0CGMcU+K6oXM1+Rc9yA== X-ME-Sender: X-Sasl-enc: RPJraGkeZUh3LQvLLHB76KNjlQGxyBhheXMF9fVqvBDE 1498509277 Received: from mittlerweile.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net [76.104.201.218]) by mail.messagingengine.com (Postfix) with ESMTPA id 46BD87E7EE; Mon, 26 Jun 2017 16:34:37 -0400 (EDT) From: Benno Rice Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Date: Mon, 26 Jun 2017 13:34:35 -0700 In-Reply-To: <20170626202524.GY3437@kib.kiev.ua> Cc: Benjamin Kaduk , Manfred Antar , FreeBSD Current To: Konstantin Belousov References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170626202524.GY3437@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 20:34:42 -0000 > On Jun 26, 2017, at 13:25, Konstantin Belousov = wrote: >=20 > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov = >> wrote: >>=20 >>> No need, I understood why MAP_STACK failed in this case, thanks to = the >>> ktrace log. This is indeed something ruby-specific, or rather, = triggered >>> by ruby special use of libthr. It is not related to the main stack >>> split. >>>=20 >>> It seems that ruby requested very small stack for a new thread, only = 5 >>> pages in size. This size caused the stack gap to be correctly = calculated >>> as having zero size, because the whole stack is allocated by initial = grow. >>> But then there is no space for the guard page, which caused mapping = failure >>> for it, and overall stack mapping failure. >>>=20 >>> Try this. >>> https://people.freebsd.org/~kib/misc/vm2.2.patch >>>=20 >>>=20 >> I managed to get the "Cannot allocate red zone for initial thread" at = the >> start of installworld (doing CC feature detection, IIRC) going from = r306247 >> to r320328. >>=20 >> Is it worth trying that patch out? >=20 > Ensure that you run a kernel past r320344 and then show me ktrace of > the failing process. So I=E2=80=99m running r320364 with a ZFS root: > uname -a FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 = 12:35:03 PDT 2017 = benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG amd64 While upgrading I discovered that the zfs command works fine in = multiuser but fails in single-user in the way described above: # zfs mount -a Fatal error 'Cannot allocate red zone for initial thread' at line 393 in = file /src/freebsd/lib(something)/thread/thr_init.c (errno =3D 12) Abort trap (core dumped) I booted into single-user and ran zfs under ktrace and I=E2=80=99ve put = the results up for you: https://people.freebsd.org/~benno/ktrace.out.txt https://people.freebsd.org/~benno/ktrace.out https://people.freebsd.org/~benno/zfs.core= From owner-freebsd-current@freebsd.org Mon Jun 26 20:41:59 2017 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 EC9BCD91B67 for ; Mon, 26 Jun 2017 20:41:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 7800B65DBE for ; Mon, 26 Jun 2017 20:41:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5QKfrZ5048904 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 23:41:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5QKfrZ5048904 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5QKfrij048903; Mon, 26 Jun 2017 23:41:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Jun 2017 23:41:53 +0300 From: Konstantin Belousov To: Benno Rice Cc: Benjamin Kaduk , Manfred Antar , FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170626204153.GA3437@kib.kiev.ua> References: <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170626202524.GY3437@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 26 Jun 2017 20:42:00 -0000 On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote: > > > On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov > >> wrote: > >> > >>> No need, I understood why MAP_STACK failed in this case, thanks to the > >>> ktrace log. This is indeed something ruby-specific, or rather, triggered > >>> by ruby special use of libthr. It is not related to the main stack > >>> split. > >>> > >>> It seems that ruby requested very small stack for a new thread, only 5 > >>> pages in size. This size caused the stack gap to be correctly calculated > >>> as having zero size, because the whole stack is allocated by initial grow. > >>> But then there is no space for the guard page, which caused mapping failure > >>> for it, and overall stack mapping failure. > >>> > >>> Try this. > >>> https://people.freebsd.org/~kib/misc/vm2.2.patch > >>> > >>> > >> I managed to get the "Cannot allocate red zone for initial thread" at the > >> start of installworld (doing CC feature detection, IIRC) going from r306247 > >> to r320328. > >> > >> Is it worth trying that patch out? > > > > Ensure that you run a kernel past r320344 and then show me ktrace of > > the failing process. > > So I???m running r320364 with a ZFS root: > > > uname -a > FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 12:35:03 PDT 2017 benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG amd64 > > While upgrading I discovered that the zfs command works fine in multiuser but fails in single-user in the way described above: > > # zfs mount -a > Fatal error 'Cannot allocate red zone for initial thread' at line 393 in file /src/freebsd/lib(something)/thread/thr_init.c (errno = 12) > Abort trap (core dumped) > > I booted into single-user and ran zfs under ktrace and I???ve put the results up for you: > > https://people.freebsd.org/~benno/ktrace.out.txt > https://people.freebsd.org/~benno/ktrace.out > https://people.freebsd.org/~benno/zfs.core Try this. Even if it helps, the patch is being actively discussed and may be not in its final form. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 7b4a86dffd8..2766454d825 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1556,6 +1556,25 @@ again: return (result); } +int +vm_map_find_min(vm_map_t map, vm_object_t object, vm_ooffset_t offset, + vm_offset_t *addr, vm_size_t length, vm_offset_t min_addr, + vm_offset_t max_addr, int find_space, vm_prot_t prot, vm_prot_t max, + int cow) +{ + vm_offset_t hint; + int rv; + + hint = *addr; + for (;;) { + rv = vm_map_find(map, object, offset, addr, length, max_addr, + find_space, prot, max, cow); + if (rv == KERN_SUCCESS || hint == 0 || min_addr >= hint) + return (rv); + *addr = min_addr; + } +} + /* * vm_map_simplify_entry: * diff --git a/sys/vm/vm_map.h b/sys/vm/vm_map.h index 2c89e1d73d4..78f3f31c226 100644 --- a/sys/vm/vm_map.h +++ b/sys/vm/vm_map.h @@ -372,6 +372,8 @@ vm_map_t vm_map_create(pmap_t, vm_offset_t, vm_offset_t); int vm_map_delete(vm_map_t, vm_offset_t, vm_offset_t); int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t, vm_offset_t, int, vm_prot_t, vm_prot_t, int); +int vm_map_find_min(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, + vm_size_t, vm_offset_t, vm_offset_t, int, vm_prot_t, vm_prot_t, int); int vm_map_fixed(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t, vm_size_t, vm_prot_t, vm_prot_t, int); int vm_map_findspace (vm_map_t, vm_offset_t, vm_size_t, vm_offset_t *); diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index 4d8f6ad9ed7..24360d422e3 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -1438,10 +1439,12 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr, vm_size_t size, vm_prot_t prot, vm_prot_t maxprot, int flags, vm_object_t object, vm_ooffset_t foff, boolean_t writecounted, struct thread *td) { - boolean_t fitit; + boolean_t curmap, fitit; + vm_offset_t max_addr; int docow, error, findspace, rv; - if (map == &td->td_proc->p_vmspace->vm_map) { + curmap = map == &td->td_proc->p_vmspace->vm_map; + if (curmap) { PROC_LOCK(td->td_proc); if (map->size + size > lim_cur_proc(td->td_proc, RLIMIT_VMEM)) { PROC_UNLOCK(td->td_proc); @@ -1529,11 +1532,20 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr, vm_size_t size, vm_prot_t prot, MAP_ALIGNMENT_SHIFT); else findspace = VMFS_OPTIMAL_SPACE; - rv = vm_map_find(map, object, foff, addr, size, + max_addr = 0; #ifdef MAP_32BIT - flags & MAP_32BIT ? MAP_32BIT_MAX_ADDR : + if ((flags & MAP_32BIT) != 0) + max_addr = MAP_32BIT_MAX_ADDR; #endif - 0, findspace, prot, maxprot, docow); + if (curmap) { + rv = vm_map_find_min(map, object, foff, addr, size, + round_page((vm_offset_t)td->td_proc->p_vmspace-> + vm_daddr + lim_max(td, RLIMIT_DATA)), max_addr, + findspace, prot, maxprot, docow); + } else { + rv = vm_map_find(map, object, foff, addr, size, + max_addr, findspace, prot, maxprot, docow); + } } else { rv = vm_map_fixed(map, object, foff, *addr, size, prot, maxprot, docow); From owner-freebsd-current@freebsd.org Mon Jun 26 21:18:45 2017 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 76D04D9212A for ; Mon, 26 Jun 2017 21:18:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 017EF66BEC for ; Mon, 26 Jun 2017 21:18:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id b184so9053554wme.1 for ; Mon, 26 Jun 2017 14:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6GL3SqlaS9phXJd/aHrM+Rouk/tbUvrulig/pl9G2+w=; b=CAoSLwfEDHxo2EtEynXxI40uzDzgjgfqYojzBdeFGvZ6y9Kw/vd1nw25XViI6RXPaX A1oPOGqDIuF0VBfo0ItB9194bO8YGA4c5zcTIF/1s9lvPz0PlemX4GGANTxKtwXcPSXR wGuKMjX9SETa5wWpC6RuuGw76iTVNOt3Sg0MYuxdjTupt/ONugh3VvqHui/lg7cdZrZ9 DbBAX/rIZ5aizR+8aLzY8gZjCzVUgFDzuGVqVIzT3mPKjXnvuI9ZDtZcwzHRts7aIG1G gRfhBiHNIPrR/2XcytrNu9l5ExzinIYOnvh+gee5NJZ8LVBqvnoCgSqhcoEehHi16WjJ LxMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6GL3SqlaS9phXJd/aHrM+Rouk/tbUvrulig/pl9G2+w=; b=JakwmR2J11ojt91+UPCI1t7Fkbd5RK3yz8bngu2M6+mOgdGkH8rxvHRaUKgeLkt38/ vljw0O0J11+PbsvKwoEhDzmjLXUKrfV1HdffVPmj4asnbSlG+Ecm+pvBdeLxVBNwpXy8 FGYAiihHspVd7TEAClNL2S/ZT/AbG1yL4R84MSclyE0g+Ha4l/89kJHOiKuU0Q3TmXw1 YY5c8KswL+DDUOpjDUxmZ5qKCLtDUQErP4J7235FMRq+tMw3jlDyx/34a6+/NHpT1P8s vOg13II7yNymVIoBcJ6RQHY0ohk3O6EdEYxHid158jwEeYwUTwdp/U8QHKoDYBWPbdgF 5vUw== X-Gm-Message-State: AKS2vOx7SGYJYqMxiZtflpp5//sajBeophZAfTM+WSciusshAukul46o S+jfxJSo0U/EFY5qay5Y9fG3x2FsQw== X-Received: by 10.28.213.135 with SMTP id m129mr1047550wmg.78.1498511923003; Mon, 26 Jun 2017 14:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.183.138 with HTTP; Mon, 26 Jun 2017 14:18:42 -0700 (PDT) In-Reply-To: <50.A5.03935.85F90595@dnvrco-omsmta01> References: <78.25.03057.F5ADD495@dnvrco-omsmta02> <89.F1.03057.D331E495@dnvrco-omsmta02> <50.A5.03935.85F90595@dnvrco-omsmta01> From: Adrian Chadd Date: Mon, 26 Jun 2017 14:18:42 -0700 Message-ID: Subject: Re: Ports still broken by ino64? To: Thomas Mueller Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 21:18:45 -0000 I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller wrote: > from Adrian Chadd: > >> valgrind broke as part of the ino64 work :( > > Valgrind was not on my mind! Your post sent me to > > ls -d /usr/ports/*/val* > > to find valgrind, and then read the pkg-descr. > > One less tool for getting debugging information when something crashes? > > Tom > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 26 23:30:34 2017 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 4CD90D94318 for ; Mon, 26 Jun 2017 23:30:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D7E4A6EED1 for ; Mon, 26 Jun 2017 23:30:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1446 invoked from network); 26 Jun 2017 23:30:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Jun 2017 23:30:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 19:30:31 -0400 (EDT) Received: (qmail 8925 invoked from network); 26 Jun 2017 23:30:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jun 2017 23:30:31 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B8B2EC893D; Mon, 26 Jun 2017 16:30:31 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320192 -> -r320387 kernel build and install to a DESTDIR: if_igb.ko vs. DESTDIR use for installkernel has symbolic link that seems inapproriate Message-Id: <4176FEB2-192E-4204-8F74-598CB74B1132@dsl-only.net> Date: Mon, 26 Jun 2017 16:30:30 -0700 To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 26 Jun 2017 23:30:34 -0000 installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 produced a if_igb.ko (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _em.ko This does not allow simple copies of such directory trees that have if_igb.ko pointing to the right if_em.ko. Looking in my -r320192 based /boot/kernel/ that had been filled in via a default DESTDIR for installkernel (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel 21 20 if_igb.ko -> = /boot/kernel/if_em.ko So something like: cp -aRx /boot/kernel/ /boot/kercgd ends up with /boot/kercgd/if_igb.ko pointing into /boot/kernel/ instead of into /boot/kercgd/ . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 27 03:11:27 2017 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 5923FD9C484 for ; Tue, 27 Jun 2017 03:11:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 1A9FF76B0F for ; Tue, 27 Jun 2017 03:11:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2574 invoked from network); 27 Jun 2017 03:11:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Jun 2017 03:11:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 23:11:25 -0400 (EDT) Received: (qmail 28370 invoked from network); 27 Jun 2017 03:11:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Jun 2017 03:11:25 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5F0B3EC894C; Mon, 26 Jun 2017 20:11:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Recent reports of needing to avoid META_MODE for head kernel builds for updates: a preliminary investigation Message-Id: <5D970E60-5F3A-4580-9E7F-5CFD96361546@dsl-only.net> Date: Mon, 26 Jun 2017 20:11:23 -0700 To: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 03:11:27 -0000 For an example of the recent reports: David Wolfskill david at catwhisker.org wrote on Mon Jun 26 12:44:20 UTC 2017 : > On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > > ... > > > > Hmmm..... > > > > As if computer tries to say you, do not use meta mode. >=20 >=20 > For building the kernel, on head as of some commit after r320307 (but > by r320324). While there are other kernel issues going on I decided to try to investigate the difference in meta mode incremental build results vs. full rebuild. I started with head -r320192. This sequence avoids updating the live kernel (since other problems are being looked into). Local DESTDIR's are used for installkernel. # more ~/src.configs/src.conf.amd64-clang.amd64-host=20 TO_TYPE=3Damd64 # KERNCONF=3DGENERIC-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLVM_LIBUNWIND=3D WITH_LLDB=3D #PORTS_MODULES=3Demulators/virtualbox-ose-additions # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D Note the "WITH_REPRODUCIBLE_BUILD=3D". =46rom a -r320192 context I did: svnlite update -r320387 /usr/src I then used my usual script to do buildworld buildkernel. It updated = things in the pre-existing /usr/obj/amd64_clang/amd64.amd64/ . (I cause the explicit amd64.amd64 deliberately. This is not a cross build.) I'll note that I've been using /usr/obj/amd64_clang/amd64.amd64/ for incremental builds for a long time. (This will show up later.) I then used the script to: installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 I then moved /usr/obj/amd64_clang/ to be /usr/obj/amd64_clang_192_387/ = for later potential detailed comparisons. I then redid the buildworld = buildkernel=20 which produced another /usr/obj/amd64_clang/ but from scratch this time. I then used the script to: installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387 I then did (the D %C avoids date/time text being different): # ls -lD %C = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ = > ~/ls_192_387_kernel.txt # ls -lD %C = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ = > ~/ls_noth_387_kernel.txt allowing me to compare sizes and permissions: # diff -u ~/ls_192_387_kernel.txt ~/ls_noth_387_kernel.txt | more --- /root/ls_192_387_kernel.txt 2017-06-26 16:13:25.734588000 -0700 +++ /root/ls_noth_387_kernel.txt 2017-06-26 18:22:34.001866000 = -0700 @@ -1,4 +1,4 @@ -total 69163 +total 68995 -r-xr-xr-x 1 root wheel 107664 20 aac.ko -r-xr-xr-x 1 root wheel 105232 20 aacraid.ko -r-xr-xr-x 1 root wheel 6296 20 accf_data.ko @@ -270,7 +270,7 @@ -r-xr-xr-x 1 root wheel 41968 20 if_gre.ko -r-xr-xr-x 1 root wheel 41664 20 if_hme.ko -r-xr-xr-x 1 root wheel 18192 20 if_ic.ko -lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _em.ko +lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _em.ko -r-xr-xr-x 1 root wheel 24000 20 if_ipheth.ko -r-xr-xr-x 1 root wheel 78344 20 if_ipw.ko -r-xr-xr-x 1 root wheel 113544 20 if_iwi.ko @@ -419,7 +419,7 @@ -r-xr-xr-x 1 root wheel 12160 20 joy.ko -r-xr-xr-x 1 root wheel 46984 20 kbdmux.ko -r-xr-xr-x 1 root wheel 14168 20 kern_testfrwk.ko --r-xr-xr-x 1 root wheel 27479832 20 kernel +-r-xr-xr-x 1 root wheel 27307184 20 kernel -r-xr-xr-x 1 root wheel 105216 20 kgssapi.ko -r-xr-xr-x 1 root wheel 53840 20 kgssapi_krb5.ko -r-xr-xr-x 1 root wheel 163976 20 krpc.ko [Note: there is still a problem of if_igb.ko being handled as a full-pathj symbolic link such that copying kernels around=20 need not end up with a working if_igb.ko . I doubt that this is the problem that the reports are about.] The kernel from the incremental build is larger (includes more?). Of this the kernel being a different size would seem to be a problem. But going in a different direction that is more detailed (content comparison spanning all of boot, not just boot/kernel/ ): # diff -r = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/ = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/ | more Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ae= sni.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ae= sni.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/at= h_hal_ar5416.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/at= h_hal_ar5416.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ca= m.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ca= m.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/dt= race.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/dt= race.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/fa= sttrap.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/fa= sttrap.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ge= om_raid.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ge= om_raid.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ge= om_raid3.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ge= om_raid3.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _de.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _de.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _jme.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _jme.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _mxge.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _mxge.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _oce.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _oce.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _qlnxe.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _qlnxe.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _qlxge.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _qlxge.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _vr.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _vr.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _vtnet.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _vtnet.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ip= fw.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ip= fw.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ip= l.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ip= l.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ke= rnel and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ke= rnel differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/kr= pc.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/kr= pc.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nker.hints and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nker.hints differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nux.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nux.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nux64.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nux64.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/nf= scommon.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/nf= scommon.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/nf= sd.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/nf= sd.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ng= _ksocket.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ng= _ksocket.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/pf= .ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/pf= .ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/sn= d_emu10kx.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/sn= d_emu10kx.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/sy= svmsg.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/sy= svmsg.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/t4= _tom.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/t4= _tom.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/wl= an.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/wl= an.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/zf= s.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/zf= s.ko differ So a fair number of .ko files also end up being different by content for a from-scratch build, not just kernel . Going through looking at .o files for size and permissions. . . --- /root/ls_192_387_sys_o.txt 2017-06-26 16:54:32.669034000 -0700 +++ /root/ls_noth_387_sys_o.txt 2017-06-26 18:24:19.604302000 -0700 (So "+" is the from-scratch build again.) Some are different in size (just a couple of examples are shown of the many): --rw-r--r-- 1 root wheel 310240 20 ./GENERIC-NODBG/aacraid.o +-rw-r--r-- 1 root wheel 310264 20 ./GENERIC-NODBG/aacraid.o --rw-r--r-- 1 root wheel 128960 20 ./GENERIC-NODBG/ar9280_olc.o +-rw-r--r-- 1 root wheel 128976 20 ./GENERIC-NODBG/ar9280_olc.o Looking also at dates for the above (and any other name matches): aacraid.o . . . /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 310240 = Jun 19 22:38:55 2017 ./GENERIC-NODBG/aacraid.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 283504 = Jun 26 15:56:22 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/aacraid/aacraid.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 310264 = Jun 26 18:20:07 2017 ./GENERIC-NODBG/aacraid.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 283504 = Jun 26 18:16:44 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/aacraid/aacraid.o So for the incremental upgrade the module's aacraid.o was rebuilt but the non-module one was not updated. ar9280_olc.o . . . /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128960 = Jun 19 22:39:42 2017 ./GENERIC-NODBG/ar9280_olc.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128984 = May 3 02:38:30 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ar9280_olc.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 129000 = Jun 26 15:56:36 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath_hal_ar5416/ar9280_olc.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128976 = Jun 26 18:20:16 2017 ./GENERIC-NODBG/ar9280_olc.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 129024 = Jun 26 18:16:57 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath_hal_ar5416/ar9280_olc.o In this last case the number of files does not match: the "May 3" is extra. Again the module's .o was updated by the incremental build but the non-module one was not. Some exist only in the -r320192 -> -r320387 incremental build: (some omitted but incremental builds seem to not clean out old .o's from prior buildkernel activity in general) --rw-r--r-- 1 root wheel 46992 20 ./GENERIC-NODBG/amd64_mem.o --rw-r--r-- 1 root wheel 4176 20 ./GENERIC-NODBG/eisa_if.o --rw-r--r-- 1 root wheel 27064 20 ./GENERIC-NODBG/hv_heartbeat.o --rw-r--r-- 1 root wheel 87368 20 ./GENERIC-NODBG/hv_net_vsc.o --rw-r--r-- 1 root wheel 278712 20 = ./GENERIC-NODBG/hv_netvsc_drv_freebsd.o --rw-r--r-- 1 root wheel 101920 20 ./GENERIC-NODBG/hv_rndis_filter.o --rw-r--r-- 1 root wheel 27704 20 ./GENERIC-NODBG/hv_shutdown.o --rw-r--r-- 1 root wheel 38008 20 ./GENERIC-NODBG/hv_timesync.o --rw-r--r-- 1 root wheel 24640 20 ./GENERIC-NODBG/hv_util.o --rw-r--r-- 1 root wheel 590520 20 ./GENERIC-NODBG/if_igb.o --rw-r--r-- 1 root wheel 465848 20 ./GENERIC-NODBG/if_lem.o --rw-r--r-- 1 root wheel 86488 20 ./GENERIC-NODBG/ip_ipsec.o --rw-r--r-- 1 root wheel 153472 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah.o --rw-r--r-- 1 root wheel 99056 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_9287.o --rw-r--r-- 1 root wheel 90416 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v1.o --rw-r--r-- 1 root wheel 100608 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v14.o --rw-r--r-- 1 root wheel 151288 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v3.o . . . --rw-r--r-- 1 root wheel 245592 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/if_ath_tx_edma.o --rw-r--r-- 1 root wheel 226432 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/if_ath_tx_ht.o --rw-r--r-- 1 root wheel 289928 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/sample.o --rw-r--r-- 1 root wheel 18440 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram.o --rw-r--r-- 1 root wheel 161840 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram_common.o --rw-r--r-- 1 root wheel 67320 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram_parser.o --rw-r--r-- 1 root wheel 40488 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_sprom_parser.o --rw-r--r-- 1 root wheel 34728 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_sprom_subr.o --rw-r--r-- 1 root wheel 31976 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/bhnd_spr= om_chipc.o --rw-r--r-- 1 root wheel 115256 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/chipc.o --rw-r--r-- 1 root wheel 46264 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/chipc_su= br.o --rw-r--r-- 1 root wheel 133560 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/nvram_subr.o --rw-r--r-- 1 root wheel 247344 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ctl/ctl_frontend_iscsi.o --rw-r--r-- 1 root wheel 162408 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/cxgbe/cxgbei/cxgbei_ulp2_ddp.o= --rw-r--r-- 1 root wheel 174752 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_dma.o --rw-r--r-- 1 root wheel 120016 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_drv.o --rw-r--r-- 1 root wheel 141880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_irq.o --rw-r--r-- 1 root wheel 134000 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_mem.o --rw-r--r-- 1 root wheel 136912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_suspend.o --rw-r--r-- 1 root wheel 208104 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r300_cmdbuf.o --rw-r--r-- 1 root wheel 174912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r600_blit.o --rw-r--r-- 1 root wheel 339512 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r600_cp.o --rw-r--r-- 1 root wheel 245632 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_cp.o --rw-r--r-- 1 root wheel 156736 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_cs.o --rw-r--r-- 1 root wheel 140072 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_drv.o --rw-r--r-- 1 root wheel 139608 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_irq.o --rw-r--r-- 1 root wheel 129824 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_mem.o --rw-r--r-- 1 root wheel 352464 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_state.o --rw-r--r-- 1 root wheel 816 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/dtrace/dtrace/assym.o --rw-r--r-- 1 root wheel 430976 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/em/if_lem.o --rw-r--r-- 1 root wheel 117376 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/en/if_en_pci.o --rw-r--r-- 1 root wheel 236040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/en/midway.o --rw-r--r-- 1 root wheel 282368 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/fatm/if_fatm.o --rw-r--r-- 1 root wheel 83520 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/geom/geom_part/geom_part_pc98/= g_part_pc98.o --rw-r--r-- 1 root wheel 310872 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm.o --rw-r--r-- 1 root wheel 93040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_intr.o --rw-r--r-- 1 root wheel 77992 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_ioctl.o --rw-r--r-- 1 root wheel 77784 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_rx.o --rw-r--r-- 1 root wheel 151736 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_tx.o --rw-r--r-- 1 root wheel 86872 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_net_vsc.o --rw-r--r-- 1 root wheel 243992 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_netvsc_drv_fr= eebsd.o --rw-r--r-- 1 root wheel 101480 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_rndis_filter.= o --rw-r--r-- 1 root wheel 27240 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_heartbeat.= o --rw-r--r-- 1 root wheel 27880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_shutdown.o= --rw-r--r-- 1 root wheel 38184 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_timesync.o= --rw-r--r-- 1 root wheel 24824 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_util.o --rw-r--r-- 1 root wheel 125184 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_80003es2lan.o --rw-r--r-- 1 root wheel 78984 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82540.o --rw-r--r-- 1 root wheel 95856 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82541.o --rw-r--r-- 1 root wheel 69624 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82542.o --rw-r--r-- 1 root wheel 125888 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82543.o --rw-r--r-- 1 root wheel 166040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82571.o --rw-r--r-- 1 root wheel 240320 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82575.o --rw-r--r-- 1 root wheel 91168 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_api.o --rw-r--r-- 1 root wheel 96536 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_i210.o --rw-r--r-- 1 root wheel 342880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_ich8lan.o --rw-r--r-- 1 root wheel 167104 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_mac.o --rw-r--r-- 1 root wheel 76168 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_manage.o --rw-r--r-- 1 root wheel 82936 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_mbx.o --rw-r--r-- 1 root wheel 100096 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_nvm.o --rw-r--r-- 1 root wheel 52456 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_osdep.o --rw-r--r-- 1 root wheel 177672 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_phy.o --rw-r--r-- 1 root wheel 59088 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_vf.o --rw-r--r-- 1 root wheel 554784 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/if_igb.o --rw-r--r-- 1 root wheel 50496 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mcd/mcd_isa.o --rw-r--r-- 1 root wheel 47072 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mem/amd64_mem.o --rw-r--r-- 1 root wheel 26888 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mmcsd/mmc_subr.o --rw-r--r-- 1 root wheel 55000 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/msdosfs/msdosfs_fileno.o --rw-r--r-- 1 root wheel 142248 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm.o --rw-r--r-- 1 root wheel 152064 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_attach.o --rw-r--r-- 1 root wheel 102056 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_intr.o --rw-r--r-- 1 root wheel 75560 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_ioctl.o --rw-r--r-- 1 root wheel 40592 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_rtables.o --rw-r--r-- 1 root wheel 107744 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_rx.o --rw-r--r-- 1 root wheel 167912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_tx.o --rw-r--r-- 1 root wheel 19080 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/rtwnfw/rtwnrtl8192cUB/rtwn-rtl= 8192cfwU_B.o --rw-r--r-- 1 root wheel 96288 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/scd/scd.o --rw-r--r-- 1 root wheel 49512 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/scd/scd_isa.o --rw-r--r-- 1 root wheel 96376 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/sfxge/efx_wol.o --rw-r--r-- 1 root wheel 80552 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/sfxge/hunt_phy.o --rw-r--r-- 1 root wheel 75160 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si.o --rw-r--r-- 1 root wheel 11952 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si2_z280.o --rw-r--r-- 1 root wheel 24904 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si3_t225.o --rw-r--r-- 1 root wheel 37416 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si_isa.o --rw-r--r-- 1 root wheel 33280 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si_pci.o --rw-r--r-- 1 root wheel 617464 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwn/if_urtwn.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8188eu/urtwn-r= tl8188eufw.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8192cT/urtwn-r= tl8192cfwT.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8192cU/urtwn-r= tl8192cfwU.o --rw-r--r-- 1 root wheel 55040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/idtphy.o --rw-r--r-- 1 root wheel 53400 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/suni.o --rw-r--r-- 1 root wheel 123216 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/utopia.o --rw-r--r-- 1 root wheel 12952 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/vmm/amdv.o --rw-r--r-- 1 root wheel 204240 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/zfs/gfs.o --rw-r--r-- 1 root wheel 54880 20 ./GENERIC-NODBG/msdosfs_fileno.o --rw-r--r-- 1 root wheel 75480 20 ./GENERIC-NODBG/nvme_all.o --rw-r--r-- 1 root wheel 125568 20 ./GENERIC-NODBG/nvme_xpt.o --rw-r--r-- 1 root wheel 82296 20 ./GENERIC-NODBG/procfs_ctl.o --rw-r--r-- 1 root wheel 77320 20 ./GENERIC-NODBG/vm_unix.o --rw-r--r-- 1 root wheel 892 20 ./boot/geli/explicit_bzero.o (The somewhat manual process might have put a few extra lines above.) If any of this is picked up and linked in to kernel it might explain part of the kernel file size difference: 27479832 - 27307184 =3D=3D 172648 . I stop with this for now. It seems that as things are that one should clean out the buildkernel materials at least for some types of build contexts before doing another buildkernel. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 27 06:31:11 2017 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 359B9DA24E2 for ; Tue, 27 Jun 2017 06:31:11 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF7407D914 for ; Tue, 27 Jun 2017 06:31:10 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by fc.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dPk1j-000EPG-RI for freebsd-current@freebsd.org; Tue, 27 Jun 2017 08:31:07 +0200 Date: Tue, 27 Jun 2017 08:31:07 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Subject: Compiler more strict on 12 with r320337 ? Message-ID: <20170627063107.GB1256@fc.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 06:31:11 -0000 Hi! Compiling devel/lfcbase, it fails while including sys/socketvar.h with this error: In file included from Net.cc:36: /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an anonymous struct enum { ^ 1 error generated. Should sys/socketvar.h be included at all ? -- pi@FreeBSD.org +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Tue Jun 27 07:57:42 2017 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 2C052DA3E53 for ; Tue, 27 Jun 2017 07:57:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 BE03D8045B for ; Tue, 27 Jun 2017 07:57:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21280 invoked from network); 27 Jun 2017 07:57:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Jun 2017 07:57:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 27 Jun 2017 03:57:39 -0400 (EDT) Received: (qmail 31740 invoked from network); 27 Jun 2017 07:57:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Jun 2017 07:57:38 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 27688EC8143; Tue, 27 Jun 2017 00:57:38 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Compiler more strict on 12 with r320337 ? Message-Id: <63CEB3B7-5CAD-438E-8ABF-9BC5601FD544@dsl-only.net> Date: Tue, 27 Jun 2017 00:57:37 -0700 To: Jaeger Kurt , glebius@FreeBSD.org, FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 07:57:42 -0000 Kurt Jaeger lists at opsec.eu wrote on Tue Jun 27 06:31:11 UTC 2017 : > Compiling devel/lfcbase, it fails while including sys/socketvar.h with > this error: > > In file included from Net.cc:36: > /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an > anonymous struct > enum { > ^ > 1 error generated. The rejected syntax in socketvar.h was added in -r319722 : To: revision 319722 by glebius, Thu Jun 8 21:30:34 2017 UTC From: revision 319641 by glebius, Wed Jun 7 01:48:11 2017 UTC and so is fairly recent. So if that is more recent than the most recent compile that worked for you then it may not be a compiler change at all. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 27 08:15:31 2017 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 A40A9DA4552 for ; Tue, 27 Jun 2017 08:15:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 667CF80E81 for ; Tue, 27 Jun 2017 08:15:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x234.google.com with SMTP id c73so12912042pfk.2 for ; Tue, 27 Jun 2017 01:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=+RqSPCy1JzRhtwxHSdTxFsxZY2E1eL2DquWq0PV5WI0=; b=HugxMdgjHSdmlfwp064q5lZ9Xu0oOv6/+BjsKTUujdG+gTHSWS1IUvWE09NqUoaA7B PRISA3Si/i2hePJp8vFqyzCMI+ASzfDe14XSuMTjEMN6qaZz8mzDjDjjUV56/HGXP4uN wQeC8s9FIBPAmxpHCE6rHtOEpojbyJK3uR27hvF/JvMAbgl3bg+5QZDp3FG5tj5a0pLr 6c4Iu+7WnKJK0T+8d9G/iJZpD4uikl5t5FXw7zPaObJYwxnpJryyz1ogfnwbHVQ+4riP egyz57rSLCNFtvkHJFQouxr52PBaKFyDccZxOpjMrgYLuh96bnPCA9DhiHRyBPfBG0QA 1awA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=+RqSPCy1JzRhtwxHSdTxFsxZY2E1eL2DquWq0PV5WI0=; b=RlE3t4WoLgs8scazLwPawLYrGe9utElx0EXbom07l+i8mEsaT+B+ZDHNUA9DuxWvtN /BUFug//fNoTIGtHGhAmWYfHoJfTIMncuh4F1IolO5Hbz3REclhVns3xeIMtHWNlKepZ QQYN/lbdB+70X55uCsxMzMfk6gshKsQfq8ReWyXDZ8Une6P4IMLTCF1pP226U7P9bp+r pO1QagQaIR3rPzWoGYdLb41LUnjA34atk/0D8RP9CMQ5FEzRtvcNsnfuuLfSawG5eHTl 96stJ+tv1BjYzvv6jHDX4tFKDVE5n1J6bYk8L9kmJJ8zuJd97JqEYZL792bMqEuuPl/x U32Q== X-Gm-Message-State: AKS2vOwNXIkPLS0IvHGk0J2hUEvOqwglCWNXhrWmqa0Knpqo46pf+KPQ 5m+ipzxpljjHK9DxoRI= X-Received: by 10.99.123.81 with SMTP id k17mr4096707pgn.71.1498551330751; Tue, 27 Jun 2017 01:15:30 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id c22sm4886336pfl.97.2017.06.27.01.15.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Jun 2017 01:15:30 -0700 (PDT) Subject: Re: Compiler more strict on 12 with r320337 ? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_288D0A0A-912E-4422-8CBB-63E3E2B79D4B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170627063107.GB1256@fc.opsec.eu> Date: Tue, 27 Jun 2017 01:15:28 -0700 Cc: freebsd-current@freebsd.org Message-Id: References: <20170627063107.GB1256@fc.opsec.eu> To: Kurt Jaeger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 08:15:31 -0000 --Apple-Mail=_288D0A0A-912E-4422-8CBB-63E3E2B79D4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 26, 2017, at 23:31, Kurt Jaeger wrote: >=20 > Hi! >=20 > Compiling devel/lfcbase, it fails while including sys/socketvar.h with > this error: >=20 > In file included from Net.cc:36: > /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in = an > anonymous struct > enum { > ^ > 1 error generated. >=20 > Should sys/socketvar.h be included at all ? Hi Kurt, What compiler/CFLAGS (in particular, -std=3D) are you using = to compile devel/lfcbase? Thanks! -Ngie --Apple-Mail=_288D0A0A-912E-4422-8CBB-63E3E2B79D4B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZUhQhAAoJEPWDqSZpMIYVwXgQAIGevJPHS0uG+sts4/mGDVrQ 0aJCpXsIi5lNvlwLvKizMel2BdH1OpN2gDrVcqTemQMQJ2YfmWvfpSpMzY4FC5dg 3x3zCtS5sXjpGM3IlAvWZllSZJhjH5t+TQbiykz6EG4teDSzdmAC+C617OCV+U9e c1uEqa+QTl4Yn8ACIySOnFEx0gzeS19gqooV3wwPm0Kmv8a1iwu6CuPYqhlL8nmy Y4izmr4VHo+rwpCP+/0gEdTJPKEqzyd2vZBas1aKassQwJpHM8mHZDRZssyyrfqa o1TqTwasiha8LEOebLfD5yJEYxyJo1DgV8tdRUXenFoCp+7ENyThjJrbxhF70wiT UXbqyyawHWiH9M3Nlbbxv3zp273a7KvH3U48RuSg3WjTpsfEojNUQ4943Q1FRkVt NCAYONc5pguk9mHAG/DBRwdqgCgXnt8U2SGT84LYmUBycMNtXkOnZNMZr3OYSktQ zEbALR6wosT4KzZ/W4F4upLV6qbxYGS+/wQbv4kuIxhAzGRcDRaYLdm52SkN+iFQ s+/KHu7SK58qR2lkXSlP+0p1o5CiFV5gWWTcvF+oDo2LVEiwOfmxNWxtOHqJvJC7 8zeAE1AZczd+jNhc1Zz8s0rY40ae3M1USHMTzUdJAXW+88oX95iNZ21fPvt/33Gc Uv7M6yanJYhkjP4Oriz+ =xHF0 -----END PGP SIGNATURE----- --Apple-Mail=_288D0A0A-912E-4422-8CBB-63E3E2B79D4B-- From owner-freebsd-current@freebsd.org Tue Jun 27 11:02:27 2017 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 EABE0DA74C6 for ; Tue, 27 Jun 2017 11:02:27 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward8p.cmail.yandex.net (forward8p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A89271601; Tue, 27 Jun 2017 11:02:27 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b6:7]) by forward8p.cmail.yandex.net (Yandex) with ESMTP id CB80721176; Tue, 27 Jun 2017 14:02:24 +0300 (MSK) Received: from smtp2p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2p.mail.yandex.net (Yandex) with ESMTP id 16DF01A80080; Tue, 27 Jun 2017 14:02:23 +0300 (MSK) Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 0dyPPr8vrl-2NUm7OQw; Tue, 27 Jun 2017 14:02:23 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1498561343; bh=qdqkpYeb7n4GQ6U078DFAtg1H7FOQZHy28yDdTVwy6M=; h=To:From:Subject:Message-ID:Date; b=bJUd4ICg1fpQhPnCrPouSPnhpb8FiHJcUYdsKFRronKk5RbWUKk13uXKA5TXKxA7j cUQvYONGA2oJqnlAlZJbQcDivYvlGdQkX+dXsC5PVEFDuPLYqzueznWRRApoaRg8rb /A6f/oLrf0Mgmr4Xmiam1DP58VuL9zDoCeDDmiXk= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0,1 0 To: freebsd-current@FreeBSD.org, trasz@FreeBSD.org From: Boris Samorodov Subject: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory Message-ID: <0b7fa203-93eb-ff2d-ad14-507fcbbf75d1@passap.ru> Date: Tue, 27 Jun 2017 14:00:15 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 11:02:28 -0000 Hi, I regularly build base packages for FreeBSD-HEAD-amd64. After jump from r320347 to r320392 (build world/kernel are fine) I get an error while package building (make -C /usr/src packages): ----- --- realinstall_subdir_share --- --- realinstall_subdir_share/zoneinfo --- install: builddir/Africa/Abidjan: No such file or directory *** [install-zoneinfo] Error code 71 ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Tue Jun 27 11:20:11 2017 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 A5AEADA79F7 for ; Tue, 27 Jun 2017 11:20:11 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 6C77B1E6D for ; Tue, 27 Jun 2017 11:20:11 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dPoXT-000JOb-Q6; Tue, 27 Jun 2017 13:20:11 +0200 Date: Tue, 27 Jun 2017 13:20:11 +0200 From: Kurt Jaeger To: "Ngie Cooper (yaneurabeya)" Cc: freebsd-current@freebsd.org Subject: Re: Compiler more strict on 12 with r320337 ? Message-ID: <20170627112011.GC65214@home.opsec.eu> References: <20170627063107.GB1256@fc.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 11:20:11 -0000 Hi! > > Compiling devel/lfcbase, it fails while including sys/socketvar.h with > > this error: > > > > In file included from Net.cc:36: > > /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an > > anonymous struct > > enum { > > ^ > > 1 error generated. > > > > Should sys/socketvar.h be included at all ? > > Hi Kurt, > What compiler/CFLAGS (in particular, -std=) are you using to compile devel/lfcbase? http://people.freebsd.org/~pi/logs/lfcbase.txt says: /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. -O3 -O2 -pipe -fstack-protector -fno-strict-aliasing -MT Net.lo -MD -MP -MF .deps/Net.Tpo -c -o Net.lo Net.cc and: c++ --version says: FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Tue Jun 27 11:45:47 2017 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 5E680DA828B for ; Tue, 27 Jun 2017 11:45:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24AD82D4E; Tue, 27 Jun 2017 11:45:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 88FD0325A5; Tue, 27 Jun 2017 13:45:37 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DC409271-CBD8-4F7D-9B72-09B9DC179BE8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Compiler more strict on 12 with r320337 ? Date: Tue, 27 Jun 2017 13:45:26 +0200 In-Reply-To: <20170627112011.GC65214@home.opsec.eu> Cc: "Ngie Cooper (yaneurabeya)" , FreeBSD Current , Gleb Smirnoff To: Kurt Jaeger References: <20170627063107.GB1256@fc.opsec.eu> <20170627112011.GC65214@home.opsec.eu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 11:45:47 -0000 --Apple-Mail=_DC409271-CBD8-4F7D-9B72-09B9DC179BE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Jun 2017, at 13:20, Kurt Jaeger wrote: >=20 > Hi! >=20 >>> Compiling devel/lfcbase, it fails while including sys/socketvar.h = with >>> this error: >>>=20 >>> In file included from Net.cc:36: >>> /usr/include/sys/socketvar.h:117:4: error: types cannot be declared = in an >>> anonymous struct >>> enum { >>> ^ >>> 1 error generated. >>>=20 >>> Should sys/socketvar.h be included at all ? >>=20 >> Hi Kurt, >> What compiler/CFLAGS (in particular, -std=3D) are you using = to compile devel/lfcbase? >=20 > http://people.freebsd.org/~pi/logs/lfcbase.txt >=20 > says: >=20 > /bin/sh ../libtool --tag=3DCXX --mode=3Dcompile c++ = -DHAVE_CONFIG_H -I. -I.. -O3 -O2 -pipe -fstack-protector = -fno-strict-aliasing -MT Net.lo -MD -MP -MF .deps/Net.Tpo -c -o Net.lo = Net.cc Ah, this is because you're compiling the header as C++. Normally values like SQ_NONE, SQ_INCOMP etc are defined as preprocessor macros, not enum values. Either that should be done, or define the enum should be declared outside the struct. -Dimitry --Apple-Mail=_DC409271-CBD8-4F7D-9B72-09B9DC179BE8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllSRV8ACgkQsF6jCi4glqMVcwCePi0RhM2OpzaC0Iswoh1vmsdl UhMAn3HQa/NKcchB3DrEhxuBzlwxrzhb =6nnA -----END PGP SIGNATURE----- --Apple-Mail=_DC409271-CBD8-4F7D-9B72-09B9DC179BE8-- From owner-freebsd-current@freebsd.org Tue Jun 27 14:13:24 2017 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 5F4AFD8672B for ; Tue, 27 Jun 2017 14:13:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86EF067EB1 for ; Tue, 27 Jun 2017 14:13:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08845; Tue, 27 Jun 2017 17:13:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dPrEp-00071V-ST; Tue, 27 Jun 2017 17:13:07 +0300 Subject: Re: ZFS ABD Panic To: Shawn Webb , freebsd-current@FreeBSD.org References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> From: Andriy Gapon Message-ID: <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> Date: Tue, 27 Jun 2017 17:12:01 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 14:13:24 -0000 On 26/06/2017 03:31, Shawn Webb wrote: > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0xfffff803b7d4e810 with sleeping prohibited > [141] cpuid = 5 > [141] time = 1498436043 > [141] KDB: stack backtrace: > [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00002fc8b0 > [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 > [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 > [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 > [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fcaa0 > [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 > [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfffffe00002fcb20 > [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 > [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe00002fcb70 > [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002fcba0 > [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 > [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 > [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcbf0 Seems like another architectural incompatibility between illumos and FreeBSD. Are you able to reproduce the crash more or less reliably? -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Jun 27 14:16:25 2017 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 D38E8D86904 for ; Tue, 27 Jun 2017 14:16:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 8B678681AE for ; Tue, 27 Jun 2017 14:16:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22a.google.com with SMTP id i2so25324723qta.3 for ; Tue, 27 Jun 2017 07:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DO+w0mtTvrNJxJ3tGz3dZVEx0M8r2yI2xFFaIzLJ2Ys=; b=c5cvtfyJRuAZdeBJdqplTY1YDIPI66eL4J7RRUdnZsTTHHkX3OZWzgxUz0mEOPr5JU UabI3amI/1xmE5h6U4u+WFv42WlxFrFRgXHXDO8ZPrYUM3+rb/jQLAIY/drTjTiYIn52 B0g4f5cnkTm0NOUVNgEFEtp9+pqZl7y9OTG6IHDA38BUmIATNq0/i5zJZLmjpR+B3sxa P+WVClMSODUWmerPsCyrq11rEdLu+X24qLgSTd7JYRsHbTDydJN5TFMdG2xA1fll6TA/ 2Y9+Crati2q9yY2qxgp/dXsKL9FDqerIBCpYDT2U3jZVUJoBaRGu0L+xEOsWIehpxhGs 44mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DO+w0mtTvrNJxJ3tGz3dZVEx0M8r2yI2xFFaIzLJ2Ys=; b=n+y9AnkP3aYyL1OOvplzL1oaCnAEzJQ0yja+BZQxNiLIHXWRYEQffNW4hdzHZZ8I26 Dc98FRVLOekuOzRnOek+9fRTkFn6/HuMeE+GMhLfhn44nNlYcqMFML5v9psqMjPUciji qnq8+RYlaqURBuacJoy9MuXeqJv2S6Sl1xWDQqHRhrV1G1O7vS4lh0cvTUfVM7U90iGZ RckVBno6Xxav3GWfh6CtQ5kTOwm4/vOzj9im/fyJYD0YDHAXihcdkKkWBuVas/kODYYH XmkRwfp0+2fQAhx8rpEouyVRcHEd/CKQh8YXttIn9nd2PlG1XMMPEmP9Xkee4bUlif7a WuZA== X-Gm-Message-State: AKS2vOx1ZyotFXwCaEu4h34oAVrTSZsbRzlWrHuIo4fvJPtngBZsiY5i MnGUpkWZNFdpxruhAQ/dNw== X-Received: by 10.237.59.80 with SMTP id q16mr7351920qte.143.1498572984595; Tue, 27 Jun 2017 07:16:24 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id c4sm2578259qtc.1.2017.06.27.07.16.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Jun 2017 07:16:23 -0700 (PDT) Date: Tue, 27 Jun 2017 10:16:21 -0400 From: Shawn Webb To: Andriy Gapon Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS ABD Panic Message-ID: <20170627141621.eflvmf53goy45dzh@mutt-hbsd> References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xchcf45sp5c3xlav" Content-Disposition: inline In-Reply-To: <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 14:16:25 -0000 --xchcf45sp5c3xlav Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > On 26/06/2017 03:31, Shawn Webb wrote: > > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > >=20 > > [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0xffff= f803b7d4e810 with sleeping prohibited > > [141] cpuid =3D 5 > > [141] time =3D 1498436043 > > [141] KDB: stack backtrace: > > [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfff= ffe00002fc8b0 > > [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 > > [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 > > [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 > > [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fcaa0 > > [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 > > [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfffff= e00002fcb20 > > [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 > > [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe0000= 2fcb70 > > [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002fc= ba0 > > [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 > > [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 > > [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcbf0 >=20 > Seems like another architectural incompatibility between illumos and Free= BSD. > Are you able to reproduce the crash more or less reliably? Yup. I just need to do a buildworld and it's triggered. --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --xchcf45sp5c3xlav Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAllSaLMACgkQaoRlj1JF bu4eFxAArn29VrQXG2Soqh7ifWiOed3R5K05Rovk7xANXMRrVH2rbB3v5oJbZATO gkl2LvepsrOlZRfXTXVSIL4K7I+Log8pkOBILoHfBqTJ4U04Rzs8SBRAh4rhvk00 BNsN3r0H76L0hY8pX+GYI9B6T1PXxyLUXC6D3ajWKb0AXoA+Nwm4hiZVV2/n3GkV qBrkkIqEMvc9YMxBVptzUGdntuCZPs4tUJh1LGjtofXaG3JjrJPyjNhFXviEPnuv PlNTWsohC/pfrOHs9VUNp3FhCN3nCRSU2pKS9BaB3lp2XJHL+FlgxrkQoaqKRlng HSmjSMEs8wPMBn2IE0Q7Wkavj4rym7H71LQgXPtEdNITi0gbMKcJgkft4afmQex9 QH9mgvZdZSSK7d/gVZfisObL3YekIYqyMTf7/q6uVpUfccS+Msp2lINlS25MXmyo vfqIjkgqUeMqK4EoGuPmUZ+niiiQQm1FJkH3rj9Wu3TTlqzQWK6NIhsT8iSpRIFj wD0zDle5B1XWkbjrN9YYtSKsnOrztz2nT7DMyBOgIZ1IhD3/aQsVV4SL4XlAMUhb HyFG4DS+hrOJ3M72VQaYSWa+rEchmbJm/LIZjlPZbsl1b/5HQ5DK+Yjgj71lYtK7 dJtuuzT+mfu1lC3Vo864urUatOc41N7UI/jNKHEDJk4X0jlZxAg= =pjrm -----END PGP SIGNATURE----- --xchcf45sp5c3xlav-- From owner-freebsd-current@freebsd.org Tue Jun 27 14:23:07 2017 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 78410D86C00 for ; Tue, 27 Jun 2017 14:23:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7E63C685E1 for ; Tue, 27 Jun 2017 14:23:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08874; Tue, 27 Jun 2017 17:23:02 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dPrOQ-000724-3R; Tue, 27 Jun 2017 17:23:02 +0300 Subject: Re: ZFS ABD Panic To: Shawn Webb Cc: freebsd-current@FreeBSD.org References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> <20170627141621.eflvmf53goy45dzh@mutt-hbsd> From: Andriy Gapon Message-ID: <8798c2ee-fedf-0641-ffe5-9533d78bc6a2@FreeBSD.org> Date: Tue, 27 Jun 2017 17:22:39 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170627141621.eflvmf53goy45dzh@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 14:23:07 -0000 On 27/06/2017 17:16, Shawn Webb wrote: > On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: >> On 26/06/2017 03:31, Shawn Webb wrote: >>> This is on the latest HardenedBSD 12-CURRENT on one of my servers: >>> >>> [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0xfffff803b7d4e810 with sleeping prohibited >>> [141] cpuid = 5 >>> [141] time = 1498436043 >>> [141] KDB: stack backtrace: >>> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00002fc8b0 >>> [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 >>> [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 >>> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 >>> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fcaa0 >>> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 >>> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfffffe00002fcb20 >>> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 >>> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe00002fcb70 >>> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002fcba0 >>> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 >>> [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 >>> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcbf0 >> >> Seems like another architectural incompatibility between illumos and FreeBSD. >> Are you able to reproduce the crash more or less reliably? > > Yup. I just need to do a buildworld and it's triggered. > Could you please test this patch? http://dpaste.com/12M183A.txt I put it together rather quickly, but I think that it should work :) -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Jun 27 14:25:19 2017 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 AF629D86D57 for ; Tue, 27 Jun 2017 14:25:19 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 62B8068752 for ; Tue, 27 Jun 2017 14:25:19 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22c.google.com with SMTP id r62so26309553qkf.0 for ; Tue, 27 Jun 2017 07:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qq5wakTsQZxCkCd3MPbu3QBW1Z7NX1q0/VfqW19wlh4=; b=k1YeCZep8R+hUr5fmog5Rkjhe/wvcj6vUpknrZdAwzTjq0H1870nmtyrORqDnk79RK qiQGVNF1dLzV/cpTgA1l6N0sl143dZWwCnyKstsfemSpVcnjr4m+Qo5CgWq51W2xm6gL 4dvVFFdwf/jgQju1flcXZvzUooMkXSdWFm+12jjILfKPUxggLFbpsaq59Bl8rlOiaCCa kGMgjSXNHIJfd+xcqoIuZHSlUCwiDYkpyzKij1woZIjNP2TYlWGoYjA2idaLOKPw+dog NkziAcuN2RT9+GoUz02Puns9icMF3SBgt3HabHRamgG+bh+uqbcCt6o447wqO4tWJoxo 8WPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qq5wakTsQZxCkCd3MPbu3QBW1Z7NX1q0/VfqW19wlh4=; b=sdQyWUoMwwnUbDnBPdTp1mjOWgyuNCDMAhfD2KVUh4w46JmBVD3QJrADOaEk9Qzgav wLIC0c77MN1H3dfV1omP2qGlS85Cze/cOIa/3oBHmPmzeqj0c5x39MnzvntAwrbf60/G gPoiAhZ/A84JzN2THFPaIBu+kDYT8rk/spB47CQJ+T9PSOlvB2wAcOMTRtH5tdedxMvX H9/+rUWF+Lsr8z+W0BUN0ThBDfA/wABsZxqlaHatEHOPI9LgGukZdfUB5ptU8mdqaA4T YFbKGMYTzbyZGsK5e3OtSqUfmLRpnfvRSoIzhYXYA9GcrKJMNykIFIoGscsDOSaZZwjh 1ouw== X-Gm-Message-State: AKS2vOzo4oB94USYm5PZhsDjvaqepxd0gDh8H/KW0TED2iDozfqiHJiW OGvoy8xbpngPSrYW2sYdVA== X-Received: by 10.55.73.215 with SMTP id w206mr6797413qka.232.1498573518284; Tue, 27 Jun 2017 07:25:18 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id h17sm1990561qte.20.2017.06.27.07.25.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Jun 2017 07:25:17 -0700 (PDT) Date: Tue, 27 Jun 2017 10:25:16 -0400 From: Shawn Webb To: Andriy Gapon Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS ABD Panic Message-ID: <20170627142516.wuveh44jomoagnng@mutt-hbsd> References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> <20170627141621.eflvmf53goy45dzh@mutt-hbsd> <8798c2ee-fedf-0641-ffe5-9533d78bc6a2@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e54jnrmpxetbp3k2" Content-Disposition: inline In-Reply-To: <8798c2ee-fedf-0641-ffe5-9533d78bc6a2@FreeBSD.org> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 14:25:19 -0000 --e54jnrmpxetbp3k2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 05:22:39PM +0300, Andriy Gapon wrote: > On 27/06/2017 17:16, Shawn Webb wrote: > > On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > >> On 26/06/2017 03:31, Shawn Webb wrote: > >>> This is on the latest HardenedBSD 12-CURRENT on one of my servers: > >>> > >>> [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0xff= fff803b7d4e810 with sleeping prohibited > >>> [141] cpuid =3D 5 > >>> [141] time =3D 1498436043 > >>> [141] KDB: stack backtrace: > >>> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xf= ffffe00002fc8b0 > >>> [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 > >>> [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9a0 > >>> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 > >>> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002fca= a0 > >>> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 > >>> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfff= ffe00002fcb20 > >>> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fcb50 > >>> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe00= 002fcb70 > >>> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe00002= fcba0 > >>> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 > >>> [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 > >>> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002fcb= f0 > >> > >> Seems like another architectural incompatibility between illumos and F= reeBSD. > >> Are you able to reproduce the crash more or less reliably? > >=20 > > Yup. I just need to do a buildworld and it's triggered. > >=20 >=20 > Could you please test this patch? > http://dpaste.com/12M183A.txt > I put it together rather quickly, but I think that it should work :) Can do later today. I'll report back either tonight or tomorrow. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --e54jnrmpxetbp3k2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAllSassACgkQaoRlj1JF bu6NZw//ccPtuCl2GZot3MVS0H++gdmFE0BjoZIOWOwouoXjLZTKbPkco6BycqWT IxzY4sdh5LZ7BS71xpERUkJ3EfhAS5Yp13QekT2CWOdawuue6YbQ1r03EtCo6Qxb cTKwVB+B5PgBn2Ly7jvcLfLMEehKFD/EymLip7I6R7ZacqMjlgw73BGhaKRO9Qux PcCNSkQ+dlXHTOfPa3PGYRVEbhRc4JRKI36r9JOQ5LJ1pbZidGOwYEdVdIErEjeN 98eCqP82VhC+rpT54D9wcSbHbNNk6xOgW0UhYlplVMnUxAqQ2YhgALnqFPxqby5P WrWT84XvEbMUHblVWSlaA20yL7jfe5aTxCN3ToYlW0qN1PvDV/Z38uzzIm7qf/sd fnDhPEopE76MRqmjmfUWdkcv4jNyE2BV6SRsrCA3UMZ9fN2OlZrslIVw7s5/Q8O1 6L27L0Vb4dccCU0Wq4HjVbNtKwY7jydpasGQWHVum7NLQjr9HSuMB7CowSO7eXaw /HDKGFhAoqYkVqAQ/Cwtd5Ehko+fkZ6cuSeaYrV21lf9iANrqB5BwN9Oz+YEKlJ1 NDJl4A/f1IU+owQmHjQNihIT65jr4nY1S2FOMd6Jnppk5s4j1kyVb4ht5HWft21z tgukxqMOEvSbvxWUxIJrXcJn0Ug5ZA/fxwMBau3pgUbgXzCzlPs= =zhFH -----END PGP SIGNATURE----- --e54jnrmpxetbp3k2-- From owner-freebsd-current@freebsd.org Tue Jun 27 16:10:02 2017 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 1457DD88E11 for ; Tue, 27 Jun 2017 16:10:02 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF80F70028 for ; Tue, 27 Jun 2017 16:10:01 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.2/8.15.2) with ESMTPS id v5RG9w5u009671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 27 Jun 2017 12:09:59 -0400 (EDT) (envelope-from mikej@mikej.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 mx2.paymentallianceintl.com v5RG9w5u009671 Authentication-Results: mx2.paymentallianceintl.com; sender-id=pass header.from=mikej@mikej.com; spf=pass smtp.mfrom=mikej@mikej.com X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id v5RG9vqP015815 for ; Tue, 27 Jun 2017 12:09:57 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com v5RG9vqP015815 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com v5RG9vqP015815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1498579797; bh=l7v5KlcoWnmVFH0DP2tysvXOBAa1BvIC7CbiJcYrQDE=; h=Date:From:To:Subject:In-Reply-To:References; b=BkZ1BJeiUe7OKxFbYKGWSBohXMzc7MaZMzl7VwhUXmb4+HVHpgK1JRSd7NzY+GO/p 2AGZJsHhhRcdezXzwjN6q29gdW0Jz9+VUSV1P1rcI2ZbKBGoy9UFpt0AhNKtsXcTXb P1d/YKZXss3oyBDkZWbQNxdyxo2jfx1ldX3SGGPGChjmd3C1vRuv4H3qAm91yeeza2 P/cWMu4Nw4/QTBxn6RPWUp7R5CDdlmhzbJTN91RPTa4pzlxd7ekOIzrf9ZGaipBPgs rYf4QU6qGGgTm4c8QxfbTRHfteKB3XiNewXnzawVvbjZcgYttuRNWcKoeHkcB0z+hY LNJ9NiYo4yKmQ== X-Authentication-Warning: firewall.mikej.com: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 Jun 2017 12:09:56 -0400 From: Michael Jung To: freebsd-current@freebsd.org Subject: r320358 panics immediately on boot / AMD64-GENERIC kernel In-Reply-To: <939f19bd428b232515463436995da4b7@mikej.com> References: <4edb3e720c071385f8a6555c89116530@mikej.com> <939f19bd428b232515463436995da4b7@mikej.com> Message-ID: <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.2.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 16:10:02 -0000 Screen image with backtrace https://pasteboard.co/dZRVG5Uo.jpg After upgrading from 318959 to 320358 I immediately get the attached panic. This is AMD64 / GENERIC kernel. /boot/loader.conf is empty. The system boots off a UFS2 partition. This is a virtual guest and I do currently have a serial cable. Short of figuring out how to virtualize a serial console from a ESXi guest is there any more information I can provide? Thanks. Mike From owner-freebsd-current@freebsd.org Tue Jun 27 16:16:51 2017 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 E7A16D8991F for ; Tue, 27 Jun 2017 16:16:51 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id CC2FB71632 for ; Tue, 27 Jun 2017 16:16:51 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id BB9295646B; Tue, 27 Jun 2017 11:16:50 -0500 (CDT) Subject: Re: r320358 panics immediately on boot / AMD64-GENERIC kernel To: Michael Jung , freebsd-current@freebsd.org References: <4edb3e720c071385f8a6555c89116530@mikej.com> <939f19bd428b232515463436995da4b7@mikej.com> <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> From: Eric van Gyzen Message-ID: <728a734d-6d3e-4b29-2e7a-cfe5877eedff@vangyzen.net> Date: Tue, 27 Jun 2017 11:16:47 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 16:16:52 -0000 On 06/27/2017 11:09, Michael Jung wrote: > Screen image with backtrace > > https://pasteboard.co/dZRVG5Uo.jpg > > > After upgrading from 318959 to 320358 I immediately get the attached panic. > > This is AMD64 / GENERIC kernel. > > /boot/loader.conf is empty. > > The system boots off a UFS2 partition. > > This is a virtual guest and I do currently have a serial cable. > > Short of figuring out how to virtualize a serial console from a ESXi > guest is > there any more information I can provide? Someone else hit this. Removing the contents of /usr/obj and rebuilding fixed it for him. Apparently, some of the objects didn't get rebuilt, as needed. Eric From owner-freebsd-current@freebsd.org Tue Jun 27 16:16:58 2017 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 DB1A7D89934 for ; Tue, 27 Jun 2017 16:16:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 6762D716C0 for ; Tue, 27 Jun 2017 16:16:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5RGGpGw008673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Jun 2017 19:16:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5RGGpGw008673 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5RGGpW2008672; Tue, 27 Jun 2017 19:16:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Jun 2017 19:16:51 +0300 From: Konstantin Belousov To: Michael Jung Cc: freebsd-current@freebsd.org Subject: Re: r320358 panics immediately on boot / AMD64-GENERIC kernel Message-ID: <20170627161651.GG3437@kib.kiev.ua> References: <4edb3e720c071385f8a6555c89116530@mikej.com> <939f19bd428b232515463436995da4b7@mikej.com> <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 27 Jun 2017 16:16:59 -0000 On Tue, Jun 27, 2017 at 12:09:56PM -0400, Michael Jung wrote: > Screen image with backtrace > > https://pasteboard.co/dZRVG5Uo.jpg > > > After upgrading from 318959 to 320358 I immediately get the attached > panic. > > This is AMD64 / GENERIC kernel. > > /boot/loader.conf is empty. > > The system boots off a UFS2 partition. > > This is a virtual guest and I do currently have a serial cable. > > Short of figuring out how to virtualize a serial console from a ESXi > guest is > there any more information I can provide? Rebuild the kernel after removing the kernel build directory. From owner-freebsd-current@freebsd.org Tue Jun 27 16:19:38 2017 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 7AB03D89B44 for ; Tue, 27 Jun 2017 16:19:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 2A67E7233F for ; Tue, 27 Jun 2017 16:19:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v5RGJa4t029566; Tue, 27 Jun 2017 16:19:36 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5RGJZPx029565; Tue, 27 Jun 2017 09:19:35 -0700 (PDT) (envelope-from david) Date: Tue, 27 Jun 2017 09:19:35 -0700 From: David Wolfskill To: Michael Jung Cc: freebsd-current@freebsd.org Subject: Re: r320358 panics immediately on boot / AMD64-GENERIC kernel Message-ID: <20170627161935.GP1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Michael Jung , freebsd-current@freebsd.org References: <4edb3e720c071385f8a6555c89116530@mikej.com> <939f19bd428b232515463436995da4b7@mikej.com> <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+/lp9f/wU8jZ28Xb" Content-Disposition: inline In-Reply-To: <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 16:19:38 -0000 --+/lp9f/wU8jZ28Xb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 12:09:56PM -0400, Michael Jung wrote: > Screen image with backtrace >=20 > https://pasteboard.co/dZRVG5Uo.jpg >=20 >=20 > After upgrading from 318959 to 320358 I immediately get the attached=20 > panic. >=20 > This is AMD64 / GENERIC kernel. >=20 > /boot/loader.conf is empty. >=20 > The system boots off a UFS2 partition. > .... If the object directory for your kernel (e.g., /usr/obj/usr/src/sys/GENERIC) had more in it than the "version" file, you might try removing everything in that directory, then rebuilding the kernel. (Ref. the thread that starts at http://docs.FreeBSD.org/cgi/mid.cgi?20170625120731.GE1241 .) Peace, david --=20 David H. Wolfskill david@catwhisker.org I look forward to voting against Trump again at the earliest opportunity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+/lp9f/wU8jZ28Xb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZUoWXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XdpsH/isasQqYQrMpfnpsuf6pBZLe yYD1lD5F9Eb08r6/FDdTvwrpgcI9H+tz4Y1Q+MI8LTv9C/QTGC2uRCoZxuHSkU2w V7nrBCh7XmQjM9dPh7OSTIlC+jsIda7G7a33S9G+RH+yun9SkgliyLjNCCMYo9Bt HFlz11cntdFF/8owQ8rWt1fJZkm3Y0U1/lL+BS+7MPEOF3gRPpPNf9w6V/Nq/8f2 LgNyVh/9h/JvgJWsuiKnn7FlyoqVtOEeT1gvshqsWccKMcVM2ZgeZ0Cz1ujvZ3u6 bXnaO9ijOjkHIwok8aCp9cntQKi4LOYF66eRnLRVjGJfTaI2cu8S/tzn14/W+uA= =HcjW -----END PGP SIGNATURE----- --+/lp9f/wU8jZ28Xb-- From owner-freebsd-current@freebsd.org Tue Jun 27 15:19:38 2017 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 40D5FD87D41 for ; Tue, 27 Jun 2017 15:19:38 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82DD76E4FF for ; Tue, 27 Jun 2017 15:19:36 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.2/8.15.2) with ESMTPS id v5RF1t4W004492 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 27 Jun 2017 11:01:56 -0400 (EDT) (envelope-from mikej@mikej.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 mx2.paymentallianceintl.com v5RF1t4W004492 Authentication-Results: mx2.paymentallianceintl.com; sender-id=pass header.from=mikej@mikej.com; spf=pass smtp.mfrom=mikej@mikej.com X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id v5RF1rol013057 for ; Tue, 27 Jun 2017 11:01:54 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com v5RF1rol013057 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com v5RF1rol013057 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1498575714; bh=mC6SHjvpGOLUuYoORAgLtFCmh16InPcVdH7g6TlJgcs=; h=Date:From:To:Subject:In-Reply-To:References; b=nj1LPfBk1sED8Z3EnYWL9Wbs7BX4DWJG/zsi7BPtWhnaXWR9/vVR6yfLm1a+Cwr0d w7RLl8reVNHMIHlTXndXAI/0upS4/zlj/C8iJNDE/SP6Q5NFuMLmpWUypzw/yvbdAi iVZ5r0rDBFFdt1V95RrU2dE/PFrdTSyaAbbb+mc7/hVc3E6Ccwsa7WuOc7Fj93s7QP 7ZXu24w0e1W1hVRes24ja3V8+QjqUJM4BNQnUaLacpi1qZyjlJZdtJeyen3RhMmmt+ nLwMuF55kBujA/LqOHc8I9js/iFEABLvRqwEK16VGejIDU45Zv3A0/YAvTsVxGQdgc 7rNCRG+gzldAg== X-Authentication-Warning: firewall.mikej.com: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Date: Tue, 27 Jun 2017 11:01:53 -0400 From: Michael Jung To: freebsd-current@freebsd.org Subject: r320358 panics immediately on boot / AMD64-GENERIC kernel In-Reply-To: <4edb3e720c071385f8a6555c89116530@mikej.com> References: <4edb3e720c071385f8a6555c89116530@mikej.com> Message-ID: <939f19bd428b232515463436995da4b7@mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.2.5 X-Mailman-Approved-At: Tue, 27 Jun 2017 16:26:48 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 15:19:38 -0000 After upgrading from 318959 to 320358 I immediately get the attached panic. This is AMD64 / GENERIC kernel. /boot/loader.conf is empty. The system boots off a UFS2 partition. This is a virtual guest and I do currently have a serial cable. Short of figuring out how to virtualize a serial console from a ESXi guest is there any more information I can provide? Thanks. Mike From owner-freebsd-current@freebsd.org Tue Jun 27 17:06:57 2017 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 95F8ED8B198 for ; Tue, 27 Jun 2017 17:06:57 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 284087489A for ; Tue, 27 Jun 2017 17:06:56 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5RH6ju1077025 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Jun 2017 19:06:45 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5RH6iEg077022 for ; Tue, 27 Jun 2017 19:06:45 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 27 Jun 2017 19:06:44 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory Message-ID: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 17:06:57 -0000 Try running make installworld without -j N. Serial installworld was successful at my end. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Tue Jun 27 17:33:50 2017 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 38DA9D8BD9E for ; Tue, 27 Jun 2017 17:33:50 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D726275D6B for ; Tue, 27 Jun 2017 17:33:49 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.2/8.15.2) with ESMTPS id v5RHXlNt015680 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 27 Jun 2017 13:33:47 -0400 (EDT) (envelope-from mikej@mikej.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 mx2.paymentallianceintl.com v5RHXlNt015680 Authentication-Results: mx2.paymentallianceintl.com; sender-id=pass header.from=mikej@mikej.com; spf=pass smtp.mfrom=mikej@mikej.com X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id v5RHXjOf016773; Tue, 27 Jun 2017 13:33:45 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com v5RHXjOf016773 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com v5RHXjOf016773 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1498584826; bh=ksduuTlaGZKmsOEpT74ZkfURxx8Svb7NFmraBzy9zSM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Z0m54NvCC+bBjl9LtJeBG+r904xwjcMHdkyIkfOT313bxZqTdtm+iLU2L0AWslxZE xOf7ckItRqnF+mKViFD/8L8hhflK+7AN4GNUX3/YQCTtOcm7ihzfsj/s24i2Sz08bY Miq452nrbnvAt6EbdIAZG/IfFpuKlxp5BDgMj2BebS1hD8G/jgXqWdNsft4WdY/dUM jdU3UlUUaFP5rfb+HapeNc1/jAttPouXFCbG0Uj/UIKHA74JQoLT3H7hnNkfZt4jTu sFqQdwI19YX3XOkVZueaH8YnuaUtf5wpCu4WywFkpUg77TJCh0A5R5oOH1MEIsUsCm K7IKEX2ioXbdQ== X-Authentication-Warning: firewall.mikej.com: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 Jun 2017 13:33:44 -0400 From: Michael Jung To: Eric van Gyzen Cc: freebsd-current@freebsd.org Subject: Re: r320358 panics immediately on boot / AMD64-GENERIC kernel In-Reply-To: <728a734d-6d3e-4b29-2e7a-cfe5877eedff@vangyzen.net> References: <4edb3e720c071385f8a6555c89116530@mikej.com> <939f19bd428b232515463436995da4b7@mikej.com> <78b111f8c0c26a08d204d1ba16c55df1@mikej.com> <728a734d-6d3e-4b29-2e7a-cfe5877eedff@vangyzen.net> Message-ID: <320ad3f0f86f8e59b77d590b27ab58f6@mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.2.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 17:33:50 -0000 On 2017-06-27 12:16, Eric van Gyzen wrote: > On 06/27/2017 11:09, Michael Jung wrote: >> Screen image with backtrace >> >> https://pasteboard.co/dZRVG5Uo.jpg >> >> >> After upgrading from 318959 to 320358 I immediately get the attached >> panic. >> >> This is AMD64 / GENERIC kernel. >> >> /boot/loader.conf is empty. >> >> The system boots off a UFS2 partition. >> >> This is a virtual guest and I do currently have a serial cable. >> >> Short of figuring out how to virtualize a serial console from a ESXi >> guest is >> there any more information I can provide? > > Someone else hit this. Removing the contents of /usr/obj and > rebuilding > fixed it for him. Apparently, some of the objects didn't get rebuilt, > as needed. > > Eric Thank to all that replied. Indeed removing the contents of /usr/obj and rebuilding the kernel resolved the issue. Thanks! --mikej From owner-freebsd-current@freebsd.org Tue Jun 27 18:28:46 2017 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 92A75D8D48A for ; Tue, 27 Jun 2017 18:28:46 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward3o.cmail.yandex.net (forward3o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::288]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C9F778101 for ; Tue, 27 Jun 2017 18:28:46 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp4p.mail.yandex.net (smtp4p.mail.yandex.net [IPv6:2a02:6b8:0:1402::15:6]) by forward3o.cmail.yandex.net (Yandex) with ESMTP id 1F2BA2129A for ; Tue, 27 Jun 2017 21:28:35 +0300 (MSK) Received: from smtp4p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp4p.mail.yandex.net (Yandex) with ESMTP id F1ECD6501150 for ; Tue, 27 Jun 2017 21:28:34 +0300 (MSK) Received: by smtp4p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id lDCFo61LiH-SXcSmNg7; Tue, 27 Jun 2017 21:28:33 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1498588113; bh=vqVY1+sx1Ym4lNFPeRDQR2o234KHXJUprWzS55qktC4=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=FNXdsyqyy9+OJtDyRuSo0wK5sgolvZJ0bR6Ipuv+hMfw1v4bUDSgkqsk48wkFcjgI zM4wb8aU9sA0xV3sbK5F1oaliQPDsBBNmBH2NiIBA3hUw+3LSaGCFsc+M4Diptbu5a 8eMN+Ol3fnGdeT8J75hjAsrAYt/HOSlgFkZFz6ng= Authentication-Results: smtp4p.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0 Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory To: freebsd-current@freebsd.org References: From: Boris Samorodov Message-ID: <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru> Date: Tue, 27 Jun 2017 21:28:33 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 18:28:46 -0000 27.06.2017 20:06, Trond Endrestøl пишет: > Try running make installworld without -j N. > Serial installworld was successful at my end. Thank you, that helped. -- WBR, bsam From owner-freebsd-current@freebsd.org Tue Jun 27 18:28:59 2017 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 CCAC6D8D4B5 for ; Tue, 27 Jun 2017 18:28:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B421781C1 for ; Tue, 27 Jun 2017 18:28:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5RISof1077418 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Jun 2017 20:28:51 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5RISoGt077415 for ; Tue, 27 Jun 2017 20:28:50 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 27 Jun 2017 20:28:50 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: <20170625190544.GH3437@kib.kiev.ua> Message-ID: References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170625190544.GH3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 18:28:59 -0000 On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > This patch made ruby23 happy on my end. Can't say the same for > > emacs-nox11 or temacs while building the former. > > What exactly do you mean ? Explain the behaviour and show the ktrace log. It builds now. I'm running unpatched r320406, and I'll attempt building and running r320420 with your patch from yesterday. I too suffer from /sbin/zfs's inability to run in singleuser mode, yet somehow it does its job while in multiuser mode. -- Trond. From owner-freebsd-current@freebsd.org Tue Jun 27 18:56:45 2017 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 29A24D8DDC2 for ; Tue, 27 Jun 2017 18:56:45 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B85679046 for ; Tue, 27 Jun 2017 18:56:44 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v5RIua60077577 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Jun 2017 20:56:36 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v5RIuaiF077574 for ; Tue, 27 Jun 2017 20:56:36 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 27 Jun 2017 20:56:36 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 In-Reply-To: Message-ID: References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170625190544.GH3437@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 18:56:45 -0000 On Tue, 27 Jun 2017 20:28+0200, Trond Endrestl wrote: > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > > This patch made ruby23 happy on my end. Can't say the same for > > > emacs-nox11 or temacs while building the former. > > > > What exactly do you mean ? Explain the behaviour and show the ktrace log. > > It builds now. > > I'm running unpatched r320406, and I'll attempt building and running > r320420 with your patch from yesterday. > > I too suffer from /sbin/zfs' inability to run in singleuser mode, yet > somehow it does its job while in multiuser mode. That patch enables /sbin/zfs to run in singleuser mode. Next, there seems to be a race condition while running installworld in parallel, but that's a story for another time. -- Trond. From owner-freebsd-current@freebsd.org Tue Jun 27 19:58:06 2017 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 B048CD8EFBC for ; Tue, 27 Jun 2017 19:58:06 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8535F7AD5F for ; Tue, 27 Jun 2017 19:58:06 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id PwcddcxMVETFpPwcedgFEe; Tue, 27 Jun 2017 13:58:05 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=8nJEP1OIZ-IA:10 a=LWSFodeU3zMA:10 a=21NAlnQ-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=x1YCqE8laNQiRfgq_5UA:9 a=wPNLvfGTeEIA:10 a=y82nBF0NtXRWrrZL_lSQ:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 7A0EEBF; Tue, 27 Jun 2017 12:58:03 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5RJujqP065871; Tue, 27 Jun 2017 12:56:45 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706271956.v5RJujqP065871@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Boris Samorodov cc: freebsd-current@freebsd.org Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory In-Reply-To: Message from Boris Samorodov of "Tue, 27 Jun 2017 21:28:33 +0300." <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 27 Jun 2017 12:56:45 -0700 X-CMAE-Envelope: MS4wfLwaJ9YfxXtC0sLcR8C/A47b5hxwaXwQfbCsfNTncz8QHDiSwX1ld2qou5GJ9N3kMoh/w+2Ray84HUe28z50SFBx8dD+5od/sSrVQKo1CeBybwxnFR5+ zhR8ep/9scwuRDGhob0oTsvx6TMSe4BIFXnJaEnIcpU0KgPCWBb0JM3QCmypkRvE7CWBn84OHtULKFRpGDH5vyhM9CJK3rs/+hY= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 19:58:06 -0000 In message <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru>, Boris Samorodov wr ites: > 27.06.2017 20:06, Trond Endrestøl пишет: > > > Try running make installworld without -j N. > > Serial installworld was successful at my end. > > Thank you, that helped. For users doing poudriere jail -c or poudriere jail -u, use -J 1, though poudriere should only perform parallel builds only, not parallel installs. Parallel installs is simply asking for trouble regardless. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Jun 27 20:16:15 2017 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 5D985D8F5F1 for ; Tue, 27 Jun 2017 20:16:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AFD747B7B7; Tue, 27 Jun 2017 20:16:14 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id Pwu5dd3HpETFpPwu6dgJlV; Tue, 27 Jun 2017 14:16:08 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=8nJEP1OIZ-IA:10 a=LWSFodeU3zMA:10 a=VxmjJ2MpAAAA:8 a=21NAlnQ-AAAA:8 a=bhHEUyJqAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=a4hU-AsW7-tu6m66c58A:9 a=wPNLvfGTeEIA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=y82nBF0NtXRWrrZL_lSQ:22 a=crJotJrOxJ47qoN_eMsF:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id F3376D3; Tue, 27 Jun 2017 13:16:04 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5RKEj8L042071; Tue, 27 Jun 2017 13:14:45 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706272014.v5RKEj8L042071@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Boris Samorodov , freebsd-current@freebsd.org, bdrewery@freebsd.org, bapt@freebsd.org Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory In-Reply-To: Message from Cy Schubert of "Tue, 27 Jun 2017 12:56:45 -0700." <201706271956.v5RJujqP065871@slippy.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 27 Jun 2017 13:14:45 -0700 X-CMAE-Envelope: MS4wfMbfqWhABYvm+RRdDZBY3V1tHO2suQTS0ZWJHhFnRtdMPFCpjuBWvo1o1s+/Yz7wxpyKFbMxIwoNgkPHsO2+NzA4LGDOZZk3Gq2VQn5H7KvXYiaASJFi meL5PmP/0c4v62UzIMjA3ygXDtmpnPTVWwyij6YeQIlAuStuA3ImJFWdePZKAS8xbKcEQSYhyRu1IqeSGfK3WqBKRFlfjYN7r8MUj87OUysacLbQSDOKlOpm scdckS7G8o+z+lHSNF9r/+4772KfZcDVW0YFUCjirC4= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 20:16:15 -0000 In message <201706271956.v5RJujqP065871@slippy.cwsent.com>, Cy Schubert writes: > In message <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru>, Boris > Samorodov wr > ites: > > 27.06.2017 20:06, Trond Endrestøl пишет: > > > > > Try running make installworld without -j N. > > > Serial installworld was successful at my end. > > > > Thank you, that helped. > > For users doing poudriere jail -c or poudriere jail -u, use -J 1, though > poudriere should only perform parallel builds only, not parallel installs. > Parallel installs is simply asking for trouble regardless. The patch I'm about to post here isn't quite correct. Either base or the port's upstream should be patched to resolve this but this should help someone somewhere. Index: Makefile =================================================================== --- Makefile (revision 444518) +++ Makefile (working copy) @@ -2,7 +2,7 @@ PORTNAME= poudriere DISTVERSION= 3.1.19 -PORTREVISION= 0 +PORTREVISION= 1 CATEGORIES= ports-mgmt MASTER_SITES= LOCAL/bdrewery/${PORTNAME}/ \ http://mirror.shatow.net/freebsd/${PORTNAME}/ \ Index: files/patch-src__share__poudriere__jail.sh =================================================================== --- files/patch-src__share__poudriere__jail.sh (nonexistent) +++ files/patch-src__share__poudriere__jail.sh (working copy) @@ -0,0 +1,27 @@ +--- src/share/poudriere/jail.sh.orig 2017-06-01 10:21:58.000000000 -0700 ++++ src/share/poudriere/jail.sh 2017-06-27 13:06:20.548694000 -0700 +@@ -272,21 +272,16 @@ + } + + installworld() { +- local make_jobs + local destdir="${JAILMNT}" + +- if [ ${JAIL_OSVERSION} -gt 1100086 ]; then +- make_jobs="${MAKE_JOBS}" +- fi +- + msg "Starting make installworld" +- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} installworld \ ++ ${MAKE_CMD} -C "${SRC_BASE}" installworld \ + DESTDIR=${destdir} DB_FROM_SRC=1 || \ + err 1 "Failed to 'make installworld'" +- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} DESTDIR=${destdir} \ ++ ${MAKE_CMD} -C "${SRC_BASE}" DESTDIR=${destdir} \ + DB_FROM_SRC=1 distrib-dirs || \ + err 1 "Failed to 'make distrib-dirs'" +- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} DESTDIR=${destdir} \ ++ ${MAKE_CMD} -C "${SRC_BASE}" DESTDIR=${destdir} \ + distribution || err 1 "Failed to 'make distribution'" + + return 0 -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Jun 27 20:18:26 2017 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 1BB10D8F7C3 for ; Tue, 27 Jun 2017 20:18:26 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 92D3D7B97C for ; Tue, 27 Jun 2017 20:18:25 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id b207so23674095lfg.2 for ; Tue, 27 Jun 2017 13:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=vuah/RrhVIIlLCgd/5lUFa68kai1Jj6SaoxvWqH2Yxo=; b=oumfndk2gNDd6ZRx/AlPRmm75jYsN1Ia7pypbZOvoIWP9ZkrsYjIOaP88aWgIlb0Zl 1kVomM6EnXFCROXe/CdeofMIKq5aBXsh/KmE28cmsUZ261KDhjUbwI7vfjTARyDc0CyB lxNEuiV/XN9AT4PGCZl4tsTScOyOBA4DyTHYoLqMlgrevWyMIBKkjrMnX6yUqlfDnS2w 9P2biQidIWKnu20+1OUz3/RfEumT0Dnrfg0OpncLQSPdeN2zv91jMsumEx65G5teenEx mECy7JZ/l9MCpeeqUW6erPiYQxbdadPIPw098GGzGzPfn6pqmEe+56iDr2d45PZXFfwo yNmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=vuah/RrhVIIlLCgd/5lUFa68kai1Jj6SaoxvWqH2Yxo=; b=pJOHMhs4GBTB8gNhdErxlUeg7nSXbXT/x30z/Tq0dTbHwdUwOwlCkj4BMZKtzQzvfd g0qkoHezS5clt2XDORlK5RkQZUe+9Lh017URWVH8OCGc7jSUPSeTynTLM+KWN9iNgQN5 WjW0oFLqOJ7vA/CmPhD7mzbiRr0tZF1KybUN5j/7+NTJI1ekKjOesO9F3rY8MZvbGOz9 z0+Ch4Mfpns1bXSsR++Gw08h6ZUNu0JAvuqODLRrW0g0S7vNhEBJUnmQjeQLaew/8EOq eguiAwABjTxK0BYuw99/wSaI6LarveOlgxI/JjF/49VZfCpuRtgHYKOjVYwLaU9wegEf hz+g== X-Gm-Message-State: AKS2vOxP7XKeEnHEtiMb82bcC6eDod6/agW8vEhDtw5Q/7aNn0Uv4h68 n2oQ7Vg1MzULzgkEIGDic5Sdc1EKeA== X-Received: by 10.25.92.18 with SMTP id q18mr2033569lfb.13.1498594703505; Tue, 27 Jun 2017 13:18:23 -0700 (PDT) MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 10.25.115.88 with HTTP; Tue, 27 Jun 2017 13:18:22 -0700 (PDT) In-Reply-To: <201706271956.v5RJujqP065871@slippy.cwsent.com> References: <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru> <201706271956.v5RJujqP065871@slippy.cwsent.com> From: Antoine Brodin Date: Tue, 27 Jun 2017 22:18:22 +0200 X-Google-Sender-Auth: c3CWUPIVgv-KIO-ioFU-tAX8jVg Message-ID: Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory To: Cy Schubert Cc: Boris Samorodov , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 20:18:26 -0000 On Tue, Jun 27, 2017 at 9:56 PM, Cy Schubert wro= te: > In message <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru>, Boris > Samorodov wr > ites: >> 27.06.2017 20:06, Trond Endrest=C3=83=C2=B8l =C3=90=C2=BF=C3=90=C2=B8=C3= =91=CB=86=C3=90=C2=B5=C3=91=E2=80=9A: >> >> > Try running make installworld without -j N. >> > Serial installworld was successful at my end. >> >> Thank you, that helped. > > For users doing poudriere jail -c or poudriere jail -u, use -J 1, though > poudriere should only perform parallel builds only, not parallel installs= . > Parallel installs is simply asking for trouble regardless. Are you serious? poudriere has installed in parallel since forever and it's the first time there is an issue. Antoine From owner-freebsd-current@freebsd.org Tue Jun 27 22:57:01 2017 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 F0669D91FCB for ; Tue, 27 Jun 2017 22:57:01 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA51C80329 for ; Tue, 27 Jun 2017 22:57:00 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.eecs.uottawa.ca (localhost [127.0.0.1]) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id v5RMeEZL097575 for ; Tue, 27 Jun 2017 18:40:14 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Received: from 137.122.24.159 (SquirrelMail authenticated user kwhite) by courriel.site.uottawa.ca with HTTP; Tue, 27 Jun 2017 18:40:14 -0400 (EDT) Message-ID: <4799.137.122.24.159.1498603214.squirrel@courriel.site.uottawa.ca> Date: Tue, 27 Jun 2017 18:40:14 -0400 (EDT) Subject: Lost HDMI output on Dell XPS M1330 From: kwhite@site.uottawa.ca To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 22:57:02 -0000 Some time since 10.3, I am no longer able to select HDMI output using xrandr, just VGA. Hints on how to get it back? Noise follows: == 10.3 == # uname -ap FreeBSD m1330 10.3-RELEASE-p18 FreeBSD 10.3-RELEASE-p18 #0: Tue Apr 11 10:31:00 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 amd64 # kenv smbios.system.product XPS M1330 # xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192 LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 290mm x 180mm 1280x800 60.04*+ 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) # dmesg -a | egrep -i 'vga|drm' vgapci0: port 0xeff8-0xefff mem 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Boot video device vgapci1: mem 0xf6f00000-0xf6ffffff at device 2.1 on pci0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] initialized overlay support info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector HDMI-A-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.HDMI-A-1 info: [drm] - kern.vt.fb.default_mode fbd0 on drmn0 info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 == "Current" == # uname -ap FreeBSD lenovo 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r319078M: Sun May 28 20:22:51 EDT 2017 root@lenovo:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 amd64 # kenv smbios.system.product XPS M1330 # xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192 LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 290mm x 180mm 1280x800 60.04*+ 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) # dmesg -a | egrep -i 'vga|drm' VT(vga): resolution 640x480 info: [drm] Initialized drm 1.1.0 20060810 vtvga0: on motherboard vgapci0: port 0xeff8-0xefff mem 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 acpi_video0: on vgapci0 drmn0: on vgapci0 intel_iicbb0 on drmn0 intel_iicbb1 on drmn0 intel_iicbb2 on drmn0 intel_iicbb3 on drmn0 intel_iicbb4 on drmn0 intel_iicbb5 on drmn0 info: [drm] MSI enabled 1 message(s) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. intel_sdvo_ddc_proxy397632 on drmn0 intel_sdvo_ddc_proxy397664 on drmn0 drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] initialized overlay support info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 vgapci0: Boot video device vgapci1: mem 0xf6f00000-0xf6ffffff at device 2.1 on pci0 acpi_video1: on vgapci1 ...keith From owner-freebsd-current@freebsd.org Tue Jun 27 23:45:32 2017 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 4EE9ED92C24 for ; Tue, 27 Jun 2017 23:45:32 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 045F481BE9 for ; Tue, 27 Jun 2017 23:45:32 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x231.google.com with SMTP id i2so37587273qta.3 for ; Tue, 27 Jun 2017 16:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0tJWXXxdPwA0IZu2feA3NIWwNv/VGl1GopwH2QoCH48=; b=O3Vx6DZ3Cz3V/IYlKXDXclP/iWeJFdAZBF1sBbcLQplPTDZQEZTRmiV+YMUSHaZzSU 9Fxlw/XS7SHPz/6D+3V3Ch2MJC+c3j65oQcW/oD6z9apzQ2DiRDoerBBu2abMxGYa7nH DzuSJ6uN5FXgYd/aWfoHnTGaUYDGA0+tzHkx8aPc8FTCfGKmhEud5ss6MfAYY5tflAGW tKkmS6pJHk+n2tUNgEsvf49pNj+zxr/ZjIq4UcyzqzcTu34jl4As1L9CHAca1NhB2jUN VvOPGFJJFV6NBp/z3t41tTiYhesfjjB6+gI+2x52U/rbVWRV2xC06jwqHsHJNSb39KWJ zNJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0tJWXXxdPwA0IZu2feA3NIWwNv/VGl1GopwH2QoCH48=; b=RltrXHBYELUCJlSYjH/3rG4z4S9MK2NHNnzYjgEvaVrmavXbNG0U/BhcCocDC5P9sP uZMvc/aVjVn3mxtD1WCMia5eSKY5X+hsZDSHeQ8useb3caAscl+CCgEqYQUicat9Ai2+ DWnE+koUsFZ+CtQOq71jSqBnavb9gtghb3AF/hFApI/MNNiGhZgNj0/7S7Wx9Q8mH/J7 gakH3xaFhT83+Eu4E9cHEwQU9a81UT+fOgpzuN8XnxIH9fp4iR41c2JpTV0rxrSujsPD idWLhuiSLg8b27cqhre3mykKNeFvmiMonoiCv8IeTOfcKsQBNXGgim+Fnof2evYVTI2e vuMA== X-Gm-Message-State: AKS2vOz/wiaWVyGfx585vQkxn827Lsc3fQNVp5HJ5RCeDEPUg9hVR63E 33YEdDo4kgIk9AXouQJKGw== X-Received: by 10.200.2.139 with SMTP id p11mr7255333qtg.34.1498607131185; Tue, 27 Jun 2017 16:45:31 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id v131sm472355qka.56.2017.06.27.16.45.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Jun 2017 16:45:30 -0700 (PDT) Date: Tue, 27 Jun 2017 19:45:29 -0400 From: Shawn Webb To: Andriy Gapon Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS ABD Panic Message-ID: <20170627234529.7jioako7qsmdvdvm@mutt-hbsd> References: <20170626003129.ao72cszn7eeccyhp@mutt-hbsd> <61824b1e-9582-b50f-a55d-5ef4731383d0@FreeBSD.org> <20170627141621.eflvmf53goy45dzh@mutt-hbsd> <8798c2ee-fedf-0641-ffe5-9533d78bc6a2@FreeBSD.org> <20170627142516.wuveh44jomoagnng@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ifdxnzw5trumtv3h" Content-Disposition: inline In-Reply-To: <20170627142516.wuveh44jomoagnng@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 27 Jun 2017 23:45:32 -0000 --ifdxnzw5trumtv3h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 10:25:16AM -0400, Shawn Webb wrote: > On Tue, Jun 27, 2017 at 05:22:39PM +0300, Andriy Gapon wrote: > > On 27/06/2017 17:16, Shawn Webb wrote: > > > On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > > >> On 26/06/2017 03:31, Shawn Webb wrote: > > >>> This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > >>> > > >>> [141] panic: sleepq_add: td 0xfffff80008d20560 to sleep on wchan 0x= fffff803b7d4e810 with sleeping prohibited > > >>> [141] cpuid =3D 5 > > >>> [141] time =3D 1498436043 > > >>> [141] KDB: stack backtrace: > > >>> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0= xfffffe00002fc8b0 > > >>> [141] vpanic() at vpanic+0x19c/frame 0xfffffe00002fc930 > > >>> [141] kassert_panic() at kassert_panic+0x126/frame 0xfffffe00002fc9= a0 > > >>> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00002fc9f0 > > >>> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfffffe00002f= caa0 > > >>> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfffffe00002fcae0 > > >>> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xf= ffffe00002fcb20 > > >>> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfffffe00002fc= b50 > > >>> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfffffe= 00002fcb70 > > >>> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfffffe000= 02fcba0 > > >>> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfffffe00002fcbb0 > > >>> [141] fork_exit() at fork_exit+0x84/frame 0xfffffe00002fcbf0 > > >>> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002f= cbf0 > > >> > > >> Seems like another architectural incompatibility between illumos and= FreeBSD. > > >> Are you able to reproduce the crash more or less reliably? > > >=20 > > > Yup. I just need to do a buildworld and it's triggered. > > >=20 > >=20 > > Could you please test this patch? > > http://dpaste.com/12M183A.txt > > I put it together rather quickly, but I think that it should work :) >=20 > Can do later today. I'll report back either tonight or tomorrow. That seems to have fixed it! No kernel panic as of yet. It has survived two world + kernel builds. Thanks a lot for the help! --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --ifdxnzw5trumtv3h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAllS7hcACgkQaoRlj1JF bu4P3BAAi0dXRpmBWZpQbN7TSnzhkqBIm+PyhIW2WE6Y8YdMSCU3BVz87d1C9ReF SLRsQnL0R3+6z1BN3LLFkbnZk+mA5MFDH4JxU2lhC+amvm6BAv/geHUTq31uRKg5 JpxhVPDYmEQRPk+w18/4BwfLSyDHIv0TOX+yroxdYWl9U5J28YN6z3/tBdT/45Zg 4PIAlpQ/Twdt7jm2e+8RTJWkgXXCquFw3oKH4uHx0tK3RyNCXDE2CISpGsC/anfw qKCFiM93aX5fdsXJS1WsrhuTcbvVXzlogODiIdJf4361h7lNzpOlLknjM9CwGO2P qhRviuzG7hPT1tppa084lpkz2IUvnrE4KQuHWts8NbqSXphrvv4ndtapK441Tvhk RV3HnGQQf68yE6oGzuyApHRls1v7RwkD8X9YskHe6TUkixPPfqS3Wzpw5osXYfu8 SMHdHIIbTS1UGqC+t2MUla+tRveJFzolK5AXLnbLlRxSP08afbq1UrSDdw0A0y1v kIIwiaWdQvmnTkfB0wd1DdVNzLrDXcYTawNc0QCmMEkalCm8QRKBXPBT+25C1CIV bpYqtRo/ymFNvhoz6UpjPzNyqhDX3tyhoWePCuCTwxiU0Dh7pQE+wvhjnQs5xUF0 mG2x/NwZEgUau/QeUC7Do6exRhk8Yy0wapp6u7hBfemGmXe8nkc= =nySq -----END PGP SIGNATURE----- --ifdxnzw5trumtv3h-- From owner-freebsd-current@freebsd.org Wed Jun 28 00:20:36 2017 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 708A8D93951 for ; Wed, 28 Jun 2017 00:20:36 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A11682B84; Wed, 28 Jun 2017 00:20:35 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id Q0icdeJCSETFpQ0iddh9qs; Tue, 27 Jun 2017 18:20:33 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=21NAlnQ-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=-OihV98E0kEjoqtrj70A:9 a=QEXdDO2ut3YA:10 a=oappaISLdyUA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=pxhY87DP9d2VeQe4joPk:22 a=y82nBF0NtXRWrrZL_lSQ:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 71B8520F; Tue, 27 Jun 2017 17:20:30 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5RKLtbW049771; Tue, 27 Jun 2017 13:21:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706272021.v5RKLtbW049771@slippy.cwsent.com> Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Antoine Brodin cc: Cy Schubert , Boris Samorodov , FreeBSD Current Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory In-Reply-To: Your message of "Tue, 27 Jun 2017 22:18:22 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <49769.1498594915.1@slippy> Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2017 13:21:55 -0700 X-CMAE-Envelope: MS4wfEivRSnazjNnIZf59sa6nZdU/PW7ghVoa605tNu4Sij0g8wLSh8scrGiu6Mw7TOHMxGMOcNb+U6l0g3fIgFs0PBe8Mwf5ZC7l217kAJ85I8m3vV3g13c pH2TA0guH5iPJBfgJ1F6NrffKOd7kSu+tsVhDjrXaGSQaalq2mG6p+cBYZtksujcWBOeozuFVvOhWXSQFc2uSLaKHzjDt89lodbwK0Ui5mIFACh7Vbjz6sr3 YrrbH61Kb9ZdV1k5EHp/Qg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 00:20:36 -0000 In message , Antoine Brodin writes: > On Tue, Jun 27, 2017 at 9:56 PM, Cy Schubert = wrote > : > > In message <83207990-cd7c-90ea-6893-c0b3b132134d@passap.ru>, Boris > > Samorodov wr > > ites: > >> 27.06.2017 20:06, Trond Endrest=C3=83=C2=B8l =C3=90=C2=BF=C3=90=C2=B8= =C3=91=CB=86=C3=90=C2=B5=C3=91=E2=80=9A: > >> > >> > Try running make installworld without -j N. > >> > Serial installworld was successful at my end. > >> > >> Thank you, that helped. > > > > For users doing poudriere jail -c or poudriere jail -u, use -J 1, thou= gh > > poudriere should only perform parallel builds only, not parallel insta= lls. > > Parallel installs is simply asking for trouble regardless. > = > Are you serious? poudriere has installed in parallel since forever > and it's the first time there is an issue. Yes. I've had issues with parallel installs breaking badly before this. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Wed Jun 28 00:44:45 2017 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 386FCD93FB7 for ; Wed, 28 Jun 2017 00:44:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 06EB4837F6; Wed, 28 Jun 2017 00:44:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x243.google.com with SMTP id d5so6741923pfe.1; Tue, 27 Jun 2017 17:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Um+Q+i/gZzAbtSrKnE1O3rweWjV+D8uZpdYLK4+UzIA=; b=uOzM/SSos63jWJB6VXFm40papOu6l/U5sRS00Wbj3lNOVfcgGtZZ8Ji0I9EWjLFUC3 wKZp+zJrBu77ziBrMmsigdqEag+K620fz74wadgjefukScbpgJQItcvAiSZGA3RnfJTH mUd3nRyiIsm6yC6xbZPXQw+YDNYwdR1vHv/N8fHqWrF5wXe9Xk3Trib/qtQ+8CCABjz2 00CsmTTWPIrTY6kZB+smBlrlJV0PAsh7TA8Ve85hFZOJmS9x+QycJ0JBdraA+3ms93GE k3C9nFgd0tltMvXpahAcmPZDcjT9W73XgnNTBNfo/b5/Y9iyD6GXBJmUK3XOYQI0vw8K vsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Um+Q+i/gZzAbtSrKnE1O3rweWjV+D8uZpdYLK4+UzIA=; b=AlQEKuaUZNbmQd4XN19sHOOQe7elmpbI305D2hj5afNyUJLF8xu5gIYMZxZop+6Own pB1n8MaZYtetfqiLFN+hTyodPHI7Bx4MAUFELy+ANvzPhkiUp51TxTWmZtX77u9EHdE1 +UZa7p60nsFn2SYBO4udGNCefNGQfZjyaQKflQs+oI/aYtu+G8asI9RMJsYeFEzhEMBl ePWFHEcW2R3BpmLQRRrOqZUBWNzf0xy68b+pseuOQI+aaZZgE271j/uj+yeYHg6d4gzZ BYXk4lV1R2bVwGAFX2CNxy1ZJPOY49dJqDK4jLYsD5PgTiOSun0Ldse+dt67jG19aiND Al8A== X-Gm-Message-State: AKS2vOw8kjvJ7RKK2yd5lG71hN/pF2S0h10L1rTbKnzT8f5hvuP+mHxi 1o95yXGF5EAX0fiN5yo= X-Received: by 10.98.218.20 with SMTP id c20mr8053944pfh.112.1498610684589; Tue, 27 Jun 2017 17:44:44 -0700 (PDT) Received: from ?IPv6:2607:fb90:835d:c5b0:a84f:362f:4f90:690f? ([2607:fb90:835d:c5b0:a84f:362f:4f90:690f]) by smtp.gmail.com with ESMTPSA id i5sm651442pgk.61.2017.06.27.17.44.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 17:44:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory From: Ngie Cooper X-Mailer: iPhone Mail (14F89) In-Reply-To: <201706272021.v5RKLtbW049771@slippy.cwsent.com> Date: Tue, 27 Jun 2017 17:44:29 -0700 Cc: Antoine Brodin , Boris Samorodov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <201706272021.v5RKLtbW049771@slippy.cwsent.com> To: Cy Schubert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 00:44:45 -0000 > On Jun 27, 2017, at 13:21, Cy Schubert wrote: ... > Yes. I've had issues with parallel installs breaking badly before this. Be that what it may be, papering the issue over via poudriere is the wrong a= pproach to fixing the problem imho. Bryan's out for a few more days on vacation.. I'll see if I can look into th= is while he's gone. Thanks! -Ngie= From owner-freebsd-current@freebsd.org Wed Jun 28 00:56:20 2017 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 D0E81D943AE for ; Wed, 28 Jun 2017 00:56:20 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F6C883F39; Wed, 28 Jun 2017 00:56:20 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id Q1HEdGR59yd2DQ1HFdwf0A; Tue, 27 Jun 2017 18:56:19 -0600 X-Authority-Analysis: v=2.2 cv=F5wnTupN c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=LWSFodeU3zMA:10 a=XldT38RWNwACPDQzwzUA:9 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=PgOOqOpfEoNaP8rYQUUA:9 a=CjuIK1q_8ugA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=WcqYV7MEc-6UHiXGb_MA:9 a=ics_IjAVWSmO8OVX31YA:9 a=BOg4e644cxQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=pxhY87DP9d2VeQe4joPk:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id D57B023D; Tue, 27 Jun 2017 17:56:15 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5S0svs3036980; Tue, 27 Jun 2017 17:54:57 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706280054.v5S0svs3036980@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ngie Cooper cc: Cy Schubert , Antoine Brodin , Boris Samorodov , FreeBSD Current Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory In-Reply-To: Your message of "Tue, 27 Jun 2017 17:44:29 -0700." Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1498611286_142500" Date: Tue, 27 Jun 2017 17:54:57 -0700 X-CMAE-Envelope: MS4wfPrIf/IZ+Ajv1PYTYtYjhpGfkMtKIuJyeEM6HMPyC9wSFm38Gl2V9gE6259O6RyHZzZm9l7c3Zj+AxO8qRsSLoyAr71pdPRlFNMxfCYoWqzsBv+Xd2Wy ECoO+pVmrngFMROmbs9VTl4i/+kmuS2OKBxI8fpH46pI5IwC6irEDfjAiHzau+fW5y4H2jQi85b9kPq2VTb1SDTg07iz6rAgYT2hTvknX674l6V1gOZIG5DB 0v7RXYF0vfUfCxSCsB1QTxBSvbKLr6uwyIuvqcEwdSU= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 00:56:20 -0000 This is a multipart MIME message. --==_Exmh_1498611286_142500 Content-Type: text/plain; charset=us-ascii In message , Ngie Cooper writes : > > > > On Jun 27, 2017, at 13:21, Cy Schubert wrote: > > ... > > > Yes. I've had issues with parallel installs breaking badly before this. > > Be that what it may be, papering the issue over via poudriere is the wrong ap > proach to fixing the problem imho. > > Bryan's out for a few more days on vacation.. I'll see if I can look into thi > s while he's gone. Sure. Here's previous reply that includes a patch that addresses this in base. Does this look correct to you? --==_Exmh_1498611286_142500 Content-Type: message/rfc822 ; name="6235" Content-Description: 6235 Content-Disposition: attachment; filename="6235" X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Sean Bruno cc: Edward Tomasz Napierala , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r320362 - head/share/zoneinfo In-Reply-To: Message from Sean Bruno of "Mon, 26 Jun 2017 12:21:15 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jun 2017 20:48:57 -0700 (since we're top posting.... ) Hi Sean, Do you want to give this a spin? Index: share/zoneinfo/Makefile =================================================================== --- share/zoneinfo/Makefile (revision 320389) +++ share/zoneinfo/Makefile (working copy) @@ -94,7 +94,7 @@ .for f in ${TZS} ${INSTALL} ${TAG_ARGS} \ -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ - ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f} ${DESTDIR}/usr/share/zoneinfo/${f} + ${TZBUILDDIR}/${f} ${DESTDIR}/usr/share/zoneinfo/${f} .endfor ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/ ~cy In message , Sean Bruno write s: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f > Content-Type: multipart/mixed; boundary="VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ"; > protected-headers="v1" > From: Sean Bruno > To: Edward Tomasz Napierala , src-committers@freebsd.org, > svn-src-all@freebsd.org, svn-src-head@freebsd.org > Message-ID: > Subject: Re: svn commit: r320362 - head/share/zoneinfo > References: <201706261540.v5QFeOTj072841@repo.freebsd.org> > In-Reply-To: <201706261540.v5QFeOTj072841@repo.freebsd.org> > > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > Hmmm ... This seems to break 'poudriere jail -c jailname -m src=3D/usr/sr= > c > -v head" > > --- realinstall_subdir_share/zoneinfo --- > install: builddir/Africa/Abidjan: No such file or directory > > > On 06/26/17 09:40, Edward Tomasz Napierala wrote: > > Author: trasz > > Date: Mon Jun 26 15:40:24 2017 > > New Revision: 320362 > > URL: https://svnweb.freebsd.org/changeset/base/320362 > >=20 > > Log: > > Provide visual feedback when timezone files are installed. > > After r320003 it wasn't being shown in any way. > > =20 > > Submitted by: bdrewery > > MFC after: 1 month > > Differential Revision: https://reviews.freebsd.org/D11154 > >=20 > > Modified: > > head/share/zoneinfo/Makefile > >=20 > > Modified: head/share/zoneinfo/Makefile > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D > > --- head/share/zoneinfo/Makefile Mon Jun 26 15:23:12 2017 (r32036 > 1) > > +++ head/share/zoneinfo/Makefile Mon Jun 26 15:40:24 2017 (r32036 > 2) > > @@ -83,14 +83,19 @@ zoneinfo: yearistype ${TDATA} > > zic -D -d ${TZBUILDDIR} -p ${POSIXRULES} -m ${NOBINMODE} \ > > ${LEAPFILE} -y ${.OBJDIR}/yearistype ${TZFILES} > > =20 > > +.if make(*install*) > > +TZS!=3D cd ${TZBUILDDIR} && find -s * -type f > > +.endif > > + > > beforeinstall: install-zoneinfo > > install-zoneinfo: > > mkdir -p ${DESTDIR}/usr/share/zoneinfo > > cd ${DESTDIR}/usr/share/zoneinfo; mkdir -p ${TZBUILDSUBDIRS} > > - cd ${TZBUILDDIR} && \ > > - find -s * -type f -exec ${INSTALL} ${TAG_ARGS} \ > > +.for f in ${TZS} > > + ${INSTALL} ${TAG_ARGS} \ > > -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > > - \{} ${DESTDIR}/usr/share/zoneinfo/\{} \; > > + ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f} ${DESTDIR}/usr/share/zoneinfo= > /${f} > > +.endfor > > ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > > ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/ > > =20 > >=20 > >=20 > > > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ-- > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > > iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAllRUJtfFIAAAAAALgAo > aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 > QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 > /LaIFggAlEX4pLTfDUaRsGoxWbGI0DiirmhR1nW74ESXjGXd4u9WSYKfvxK+oGPJ > LRwxcimGw/v+h8piM102ijsmquE0+NlyyMAYjFNLb9tsZuR+kfzRbDwqiu3FNg8R > zDnsvo69JHiyoi7r9BJB30Q6P9fZDGBtCrSQ9Up2IUiPHjz+pLUK6jxy29wflPSr > qVDHitG2A7l7Sdn3Jsj8MWNw/4ehRNlhxudgg+F8v7tEJH9eNBpP6K6jR6B+aU/P > VCPrKO1rRmmJTPxxPwskLLX4/xXrf8hmUFTm0uBbLtKbvzsaO5IZ9HKXJdYFlaRo > dCw6yY1xFlMv/OrUWgSxj02fsd7GHg== > =9Mia > -----END PGP SIGNATURE----- > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f-- > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. --==_Exmh_1498611286_142500 Content-Type: text/plain; charset=us-ascii Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. --==_Exmh_1498611286_142500-- From owner-freebsd-current@freebsd.org Wed Jun 28 01:20:40 2017 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 AE3E1D94C28 for ; Wed, 28 Jun 2017 01:20:40 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E3C9847E9; Wed, 28 Jun 2017 01:20:39 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id Q1endGYOlyd2DQ1eodwjai; Tue, 27 Jun 2017 19:20:38 -0600 X-Authority-Analysis: v=2.2 cv=F5wnTupN c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=LWSFodeU3zMA:10 a=VxmjJ2MpAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=8DB2cCh4wnP8QE5Ai1cA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=3G04NqJCuKgA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 538B3CD; Tue, 27 Jun 2017 18:20:37 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5S1JLUX080580; Tue, 27 Jun 2017 18:19:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.14.8/Submit) with ESMTP id v5S1JLjk080564; Tue, 27 Jun 2017 18:19:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706280119.v5S1JLjk080564@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Ngie Cooper , Cy Schubert , Antoine Brodin , Boris Samorodov , FreeBSD Current Subject: Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory In-Reply-To: Message from Cy Schubert of "Tue, 27 Jun 2017 17:54:57 -0700." <201706280054.v5S0svs3036980@slippy.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jun 2017 18:19:21 -0700 X-CMAE-Envelope: MS4wfAVdG87VIjyT0kXcooRbkOpNMflyL2+/OP1XWZiBI8vqghaojJj33LmbEmotR7dB66tA/fQkp1jhhKi2TCiTHA796gMdRfoCGITt7Uzlf0VLMsOTjhFS TB1HaCYNbyPFCrdgi9PH48i1pTVoI99dH1HQ+lFEFyIujA7NcEQVS2FENOSR9gEk0VZz2RfvrCi0JeMz1q5CLl4JSklKqs/KW1KEUh4PYGpRWCGH1fvY0sfw dPq4d23DmUNa5PuOreOkg1qNjxxwJq9BGLSpIfbmeEw= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 01:20:40 -0000 In message <201706280054.v5S0svs3036980@slippy.cwsent.com>, Cy Schubert writes: > This is a multipart MIME message. > > --==_Exmh_1498611286_142500 > Content-Type: text/plain; charset=us-ascii > > In message , Ngie Cooper > writes > : > > > > > > > On Jun 27, 2017, at 13:21, Cy Schubert wrote: > > > > ... > > > > > Yes. I've had issues with parallel installs breaking badly before this. > > > > Be that what it may be, papering the issue over via poudriere is the wrong > ap > > proach to fixing the problem imho. > > > > Bryan's out for a few more days on vacation.. I'll see if I can look into t > hi > > s while he's gone. > > Sure. > > Here's previous reply that includes a patch that addresses this in base. > Does this look correct to you? The poudriere hack doesn't work. The attached patch does. ~cy > > > > --==_Exmh_1498611286_142500 > Content-Type: message/rfc822 ; name="6235" > Content-Description: 6235 > Content-Disposition: attachment; filename="6235" > > X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 > Reply-to: Cy Schubert > From: Cy Schubert > X-os: FreeBSD > X-Sender: cy@cwsent.com > X-URL: http://www.cschubert.com/ > To: Sean Bruno > cc: Edward Tomasz Napierala , > src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: Re: svn commit: r320362 - head/share/zoneinfo > In-Reply-To: Message from Sean Bruno > of "Mon, 26 Jun 2017 12:21:15 -0600." a@freebsd.org> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Date: Mon, 26 Jun 2017 20:48:57 -0700 > > (since we're top posting.... ) > > Hi Sean, > > Do you want to give this a spin? > > Index: share/zoneinfo/Makefile > =================================================================== > --- share/zoneinfo/Makefile (revision 320389) > +++ share/zoneinfo/Makefile (working copy) > @@ -94,7 +94,7 @@ > .for f in ${TZS} > ${INSTALL} ${TAG_ARGS} \ > -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > - ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f} ${DESTDIR}/usr/share/zoneinfo/$ > {f} > + ${TZBUILDDIR}/${f} ${DESTDIR}/usr/share/zoneinfo/${f} > .endfor > ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/ > > ~cy > > > In message , Sean Bruno > write > s: > > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f > > Content-Type: multipart/mixed; boundary="VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ" > ; > > protected-headers="v1" > > From: Sean Bruno > > To: Edward Tomasz Napierala , src-committers@freebsd.org > , > > svn-src-all@freebsd.org, svn-src-head@freebsd.org > > Message-ID: > > Subject: Re: svn commit: r320362 - head/share/zoneinfo > > References: <201706261540.v5QFeOTj072841@repo.freebsd.org> > > In-Reply-To: <201706261540.v5QFeOTj072841@repo.freebsd.org> > > > > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ > > Content-Type: text/plain; charset=utf-8 > > Content-Language: en-US > > Content-Transfer-Encoding: quoted-printable > > > > Hmmm ... This seems to break 'poudriere jail -c jailname -m src=3D/usr/sr= > > c > > -v head" > > > > --- realinstall_subdir_share/zoneinfo --- > > install: builddir/Africa/Abidjan: No such file or directory > > > > > > On 06/26/17 09:40, Edward Tomasz Napierala wrote: > > > Author: trasz > > > Date: Mon Jun 26 15:40:24 2017 > > > New Revision: 320362 > > > URL: https://svnweb.freebsd.org/changeset/base/320362 > > >=20 > > > Log: > > > Provide visual feedback when timezone files are installed. > > > After r320003 it wasn't being shown in any way. > > > =20 > > > Submitted by: bdrewery > > > MFC after: 1 month > > > Differential Revision: https://reviews.freebsd.org/D11154 > > >=20 > > > Modified: > > > head/share/zoneinfo/Makefile > > >=20 > > > Modified: head/share/zoneinfo/Makefile > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > > =3D=3D=3D=3D > > > --- head/share/zoneinfo/Makefile Mon Jun 26 15:23:12 2017 (r32036 > > 1) > > > +++ head/share/zoneinfo/Makefile Mon Jun 26 15:40:24 2017 (r32036 > > 2) > > > @@ -83,14 +83,19 @@ zoneinfo: yearistype ${TDATA} > > > zic -D -d ${TZBUILDDIR} -p ${POSIXRULES} -m ${NOBINMODE} \ > > > ${LEAPFILE} -y ${.OBJDIR}/yearistype ${TZFILES} > > > =20 > > > +.if make(*install*) > > > +TZS!=3D cd ${TZBUILDDIR} && find -s * -type f > > > +.endif > > > + > > > beforeinstall: install-zoneinfo > > > install-zoneinfo: > > > mkdir -p ${DESTDIR}/usr/share/zoneinfo > > > cd ${DESTDIR}/usr/share/zoneinfo; mkdir -p ${TZBUILDSUBDIRS} > > > - cd ${TZBUILDDIR} && \ > > > - find -s * -type f -exec ${INSTALL} ${TAG_ARGS} \ > > > +.for f in ${TZS} > > > + ${INSTALL} ${TAG_ARGS} \ > > > -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > > > - \{} ${DESTDIR}/usr/share/zoneinfo/\{} \; > > > + ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f} ${DESTDIR}/usr/share/zoneinfo= > > /${f} > > > +.endfor > > > ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ > > > ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/ > > > =20 > > >=20 > > >=20 > > > > > > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ-- > > > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f > > Content-Type: application/pgp-signature; name="signature.asc" > > Content-Description: OpenPGP digital signature > > Content-Disposition: attachment; filename="signature.asc" > > > > -----BEGIN PGP SIGNATURE----- > > > > iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAllRUJtfFIAAAAAALgAo > > aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 > > QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 > > /LaIFggAlEX4pLTfDUaRsGoxWbGI0DiirmhR1nW74ESXjGXd4u9WSYKfvxK+oGPJ > > LRwxcimGw/v+h8piM102ijsmquE0+NlyyMAYjFNLb9tsZuR+kfzRbDwqiu3FNg8R > > zDnsvo69JHiyoi7r9BJB30Q6P9fZDGBtCrSQ9Up2IUiPHjz+pLUK6jxy29wflPSr > > qVDHitG2A7l7Sdn3Jsj8MWNw/4ehRNlhxudgg+F8v7tEJH9eNBpP6K6jR6B+aU/P > > VCPrKO1rRmmJTPxxPwskLLX4/xXrf8hmUFTm0uBbLtKbvzsaO5IZ9HKXJdYFlaRo > > dCw6yY1xFlMv/OrUWgSxj02fsd7GHg== > > =9Mia > > -----END PGP SIGNATURE----- > > > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f-- > > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > --==_Exmh_1498611286_142500 > Content-Type: text/plain; charset=us-ascii > > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > --==_Exmh_1498611286_142500-- > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Wed Jun 28 14:27:16 2017 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 10F9BDA3452 for ; Wed, 28 Jun 2017 14:27:16 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (gw.macktronics.com [209.181.253.70]) (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 E65C67B0F2 for ; Wed, 28 Jun 2017 14:27:13 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from carob.macktronics.com (olive.macktronics.com [209.181.253.66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 03D0A452 for ; Wed, 28 Jun 2017 09:17:46 -0500 (CDT) Date: Wed, 28 Jun 2017 09:17:45 -0500 (CDT) From: Dan Mack X-X-Sender: mack@localhost.local To: freebsd-current@freebsd.org Subject: fixes for stack clash vulnerability Message-ID: User-Agent: Alpine 2.11 (GSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 14:27:16 -0000 FreeBSD is mentioned as being vulnerable to this and Qualsys has working exploits which might be released soon: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash I don't remember seeing an advisory or seeing any fixes on the svn commit stream so just curious. Dan From owner-freebsd-current@freebsd.org Wed Jun 28 14:40:16 2017 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 94B11DA3760 for ; Wed, 28 Jun 2017 14:40:16 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 50C077B881 for ; Wed, 28 Jun 2017 14:40:16 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-oi0-x235.google.com with SMTP id p187so43063768oif.3 for ; Wed, 28 Jun 2017 07:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qopFm4y7KrwYSFxkWlhS7fcKQK8di3CSO8+4dIql/B8=; b=t3KsfEpgxRIDTYY//XdaQHufTmcNC3T0etKFEPmKeCIVK72mCtK0FQjXW0+QFmLTg7 rNmDmIIcT8tdgWp1WZdPdJb+xyinTqhaDRNk9NYYhr6NeiCSi8k8K1+4/gQXghH393Z+ QhnJDJQXrDg2usoLDkvswgOZ87FWEOC5eQfdJ1PaJXn8xX05K0rWs/kmAfsxJeXKtmHc TYHFg5vN5vIWcw1Ju2IOFf97Moy/jLyjIO4EB352pQpzjz136STUtwSN2wWu2S91NOv6 YCgNR82Y3m2f4jANAD9elF0OyzqrYbKN8biA6kbZn6AwMJbdAlTvDRKyUp5et5/bYbn5 6Zqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qopFm4y7KrwYSFxkWlhS7fcKQK8di3CSO8+4dIql/B8=; b=tNDXALZ33Hk2hretmDTlJ5ktL9Xvg/NYSPPrB3kUccOYh6jHWu4OHv1jz+y/DX+7oc b0d3J7slipFAhdfSUHRSt9CHYvME5fzyGDICteFheyopbvk90boztINaXWS9lQVTYTen 6+MG9Q42jijGovXi8DF2GtnnZjkLuviDs+UNqJKh4nvUTMFiws9BTf0IjN0LdlJjECQJ HaIUvE1rqSMuUsW17hhOAp/X5TWJBzMbQy0sS9ZO7eiNsx9pwujDyaoOqL9oYcj8XAvk WOcQRJ0qeh1moBh/OdswwxZhgDVxyhaBhOS+7k4T0gcqIzB/W6GP2mT/BqW6xGilzgRt QEyg== X-Gm-Message-State: AKS2vOzB6rjYJEJK/NjALwwIQiH+RANJmzF/IbCS1/Mtd0mmjaXuBASJ NVX1gsyRrV+WnqtXWuDsBg== X-Received: by 10.202.102.33 with SMTP id a33mr6650146oic.206.1498660815455; Wed, 28 Jun 2017 07:40:15 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id w189sm1124511oib.19.2017.06.28.07.40.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 07:40:14 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id p187so43063072oif.3 for ; Wed, 28 Jun 2017 07:40:14 -0700 (PDT) X-Received: by 10.202.84.214 with SMTP id i205mr1338637oib.158.1498660814222; Wed, 28 Jun 2017 07:40:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.133.136 with HTTP; Wed, 28 Jun 2017 07:40:13 -0700 (PDT) Received: by 10.74.133.136 with HTTP; Wed, 28 Jun 2017 07:40:13 -0700 (PDT) In-Reply-To: References: From: Jov Date: Wed, 28 Jun 2017 22:40:13 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: fixes for stack clash vulnerability To: Dan Mack Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 14:40:16 -0000 There is a commit fix this: https://svnweb.freebsd.org/changeset/base/32031= 7 Jov 2017=E5=B9=B46=E6=9C=8828=E6=97=A5 10:27 PM=EF=BC=8C"Dan Mack" =E5=86=99=E9=81=93=EF=BC=9A > FreeBSD is mentioned as being vulnerable to this and Qualsys has working > exploits which might be released soon: > > https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash > > I don't remember seeing an advisory or seeing any fixes on the svn commit > stream so just curious. > > Dan > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Jun 28 15:08:51 2017 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 252A5DA4252 for ; Wed, 28 Jun 2017 15:08:51 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (gw.macktronics.com [209.181.253.70]) (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 032357C980 for ; Wed, 28 Jun 2017 15:08:50 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from carob.macktronics.com (olive.macktronics.com [209.181.253.66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 537C1469; Wed, 28 Jun 2017 10:08:49 -0500 (CDT) Date: Wed, 28 Jun 2017 10:08:45 -0500 (CDT) From: Dan Mack X-X-Sender: mack@localhost.local To: Jov cc: freebsd-current Subject: Re: fixes for stack clash vulnerability In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (GSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 15:08:51 -0000 Thanks Jov - I missed it! Looks like it will MFC around Saturday :-) Dan On Wed, 28 Jun 2017, Jov wrote: > There is a commit fix this: https://svnweb.freebsd.org/changeset/base/320317 > > Jov > > 2017年6月28日 10:27 PM，"Dan Mack" 写道： > >> FreeBSD is mentioned as being vulnerable to this and Qualsys has working >> exploits which might be released soon: >> >> https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash >> >> I don't remember seeing an advisory or seeing any fixes on the svn commit >> stream so just curious. >> >> Dan >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Jun 28 21:38:46 2017 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 D4B25DAA2E7 for ; Wed, 28 Jun 2017 21:38:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 73AE8353F for ; Wed, 28 Jun 2017 21:38:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9833 invoked from network); 28 Jun 2017 21:42:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Jun 2017 21:42:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 17:38:44 -0400 (EDT) Received: (qmail 7666 invoked from network); 28 Jun 2017 21:38:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Jun 2017 21:38:43 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3E299EC8FE9; Wed, 28 Jun 2017 14:38:43 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: fixes for stack clash vulnerability Message-Id: <62FACC92-DB52-4792-B11A-E356149C7475@dsl-only.net> Date: Wed, 28 Jun 2017 14:38:42 -0700 To: amutu@amutu.com, mack@macktronics.com, FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 28 Jun 2017 21:38:46 -0000 Jov amutu at amutu.com wrote on Wed Jun 28 14:40:16 UTC 2017 > There is a commit fix this: = https://svnweb.freebsd.org/changeset/base/320317 Unfortunately the change broke other behavior resulting in some failing stack allocations for new threads and so there is also now: https://lists.freebsd.org/pipermail/svn-src-head/2017-June/102259.html and its: https://svnweb.freebsd.org/changeset/base/320430 to keep the overall system behavior correct. (At least that is my understanding of the relationship between those two commits.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 08:33:49 2017 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 EE333D96C6D for ; Thu, 29 Jun 2017 08:33:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 9FF647B3BA for ; Thu, 29 Jun 2017 08:33:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12873 invoked from network); 29 Jun 2017 08:33:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 08:33:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 04:33:47 -0400 (EDT) Received: (qmail 19474 invoked from network); 29 Jun 2017 08:33:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 08:33:47 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F5B8EC7E56; Thu, 29 Jun 2017 01:33:46 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320458 (e.g.) amd64 -> powerpc cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Message-Id: Date: Thu, 29 Jun 2017 01:33:45 -0700 To: Justin Hibbits , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 08:33:50 -0000 Beyond static_assert failures and overflow/underflow of long long it also it complains in some cases about: static_assert expression is not an integral constant expression [I will note that attempting a gcc 4.2.1 build did not stop and report such things for its libstdc++. The below is somehow libc++ and/or clang 4 specific.] Context: # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M amd64 = amd64 1200036 1200036 buildworld for TARGET_ARCH=3Dpowerpc resulted in: --- filesystem/operations.o --- = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 999999999}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 1000000000}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" static_assert(is_representable({min_time_t, 0}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::max()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::min()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^ . . . --- lib__L --- 7 errors generated. *** [filesystem/operations.o] Error code 1 make[5]: stopped in /usr/src/lib/libc++experimental .ERROR_TARGET=3D'filesystem/operations.o' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' .MAKE.LEVEL=3D'5' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' .CURDIR=3D'/usr/src/lib/libc++experimental' # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental TARGET filesystem/operations.o -- command output -- = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 999999999}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 1000000000}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" static_assert(is_representable({min_time_t, 0}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::max()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::min()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^ 7 errors generated. *** Error code 1 Build configuration: # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 320458 Last Changed Rev: 320458 # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ make $* # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 09:21:43 2017 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 17467D97C5C for ; Thu, 29 Jun 2017 09:21:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 434DC7CC35 for ; Thu, 29 Jun 2017 09:21:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21318 invoked from network); 29 Jun 2017 09:23:10 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 09:23:10 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 05:21:40 -0400 (EDT) Received: (qmail 22525 invoked from network); 29 Jun 2017 09:21:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 09:21:40 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D8997EC7E56; Thu, 29 Jun 2017 02:21:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: Date: Thu, 29 Jun 2017 02:21:38 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> References: To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 09:21:43 -0000 [TARGET_ARCH=3Dpowerpc64 fails similarly in its world32 part of its build.] On 2017-Jun-29, at 1:33 AM, Mark Millard wrote: > Beyond static_assert failures and overflow/underflow of long long > it also it complains in some cases about: >=20 > static_assert expression is not an integral constant expression >=20 >=20 > [I will note that attempting a gcc 4.2.1 build did not > stop and report such things for its libstdc++. The below > is somehow libc++ and/or clang 4 specific.] >=20 >=20 > Context: >=20 > # uname -apKU > FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M = amd64 amd64 1200036 1200036 >=20 > buildworld for TARGET_ARCH=3Dpowerpc resulted in: >=20 > --- filesystem/operations.o --- > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 999999999}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 1000000000}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" > static_assert(is_representable({min_time_t, 0}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::max()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::min()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^ > . . . > --- lib__L --- > 7 errors generated. > *** [filesystem/operations.o] Error code 1 >=20 > make[5]: stopped in /usr/src/lib/libc++experimental > .ERROR_TARGET=3D'filesystem/operations.o' > = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' > .CURDIR=3D'/usr/src/lib/libc++experimental' >=20 >=20 > # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta > # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta > CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o > CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental > TARGET filesystem/operations.o > -- command output -- > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 999999999}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 1000000000}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" > static_assert(is_representable({min_time_t, 0}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::max()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::min()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^ > 7 errors generated. > *** Error code 1 >=20 >=20 >=20 > Build configuration: >=20 >=20 > # svnlite info /usr/src/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 320458 > Last Changed Rev: 320458 >=20 >=20 > # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ > make $* >=20 >=20 > # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host > TO_TYPE=3Dpowerpc > # > KERNCONF=3DGENERICvtsc-NODBG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > # lldb requires missing atomic 8-byte operations for powerpc (non-64) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > # > # Use WERROR to avoid stopping at the likes of: > # error: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] > WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D The world32 part of a TARGET_ARCH=3Dpowerpc64 cross-buildworld also gets the same errors. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 10:04:23 2017 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 2AD9BD98A5C for ; Thu, 29 Jun 2017 10:04:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 DA2EA7E16D for ; Thu, 29 Jun 2017 10:04:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28064 invoked from network); 29 Jun 2017 10:04:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 10:04:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 06:04:21 -0400 (EDT) Received: (qmail 1759 invoked from network); 29 Jun 2017 10:04:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 10:04:20 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 37AD1EC8A8B; Thu, 29 Jun 2017 03:04:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> Date: Thu, 29 Jun 2017 03:04:19 -0700 Cc: FreeBSD Toolchain , FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 10:04:23 -0000 [The libc++ code in question appears to not be ready for 32-bit contexts with 64 bit times. Disable experimental/filesystem for now? I've submitted llvm bugzilla 33638 for the issue and have added it to llvm's 25780, the FreeBSD META for clang.] On 2017-Jun-29, at 2:21 AM, Mark Millard wrote: > [TARGET_ARCH=3Dpowerpc64 fails similarly in its world32 > part of its build.] >=20 > On 2017-Jun-29, at 1:33 AM, Mark Millard wrote: >=20 >> Beyond static_assert failures and overflow/underflow of long long >> it also it complains in some cases about: >>=20 >> static_assert expression is not an integral constant expression >>=20 >>=20 >> [I will note that attempting a gcc 4.2.1 build did not >> stop and report such things for its libstdc++. The below >> is somehow libc++ and/or clang 4 specific.] >>=20 >>=20 >> Context: >>=20 >> # uname -apKU >> FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M = amd64 amd64 1200036 1200036 >>=20 >> buildworld for TARGET_ARCH=3Dpowerpc resulted in: >>=20 >> --- filesystem/operations.o --- >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 999999999}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 1000000000}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" >> static_assert(is_representable({min_time_t, 0}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::max()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::min()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^ >> . . . >> --- lib__L --- >> 7 errors generated. >> *** [filesystem/operations.o] Error code 1 >>=20 >> make[5]: stopped in /usr/src/lib/libc++experimental >> .ERROR_TARGET=3D'filesystem/operations.o' >> = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' >> .MAKE.LEVEL=3D'5' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' >> .CURDIR=3D'/usr/src/lib/libc++experimental' >>=20 >>=20 >> # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta >> # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta >> CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o >> CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental >> TARGET filesystem/operations.o >> -- command output -- >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 999999999}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 1000000000}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" >> static_assert(is_representable({min_time_t, 0}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::max()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::min()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^ >> 7 errors generated. >> *** Error code 1 >>=20 >>=20 >>=20 >> Build configuration: >>=20 >>=20 >> # svnlite info /usr/src/ | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 320458 >> Last Changed Rev: 320458 >>=20 >>=20 >> # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ >> make $* >>=20 >>=20 >> # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host >> TO_TYPE=3Dpowerpc >> # >> KERNCONF=3DGENERICvtsc-NODBG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITH_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLD=3D >> # lldb requires missing atomic 8-byte operations for powerpc (non-64) >> WITHOUT_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> # >> # Use WERROR to avoid stopping at the likes of: >> # error: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] >> WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_REPRODUCIBLE_BUILD=3D >> WITH_DEBUG_FILES=3D >=20 >=20 > The world32 part of a TARGET_ARCH=3Dpowerpc64 cross-buildworld > also gets the same errors. Turns out the libc++ code in question looks like: _LIBCPP_CONSTEXPR_AFTER_CXX11 bool is_representable(TimeSpec const& tm) { if (tm.tv_sec >=3D 0) { return (tm.tv_sec < max_seconds) || (tm.tv_sec =3D=3D max_seconds && tm.tv_nsec <=3D max_nsec); } else if (tm.tv_sec =3D=3D (min_seconds - 1)) { return tm.tv_nsec >=3D min_nsec_timespec; } else { return (tm.tv_sec >=3D min_seconds); } } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else static_assert(is_representable({max_time_t, 999999999}), ""); static_assert(is_representable({max_time_t, 1000000000}), ""); static_assert(is_representable({min_time_t, 0}), ""); #endif #endif =20 _LIBCPP_CONSTEXPR_AFTER_CXX11 bool is_representable(file_time_type const& tm) { auto secs =3D duration_cast(tm.time_since_epoch()); auto nsecs =3D duration_cast(tm.time_since_epoch() - = secs); if (nsecs.count() < 0) { secs =3D secs + seconds(1); nsecs =3D nsecs + seconds(1); } using TLim =3D numeric_limits; if (secs.count() >=3D 0) return secs.count() <=3D TLim::max(); return secs.count() >=3D TLim::min(); } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else static_assert(!is_representable(file_time_type::max()), ""); static_assert(!is_representable(file_time_type::min()), ""); static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); #endif #endif _LIBCPP_CONSTEXPR_AFTER_CXX11 file_time_type convert_timespec(TimeSpec const& tm) { auto adj_msec =3D = duration_cast(nanoseconds(tm.tv_nsec)); if (tm.tv_sec >=3D 0) { auto Dur =3D seconds(tm.tv_sec) + microseconds(adj_msec); return file_time_type(Dur); } else if = (duration_cast(nanoseconds(tm.tv_nsec)).count() =3D=3D 0) = { return file_time_type(seconds(tm.tv_sec)); } else { // tm.tv_sec < 0 auto adj_subsec =3D duration_cast(seconds(1) - = nanoseconds(tm.tv_nsec)); auto Dur =3D seconds(tm.tv_sec + 1) - adj_subsec; return file_time_type(Dur); } } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else // FIXME add tests for 32 bit builds #endif #endif That "FIXME" likely gives a clue as to the status of of the handling for ILP32 contexts. There seems to be the expectation that IPL32 will not have 64-bit time_t as well. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 10:47:27 2017 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 83CD4D998BF; Thu, 29 Jun 2017 10:47:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AF197F66D; Thu, 29 Jun 2017 10:47:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 859203610B; Thu, 29 Jun 2017 12:47:24 +0200 (CEST) From: Dimitry Andric Message-Id: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Date: Thu, 29 Jun 2017 12:47:10 +0200 In-Reply-To: Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current To: Mark Millard References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 10:47:27 -0000 --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 29 Jun 2017, at 12:04, Mark Millard wrote: > > [The libc++ code in question appears to not be ready for > 32-bit contexts with 64 bit times. Disable > experimental/filesystem for now? I've submitted > llvm bugzilla 33638 for the issue and have > added it to llvm's 25780, the FreeBSD META for > clang.] Yes, this also broke earlier on arm and mips, which is why there is the following in lib/Makefile: .if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" _libcplusplus+= libc++experimental .endif I haven't yet found the time to address this issue. Upstream should already be aware of it, though. One nasty problem with this is that it is not possible to figure out at compile time what the size of time_t is. You always need some sort of configure-time test, and an external define. -Dimitry --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllU2rsACgkQsF6jCi4glqNamACfRXH3Q0QNcEPOzK2H7KCmwgLz oAoAnRy1xkn/1oXK7qgTm5Lx8a6r7Tqt =+cuF -----END PGP SIGNATURE----- --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A-- From owner-freebsd-current@freebsd.org Thu Jun 29 11:18:43 2017 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 204D1D9A5B9 for ; Thu, 29 Jun 2017 11:18:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 051B280838 for ; Thu, 29 Jun 2017 11:18:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0162ED9A5B8; Thu, 29 Jun 2017 11:18:43 +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 01034D9A5B7 for ; Thu, 29 Jun 2017 11:18:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A69DA80837 for ; Thu, 29 Jun 2017 11:18:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 8BFDE260615; Thu, 29 Jun 2017 13:18:32 +0200 (CEST) Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' To: "O. Hartmann" , Gary Jennejohn Cc: current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <20170626132608.03eab0cf@ernst.home> <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> <20170626144858.1b799130@ernst.home> <20170626150322.52e3f4ed@freyja.zeit4.iv.bundesimmobilien.de> From: Hans Petter Selasky Message-ID: Date: Thu, 29 Jun 2017 13:16:23 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170626150322.52e3f4ed@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 11:18:43 -0000 On 06/26/17 15:03, O. Hartmann wrote: > On Mon, 26 Jun 2017 14:48:58 +0200 > Gary Jennejohn wrote: > >> On Mon, 26 Jun 2017 14:00:48 +0200 >> "O. Hartmann" wrote: >> >>> On Mon, 26 Jun 2017 13:26:08 +0200 >>> Gary Jennejohn wrote: >>> >>>> On Mon, 26 Jun 2017 10:29:47 +0200 >>>> "O. Hartmann" wrote: >>>> >>>>> Over the past week we did not update several 12-CURRENT running >>>>> development hosts, so today is the first day of performing this task. >>>>> >>>>> First I hit the very same problem David Wolfskill reported earlier, a >>>>> fatal trap 12, but fowllowing the thread, I did as advised: >>>>> removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all >>>>> over the place) and recompiling world and kernel. >>>>> >>>>> Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update >>>>> and the INO64 update hasn't performed so far starting from r319971, I >>>>> installed the kernel, rebooted the box in single user mode (this time >>>>> smoothly), did a mergemaster and tried to do "make installworld" - but >>>>> the box instantanously bails out: >>>>> >>>>> [...] >>>>> Fatal error 'Cannot allocate red zone for initial thread' at line 392 in >>>>> file /usr/src/lib/libthread/thr_init.c >>>>> pid 60 (cc) uid0: exited on signal 6 ... >>>>> >>>>> [...] >>>>> >>>>> That way, I obviously can not install a world :-( >>>>> >>>>> What is wrong here? Is the problem resovable? >>>>> >>>> >>>> How recent was your last update? Some changes were made just a few >>>> hours ago to fix a stack growth problem in threads. >>> >>> Well, what do you mean by "... source is not up to date ..."? >>> Performing an svn update of /usr/src should suffice, shouldn't >>> it? If not, then ... please correct me. I think the sources >>> are up to date as of the moment the bug occured. >>> >>> I consider the sources up to date, it is on the latest updated >>> box r320355. >>> >> >> You did not explicitly state in the orignal post at which SVN >> revison your code was. Seems to me that my question was >> reasonable. >> >> Now it's clear that your source should have been up to date. >> >> Just for the record, I just booted a kernel from SVN r320357 which >> immediately resulted in a kernel panic. I had to delete everything >> under /usr/obj/usr/src/sys to get a working kernel. > > That has been made clear earlier in the thread, telling us that NO_CLEAN > and/or META_MODE leaves the object tree in a somehow unusable state. Id did so > twice this morning. > > I have to build a kernel with KTRACE capabilities as requested herein, but can > perform this not before tomorrow morning. > > Some people seem to report positive updates, but starting from a later svn > revision. So the problem seems to be transitional ... Hi, This happens on systems with identical 12-current kernel and different user-space, like jails. Fatal error 'Cannot allocate red zone for initial thread' at line 399 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) In the one case I have a more recent 12-current user-space. On the other one which is failing I have 10-stable with 12-current kernel. Here is the kdump leading up to the error: > 1465 xxx RET __sysctl 0 > 1465 xxx CALL __sysctl(0x7fffffffdb90,0x3,0x80127632c,0x7fffffffdc38,0,0) > 1465 xxx SCTL "kern.smp.cpus" > 1465 xxx RET __sysctl 0 > 1465 xxx CALL mmap(0,0x400000,0x3,0x1002,0xffffffff,0) > 1465 xxx RET mmap 34389098496/0x801c00000 > 1465 xxx CALL thr_self(0x801c06400) > 1465 xxx RET thr_self 0 > 1465 xxx CALL mmap(0x7fffffbfe000,0x1000,0,0x1000,0xffffffff,0) > 1465 xxx RET mmap -1 errno 12 Cannot allocate memory > 1465 xxx CALL write(0x2,0x7fffffffdbc7,0x1) > 1465 xxx GIO fd 2 wrote 1 byte Does this give any hints about a solution? Is this related to sign-extension of the -1U parameter in the end of mmap() ? --HPS From owner-freebsd-current@freebsd.org Thu Jun 29 11:58:48 2017 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 D66BED9B3A2 for ; Thu, 29 Jun 2017 11:58:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BD2E3819BE for ; Thu, 29 Jun 2017 11:58:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id B921CD9B3A1; Thu, 29 Jun 2017 11:58:48 +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 B8A6AD9B3A0 for ; Thu, 29 Jun 2017 11:58:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B0C3819BC for ; Thu, 29 Jun 2017 11:58:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 6ED05260615; Thu, 29 Jun 2017 13:58:44 +0200 (CEST) Subject: Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread' From: Hans Petter Selasky To: "O. Hartmann" , Gary Jennejohn Cc: current@freebsd.org, David Wolfskill , Boris Samorodov , Konstantin Belousov References: <20170625120731.GE1241@albert.catwhisker.org> <20170626102942.274b42e6@freyja.zeit4.iv.bundesimmobilien.de> <20170626132608.03eab0cf@ernst.home> <20170626140048.6d033c7e@freyja.zeit4.iv.bundesimmobilien.de> <20170626144858.1b799130@ernst.home> <20170626150322.52e3f4ed@freyja.zeit4.iv.bundesimmobilien.de> Message-ID: <0b276ac4-3f26-4f88-dba5-ef15189c859e@selasky.org> Date: Thu, 29 Jun 2017 13:56:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 11:58:48 -0000 On 06/29/17 13:16, Hans Petter Selasky wrote: > On 06/26/17 15:03, O. Hartmann wrote: >> On Mon, 26 Jun 2017 14:48:58 +0200 >> Gary Jennejohn wrote: >> >>> On Mon, 26 Jun 2017 14:00:48 +0200 >>> "O. Hartmann" wrote: >>> >>>> On Mon, 26 Jun 2017 13:26:08 +0200 >>>> Gary Jennejohn wrote: >>>>> On Mon, 26 Jun 2017 10:29:47 +0200 >>>>> "O. Hartmann" wrote: >>>>>> Over the past week we did not update several 12-CURRENT running >>>>>> development hosts, so today is the first day of performing this task. >>>>>> >>>>>> First I hit the very same problem David Wolfskill reported earlier, a >>>>>> fatal trap 12, but fowllowing the thread, I did as advised: >>>>>> removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all >>>>>> over the place) and recompiling world and kernel. >>>>>> >>>>>> Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update >>>>>> and the INO64 update hasn't performed so far starting from r319971, I >>>>>> installed the kernel, rebooted the box in single user mode (this time >>>>>> smoothly), did a mergemaster and tried to do "make installworld" - >>>>>> but >>>>>> the box instantanously bails out: >>>>>> >>>>>> [...] >>>>>> Fatal error 'Cannot allocate red zone for initial thread' at line >>>>>> 392 in >>>>>> file /usr/src/lib/libthread/thr_init.c >>>>>> pid 60 (cc) uid0: exited on signal 6 ... >>>>>> >>>>>> [...] >>>>>> >>>>>> That way, I obviously can not install a world :-( >>>>>> >>>>>> What is wrong here? Is the problem resovable? >>>>> >>>>> How recent was your last update? Some changes were made just a few >>>>> hours ago to fix a stack growth problem in threads. >>>> >>>> Well, what do you mean by "... source is not up to date ..."? >>>> Performing an svn update of /usr/src should suffice, shouldn't >>>> it? If not, then ... please correct me. I think the sources >>>> are up to date as of the moment the bug occured. >>>> >>>> I consider the sources up to date, it is on the latest updated >>>> box r320355. >>> >>> You did not explicitly state in the orignal post at which SVN >>> revison your code was. Seems to me that my question was >>> reasonable. >>> >>> Now it's clear that your source should have been up to date. >>> >>> Just for the record, I just booted a kernel from SVN r320357 which >>> immediately resulted in a kernel panic. I had to delete everything >>> under /usr/obj/usr/src/sys to get a working kernel. >> >> That has been made clear earlier in the thread, telling us that NO_CLEAN >> and/or META_MODE leaves the object tree in a somehow unusable state. >> Id did so >> twice this morning. >> >> I have to build a kernel with KTRACE capabilities as requested herein, >> but can >> perform this not before tomorrow morning. >> >> Some people seem to report positive updates, but starting from a later >> svn >> revision. So the problem seems to be transitional ... > > Hi, > > This happens on systems with identical 12-current kernel and different > user-space, like jails. > > Fatal error 'Cannot allocate red zone for initial thread' at line 399 in > file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) > > In the one case I have a more recent 12-current user-space. On the other > one which is failing I have 10-stable with 12-current kernel. > > Here is the kdump leading up to the error: > >> 1465 xxx RET __sysctl 0 >> 1465 xxx CALL >> __sysctl(0x7fffffffdb90,0x3,0x80127632c,0x7fffffffdc38,0,0) >> 1465 xxx SCTL "kern.smp.cpus" >> 1465 xxx RET __sysctl 0 >> 1465 xxx CALL >> mmap(0,0x400000,0x3,0x1002,0xffffffff,0) >> >> 1465 xxx RET mmap 34389098496/0x801c00000 >> 1465 xxx CALL thr_self(0x801c06400) >> 1465 xxx RET thr_self 0 >> 1465 xxx CALL >> mmap(0x7fffffbfe000,0x1000,0,0x1000,0xffffffff,0) >> 1465 xxx RET mmap -1 errno 12 Cannot allocate memory >> 1465 xxx CALL write(0x2,0x7fffffffdbc7,0x1) >> 1465 xxx GIO fd 2 wrote 1 byte > > Does this give any hints about a solution? Is this related to > sign-extension of the -1U parameter in the end of mmap() ? > Updating to the very latest version of FreeBSD-12-current kernel seems to fix this issue. --HPS From owner-freebsd-current@freebsd.org Thu Jun 29 12:54:13 2017 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 1DE45D9CEC4; Thu, 29 Jun 2017 12:54:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A356C8388F; Thu, 29 Jun 2017 12:54:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5TCs7SF007230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jun 2017 15:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5TCs7SF007230 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5TCs7Eg007229; Thu, 29 Jun 2017 15:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Jun 2017 15:54:07 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD Current Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Message-ID: <20170629125407.GM1935@kib.kiev.ua> References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: 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, 29 Jun 2017 12:54:13 -0000 On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: > One nasty problem with this is that it is not possible to figure out at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. It is arguably possible, with constexpr. From owner-freebsd-current@freebsd.org Thu Jun 29 17:16:34 2017 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 A08F2DA1779 for ; Thu, 29 Jun 2017 17:16:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 49CEE67268 for ; Thu, 29 Jun 2017 17:16:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21625 invoked from network); 29 Jun 2017 17:20:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 17:20:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 13:16:31 -0400 (EDT) Received: (qmail 5689 invoked from network); 29 Jun 2017 17:16:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 17:16:31 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C3333EC7E56; Thu, 29 Jun 2017 10:16:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <20170629125407.GM1935@kib.kiev.ua> Date: Thu, 29 Jun 2017 10:16:30 -0700 Cc: Dimitry Andric , Justin Hibbits , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> <20170629125407.GM1935@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 17:16:34 -0000 On 2017-Jun-29, at 5:54 AM, Konstantin Belousov = wrote: >=20 > On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >> One nasty problem with this is that it is not possible to figure out = at >> compile time what the size of time_t is. You always need some sort = of >> configure-time test, and an external define. >=20 > It is arguably possible, with constexpr. I took Dimitry's wording as probably referring to testing the size in the C/C++ preprocessor like the original code tests for __LP64__ being defined vs. not to control what it does: extending that to involve more preprocessor tests to pick from more code blocks. (But it is a guess given his wording.) I also took him to be excluding C++17's if-constexpr (or that the limitations in where how it can be used would prevent his intent) --and excluding the types of meta-programming/Substitution-Failure-Is-Not-An-Error usage that if-constexpr can simplify: too much rework of parts of libc++. Net result: extending the Makefile's "if" that he referenced with a powerpc-family test removes something in more contexts than have the problem. I think that he was wishing for a simple way to avoid that loss but still prevent the problem cases. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 17:33:12 2017 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 406F9DA1C41 for ; Thu, 29 Jun 2017 17:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 E3F2667DD3 for ; Thu, 29 Jun 2017 17:33:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2824 invoked from network); 29 Jun 2017 17:34:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 17:34:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 13:33:10 -0400 (EDT) Received: (qmail 3134 invoked from network); 29 Jun 2017 17:33:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 17:33:10 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6D0D0EC7E56; Thu, 29 Jun 2017 10:33:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> Date: Thu, 29 Jun 2017 10:33:09 -0700 Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 17:33:12 -0000 [Good news from the llvm side of things. . .] On 2017-Jun-29, at 3:47 AM, Dimitry Andric wrote: > On 29 Jun 2017, at 12:04, Mark Millard wrote: >>=20 >> [The libc++ code in question appears to not be ready for >> 32-bit contexts with 64 bit times. Disable >> experimental/filesystem for now? I've submitted >> llvm bugzilla 33638 for the issue and have >> added it to llvm's 25780, the FreeBSD META for >> clang.] >=20 > Yes, this also broke earlier on arm and mips, which is why there is = the > following in lib/Makefile: >=20 > .if ${MACHINE_CPUARCH} !=3D "arm" && ${MACHINE_CPUARCH} !=3D "mips" > _libcplusplus+=3D libc++experimental > .endif >=20 > I haven't yet found the time to address this issue. Upstream should > already be aware of it, though. >=20 > One nasty problem with this is that it is not possible to figure out = at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. I got a notice of a pending patch for the issue: Begin forwarded message: From: bugzilla-daemon at llvm.org Subject: [Bug 33638] FreeBSD head -r320347 moved TARGET_ARCH=3Dpowerpc = to 64-bit time_t but now experimental/filesystem/operations.cpp fails = static_asserts and such Date: June 29, 2017 at 10:23:56 AM PDT . . . Comment # 2 on bug 33638 from Eric Fiselier I have a patch for this waiting in the wings. I should be able to get to = it next week =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 29 21:46:53 2017 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 061E7DA622B; Thu, 29 Jun 2017 21:46:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B273A74E59; Thu, 29 Jun 2017 21:46:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::287b:b74d:6dec:6d86] (unknown [IPv6:2001:470:7a58:0:287b:b74d:6dec:6d86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 28C1E3615C; Thu, 29 Jun 2017 23:46:50 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Date: Thu, 29 Jun 2017 23:46:25 +0200 In-Reply-To: <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> Cc: Konstantin Belousov , Justin Hibbits , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> <20170629125407.GM1935@kib.kiev.ua> <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 29 Jun 2017 21:46:53 -0000 --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Jun 2017, at 19:16, Mark Millard wrote: >=20 > On 2017-Jun-29, at 5:54 AM, Konstantin Belousov wrote: >>=20 >> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >>> One nasty problem with this is that it is not possible to figure out = at >>> compile time what the size of time_t is. You always need some sort = of >>> configure-time test, and an external define. >>=20 >> It is arguably possible, with constexpr. >=20 > I took Dimitry's wording as probably referring to > testing the size in the C/C++ preprocessor like > the original code tests for __LP64__ being defined > vs. not to control what it does: extending that to > involve more preprocessor tests to pick from more > code blocks. (But it is a guess given his wording.) Yeah, what I meant is that the code does something like: #if __LP64__ static_assert(whatever, "foo"); #else static_assert(otherthing, "bar"); #endif where __LP64__ was erroneously thought to determine whether time_t was 64-bit. You cannot replace this with something like the following C++11 construct, though: constexpr bool time_t_64bit =3D sizeof(time_t) =3D=3D 8; if (time_t_64bit) static_assert(true, "time_t is OK"); else static_assert(false, "time_t is bad"); because both static assertions will be evaluated at compile time, and one of them will fail. In any case, Eric Fiselier already had some sort of patch lined up, but I slacked off on trying it out. Sorry about that. :) -Dimitry --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllVdUkACgkQsF6jCi4glqN3wACfVKTqwhL8YMitgny3Am39EozG vcIAnR4c7W/vYn89hZEtrWmXhek3Dis/ =CeAt -----END PGP SIGNATURE----- --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F-- From owner-freebsd-current@freebsd.org Fri Jun 30 09:02:06 2017 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 CB2EDD8C662 for ; Fri, 30 Jun 2017 09:02:06 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 663AB1568 for ; Fri, 30 Jun 2017 09:02:05 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id v5U98veg082613 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 30 Jun 2017 12:08:59 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id v5U91sVb054327 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 30 Jun 2017 12:01:54 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id v5U91rr2054326 for freebsd-current@freebsd.org; Fri, 30 Jun 2017 12:01:53 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: freebsd-current@freebsd.org Subject: Re: HEAD/i386 r320212: three reproducible panics Date: Fri, 30 Jun 2017 12:01:52 +0300 Message-ID: <6682061.Xu753KpcSl@asus.theweb.org.ua> Organization: Private person User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.30; amd64; ; ) In-Reply-To: <9394534.k5lyWsM15G@asus.theweb.org.ua> References: <9394534.k5lyWsM15G@asus.theweb.org.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 09:02:06 -0000 On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote: > a) Panic on shutdown: > > > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xc6be2023 > stack pointer = 0x28:0xe13c39f4 > frame pointer = 0x28:0xe13c3a20 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 11 (swi1: netisr 0) > trap number = 1 > panic: privileged instruction fault > cpuid = 1 > time = 1498206262 > Uptime: 6m19s > > The trace is: > > __curthread () at ./machine/pcpu.h:225 > 225 __asm("movl %%fs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:225 > #1 doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318 > #2 0xc06e88c4 in kern_reboot (howto=) > at ../../../kern/kern_shutdown.c:386 > #3 0xc06e8c5b in vpanic (fmt=, > ap=0xe13c3874 "}\334\235\300H\254 \306\001") > at ../../../kern/kern_shutdown.c:779 > #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s") > at ../../../kern/kern_shutdown.c:710 > #5 0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=) > at ../../../i386/i386/trap.c:978 > #6 0xc08eea38 in trap (frame=) > at ../../../i386/i386/trap.c:704 > #7 > #8 0xc6be2023 in ?? () > #9 0xc082ed53 in tcp_do_segment (m=, th=, > so=, tp=, drop_hdrlen=, > tlen=, iptos=, > ti_locked=) > at ../../../netinet/tcp_input.c:2444 > #10 0xc082c181 in tcp_input (mp=, offp=, > proto=) at ../../../netinet/tcp_input.c:1191 > #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823 > #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=, > proto=) at ../../../net/netisr.c:899 > #13 swi_net (arg=) at ../../../net/netisr.c:946 > #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=) > at ../../../kern/kern_intr.c:1336 > #15 0xc06bb5f0 in ithread_execute_handlers (ie=, > p=) at ../../../kern/kern_intr.c:1349 > #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430 > #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 , > arg=, frame=) > at ../../../kern/kern_fork.c:1038 > #18 > (kgdb) Interesting enough that panic triggered by named shutdown ( well, 'rndc flush' is triggering this panic too ) rndc calling isc__app_ctxrun function and finally panics the system: ---- lib/isc/unix/app.c --- return (ISC_R_UNEXPECTED); } #ifndef HAVE_UNIXWARE_SIGWAIT result = sigwait(&sset, &sig); <--- panic if (result == 0) { ---------------------------- variables are set to: sset= {__bits = {16387, 0, 0, 0}} sig = 134533280 From owner-freebsd-current@freebsd.org Fri Jun 30 09:07:59 2017 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 4DCD1D8C813 for ; Fri, 30 Jun 2017 09:07:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 F356F17F8 for ; Fri, 30 Jun 2017 09:07:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31473 invoked from network); 30 Jun 2017 09:07:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 09:07:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 05:07:56 -0400 (EDT) Received: (qmail 26453 invoked from network); 30 Jun 2017 09:07:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 09:07:56 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AD4B1EC7E56; Fri, 30 Jun 2017 02:07:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (but the debug kernel build works for the same world) Message-Id: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> Date: Fri, 30 Jun 2017 02:07:55 -0700 To: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 09:07:59 -0000 The -r320482 kernel build is via gcc 4.2.1. Both gcc 4.2.1 and clang based worlds show the same problems. TARGET_ARCH=3Dpowerpc64 is not showing the problems. The production kernel build fails but the debug works --each built from the same /usr/src/ tree. I'll note what a normal boot does before getting to the login prompt but after "Starting nfsd." ("Updating motd:" can be mixed in the trap text: not shown below.) I use an example and note a lot about what varies and what stays the same from example boot to example boot of the production kernel. [Manually entered from camera pictures of the screen.] fatal kernel trap exception =3D 0x700 (program) (for "illegal instruction") srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) (note: r0 always matches srr0) (note: ctr always matches srr0) srr1 =3D 0x89032 (stays the same) lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) curthread =3D 0x5ab8ae0 (varies) pid =3D 920 (varies), comm =3D mountd (stays the same) Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 = (varies)(CPU 1) (stack addr range varies) 0xd250a500: at soisconnected+0x21c (at stays the same) 0xd250a540: at unp_connect2+0xf0 (at stays the same) 0xd250a560: at unp_connectat+0x658 (at stays the same) 0xd250a770: at unp_connect+0x2c (at stays the same) 0xd250a790: at uipc_connect+0xc0 (at stays the same) 0xd250a7d0: at soconnectat+0xa0 (at stays the same) 0xd250a800: at soconnect+0x2c (at stays the same) 0xd250a820: at kern_connect+0134 (at stays the same) 0xd250a870: at sys_connect+0x64 (at stays the same) 0xd250a8b0: at trap+0x638 (at stays the same) 0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same) 0xd250aa80: at user SC trap (at stays the same) by 0x419db168 (stays the same) srr1=3D0xf032 (stays the same) r1 =3D0xffffd5e0 (stays the same) cr =3D0x24440840 (stays the same) xer =3D0x20000000 (stays the same) ctr =3D0x419db160 (stays the same) 005b7b48 stwu r1,-32(r1) 005b7b4c mflr r0 005b7b50 stw r29,20(r1) 005b7b54 stw r30,24(r1) 005b7b58 stw r31,28(r1) 005b7b5c stw r0,36(r1) 005b7b60 mr r31,r1 005b7b64 bcl- 20,4*cr7+so,005b7b68 = 005b7b68 mflr r30 005b7b6c lwz r0,-36(r30) 005b7b70 add r30,r0,r30 005b7b74 mr r29,r3 005b7b78 lwz r0,232(r3) 005b7b7c cmpwi cr7,r0,0 005b7b80 beq- cr7,005b7b98 = 005b7b84 lwz r4,236(r3) 005b7b88 li r5,1 005b7b8c mtctr r0 005b7b90 bctrl lr: 005b7b94 b 005b7bb4 . . . Apparently this means that sol->sol_upcall is not pointing to code at all yet is not null. Given the variability observed, it might be uninitialized --or sol itself is junk. . . void solisten_wakeup(struct socket *sol) { =20 if (sol->sol_upcall !=3D NULL) (void )sol->sol_upcall(sol, sol->sol_upcallarg, = M_NOWAIT); else { selwakeuppri(&sol->so_rdsel, PSOCK); KNOTE_LOCKED(&sol->so_rdsel.si_note, 0); } SOLISTEN_UNLOCK(sol); wakeup_one(&sol->sol_comp); } =20 005b8548 li r10,1 005b854c b 005b8558 005b8550 stwcx. r10,0,r9 005b8554 li r10,0 005b8558 cmpwi cr7,r10,0 005b855c bne- cr7,005b8568 = 005b8560 addi r3,r28,16 005b8564 bl 004d4218 <__mtx_unlock_sleep> 005b8568 mr r3,r27 at soisconnected+0x21c: 005b856c bl 005b7b48 005b8570 b 005b89f0 . . . void soisconnected(struct socket *so) { struct socket *head; . . . restart: =20 SOCK_LOCK(so); if ((head =3D so->so_listen) !=3D NULL && __predict_false(SOLISTEN_TRYLOCK(head) =3D=3D 0)) { SOCK_UNLOCK(so); goto restart; } =20 so->so_state &=3D = ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); so->so_state |=3D SS_ISCONNECTED; if (head !=3D NULL && (so->so_qstate =3D=3D SQ_INCOMP)) { again: if ((so->so_options & SO_ACCEPTFILTER) =3D=3D 0) { TAILQ_REMOVE(&head->sol_incomp, so, so_list); head->sol_incqlen--; TAILQ_INSERT_TAIL(&head->sol_comp, so, so_list); head->sol_qlen++; so->so_qstate =3D SQ_COMP; SOCK_UNLOCK(so); solisten_wakeup(head); /* unlocks */ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Jun 30 10:46:48 2017 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 94680D8E221 for ; Fri, 30 Jun 2017 10:46:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4542D642AC for ; Fri, 30 Jun 2017 10:46:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (216-72-41-245.barak.net.il [216.72.41.245]) (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 BB849260615; Fri, 30 Jun 2017 12:46:44 +0200 (CEST) Subject: Re: HEAD/i386 r320212: three reproducible panics To: "Oleg V. Nauman" , freebsd-current@freebsd.org References: <9394534.k5lyWsM15G@asus.theweb.org.ua> <6682061.Xu753KpcSl@asus.theweb.org.ua> From: Hans Petter Selasky Message-ID: <8a501e11-6bf8-4b38-c1d1-937c4b2f6745@selasky.org> Date: Fri, 30 Jun 2017 12:44:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <6682061.Xu753KpcSl@asus.theweb.org.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 10:46:48 -0000 On 06/30/17 11:01, Oleg V. Nauman wrote: > On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote: >> a) Panic on shutdown: >> >> >> Fatal trap 1: privileged instruction fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction pointer = 0x20:0xc6be2023 >> stack pointer = 0x28:0xe13c39f4 >> frame pointer = 0x28:0xe13c3a20 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 11 (swi1: netisr 0) >> trap number = 1 >> panic: privileged instruction fault >> cpuid = 1 >> time = 1498206262 >> Uptime: 6m19s >> >> The trace is: >> >> __curthread () at ./machine/pcpu.h:225 >> 225 __asm("movl %%fs:%1,%0" : "=r" (td) >> (kgdb) #0 __curthread () at ./machine/pcpu.h:225 >> #1 doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318 >> #2 0xc06e88c4 in kern_reboot (howto=) >> at ../../../kern/kern_shutdown.c:386 >> #3 0xc06e8c5b in vpanic (fmt=, >> ap=0xe13c3874 "}\334\235\300H\254 \306\001") >> at ../../../kern/kern_shutdown.c:779 >> #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s") >> at ../../../kern/kern_shutdown.c:710 >> #5 0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=) >> at ../../../i386/i386/trap.c:978 >> #6 0xc08eea38 in trap (frame=) >> at ../../../i386/i386/trap.c:704 >> #7 >> #8 0xc6be2023 in ?? () >> #9 0xc082ed53 in tcp_do_segment (m=, th=, >> so=, tp=, drop_hdrlen=, >> tlen=, iptos=, >> ti_locked=) >> at ../../../netinet/tcp_input.c:2444 >> #10 0xc082c181 in tcp_input (mp=, offp=, >> proto=) at ../../../netinet/tcp_input.c:1191 >> #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823 >> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=, >> proto=) at ../../../net/netisr.c:899 >> #13 swi_net (arg=) at ../../../net/netisr.c:946 >> #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=) >> at ../../../kern/kern_intr.c:1336 >> #15 0xc06bb5f0 in ithread_execute_handlers (ie=, >> p=) at ../../../kern/kern_intr.c:1349 >> #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430 >> #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 , >> arg=, frame=) >> at ../../../kern/kern_fork.c:1038 >> #18 >> (kgdb) > > Interesting enough that panic triggered by named shutdown ( well, 'rndc > flush' is triggering this panic too ) > > rndc calling isc__app_ctxrun function and finally panics the system: > > ---- lib/isc/unix/app.c --- > return (ISC_R_UNEXPECTED); > } > > #ifndef HAVE_UNIXWARE_SIGWAIT > result = sigwait(&sset, &sig); <--- panic > if (result == 0) { > > ---------------------------- > variables are set to: > sset= {__bits = {16387, 0, 0, 0}} > sig = 134533280 Here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358 Try to turn off hyperthreading to get a more sensible panic. Might look like an issue with 32-bit systems and iflib. --HPS From owner-freebsd-current@freebsd.org Fri Jun 30 15:50:30 2017 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 14389D947E0 for ; Fri, 30 Jun 2017 15:50:30 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A581C72BED for ; Fri, 30 Jun 2017 15:50:28 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id v5UFvPlC005057 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Jun 2017 18:57:27 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id v5UFoKuD056705 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jun 2017 18:50:20 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id v5UFoKpg056704; Fri, 30 Jun 2017 18:50:20 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: HEAD/i386 r320212: three reproducible panics Date: Fri, 30 Jun 2017 18:50:19 +0300 Message-ID: <3084228.CZavzcor0p@asus.theweb.org.ua> Organization: Private person User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.30; amd64; ; ) In-Reply-To: <8a501e11-6bf8-4b38-c1d1-937c4b2f6745@selasky.org> References: <9394534.k5lyWsM15G@asus.theweb.org.ua> <6682061.Xu753KpcSl@asus.theweb.org.ua> <8a501e11-6bf8-4b38-c1d1-937c4b2f6745@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 15:50:30 -0000 On Friday 30 June 2017 12:44:37 Hans Petter Selasky wrote: Hello Hans, > On 06/30/17 11:01, Oleg V. Nauman wrote: > > On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote: > >> a) Panic on shutdown: > >> Fatal trap 1: privileged instruction fault while in kernel mode > >> cpuid =3D 1; apic id =3D 01 > >> instruction pointer =3D 0x20:0xc6be2023 > >> stack pointer =3D 0x28:0xe13c39f4 > >> frame pointer =3D 0x28:0xe13c3a20 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>=20 > >> =3D DPL 0, pres 1, def32 1, gran 1 > >>=20 > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> current process =3D 11 (swi1: netisr 0) > >> trap number =3D 1 > >> panic: privileged instruction fault > >> cpuid =3D 1 > >> time =3D 1498206262 > >> Uptime: 6m19s > >>=20 > >> The trace is: > >> __curthread () at ./machine/pcpu.h:225 > >> 225 __asm("movl %%fs:%1,%0" : "=3Dr" (td) > >> (kgdb) #0 __curthread () at ./machine/pcpu.h:225 > >> #1 doadump (textdump=3D-968633472) at ../../../kern/kern_shutdown= .c:318 > >> #2 0xc06e88c4 in kern_reboot (howto=3D) > >>=20 > >> at ../../../kern/kern_shutdown.c:386 > >>=20 > >> #3 0xc06e8c5b in vpanic (fmt=3D, > >>=20 > >> ap=3D0xe13c3874 "}\334\235\300H\254 \306\001") > >> at ../../../kern/kern_shutdown.c:779 > >>=20 > >> #4 0xc06e8b1b in panic (fmt=3D0xc092e18e "%s") > >>=20 > >> at ../../../kern/kern_shutdown.c:710 > >>=20 > >> #5 0xc08eed21 in trap_fatal (frame=3D0xe13c39b4, eva=3D) > >>=20 > >> at ../../../i386/i386/trap.c:978 > >>=20 > >> #6 0xc08eea38 in trap (frame=3D) > >>=20 > >> at ../../../i386/i386/trap.c:704 > >>=20 > >> #7 > >> #8 0xc6be2023 in ?? () > >> #9 0xc082ed53 in tcp_do_segment (m=3D, th=3D, > >>=20 > >> so=3D, tp=3D, drop_hdrlen=3D, > >> tlen=3D, iptos=3D, > >> ti_locked=3D >> 0x1>) > >>=20 > >> at ../../../netinet/tcp_input.c:2444 > >> #10 0xc082c181 in tcp_input (mp=3D, offp=3D, > >>=20 > >> proto=3D) at ../../../netinet/tcp_input.c:1191= > >>=20 > >> #11 0xc0820878 in ip_input (m=3D0x0) at ../../../netinet/ip_input.= c:823 > >> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=3D, > >>=20 > >> proto=3D) at ../../../net/netisr.c:899 > >>=20 > >> #13 swi_net (arg=3D) at ../../../net/netisr.c:946 > >> #14 0xc06bb3c5 in intr_event_execute_handlers (p=3D0x109, ie=3D >> out>) > >>=20 > >> at ../../../kern/kern_intr.c:1336 > >>=20 > >> #15 0xc06bb5f0 in ithread_execute_handlers (ie=3D, > >>=20 > >> p=3D) at ../../../kern/kern_intr.c:1349 > >>=20 > >> #16 ithread_loop (arg=3D0xc60e6d00) at ../../../kern/kern_intr.c:1= 430 > >> #17 0xc06b8a76 in fork_exit (callout=3D0xc06bb560 , > >>=20 > >> arg=3D, frame=3D) > >> at ../../../kern/kern_fork.c:1038 > >>=20 > >> #18 > >> (kgdb) > >>=20 > > Interesting enough that panic triggered by named shutdown ( well,= 'rndc > >=20 > > flush' is triggering this panic too ) > >=20 > > rndc calling isc__app_ctxrun function and finally panics the syst= em: > > ---- lib/isc/unix/app.c --- > >=20 > > return (ISC_R_UNEXPECTED); > > =20 > > } > >=20 > > #ifndef HAVE_UNIXWARE_SIGWAIT > >=20 > > result =3D sigwait(&sset, &sig); <--- panic > > if (result =3D=3D 0) { > >=20 > > ---------------------------- > >=20 > > variables are set to: > > sset=3D {__bits =3D {16387, 0, 0, 0}} > > sig =3D 134533280 >=20 > Here: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220358 Subscribed && updated. >=20 > Try to turn off hyperthreading to get a more sensible panic. Done. >=20 > Migh-t look like an issue with 32-bit systems and iflib. I do not know if this related to iflib ; iflib functions were not ment= ioned=20 in backtraces. >=20 > --HPS --=20 =D0=9D=D0=B0=D1=83=D0=BC=D0=B0=D0=BD =D0=9E=D0=BB=D0=B5=D0=B3 From owner-freebsd-current@freebsd.org Fri Jun 30 18:19:59 2017 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 EE36BD97667 for ; Fri, 30 Jun 2017 18:19:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9E2B77A6F for ; Fri, 30 Jun 2017 18:19:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OSD00200HHNUX00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Fri, 30 Jun 2017 18:19:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1498846787; bh=1l2u/cMb4hzGZd/VrlS0rj3+qDLxX1m2Ji/rkfhk1i8=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=PvHsNbuzdIQwkocuCUcsQEfrjb7DMTuHXu9ORukRPmYSPLRtEnubHJMAIVdDZeAVQ xoOFgLnlPRMWcquKiTabUHiZbuxkcDxMy+1fgmIc7/a0nX+TjU9teJ0nHFAh5/UQQe i9PxkXZQDxvV/cwvEOIRG4deEImeqW38fc3L+fISNk+BHOYHhpnlc8D+6td4FrpBsH BFWMYd8KvYKwtymXUP+9kOzb6Q6AYlvn6aKg82ZnyA5YepXtew755/Rzlb4UG5WQjl 71sEC2W4VwJcxtk4sZELQN9j1tXjWOEHvjfQDWtbBS393Y9sUtYEl498mfNvu5C3YA vLjI3jB28lrrg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OSD00AEPHKWOO20@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Fri, 30 Jun 2017 18:19:46 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-30_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706300286 From: Toomas Soome Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: about history:) Message-id: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> Date: Fri, 30 Jun 2017 21:19:43 +0300 To: freebsd-current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 18:20:00 -0000 hi! there is an question about the tty line (canonical) mode =E2=80=94 the = internal implementation is using 2k buffer, but the related (public) = constants are claiming buffer size about 255 chars. Why it is so - any = hints about the background there? #define MAX_CANON 255 /* max bytes in term canon input = line */ #define MAX_INPUT 255 /* max bytes in terminal input = */ rgds, toomas= From owner-freebsd-current@freebsd.org Fri Jun 30 18:34:47 2017 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 4BC64D97BDF for ; Fri, 30 Jun 2017 18:34:47 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 CB9EE7819A for ; Fri, 30 Jun 2017 18:34:46 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: by mail-lf0-x244.google.com with SMTP id g21so10673378lfk.1 for ; Fri, 30 Jun 2017 11:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olevole-ru.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding; bh=Amd/nRItNYRX+C1HJMuwDFtEYmXkU8TA0VXRkM7jWK4=; b=cVcaJSduA+EWEE2cGxFz6Ni6R2vNYo4wL/6Lcpf7t2sh8W1pvyGqRpbsS4FSqKrGp6 JEcpy6nuX1Vo9QYD1BOsiTjzA9uiEHm/Lo3NPzKeQw8alfZvMm56XmST2VpxJS8jVGDQ HajVoNgjVb2O8eIqoxxLVD5ssE3QGwVBCmem+y5aEAFgqV4LhtOZ68uVzHHEAdiGNAxX PSFmo+SUQ0RiNHkpQSScHmqxVzOpMp5VCOHJik6DrrRNMgpWbwXd7suseUJRa9zdqKkK TWLqDAnYeblw5lVaLaEO5cuDou4gOn6rfmvMv6ybtpoZDi7V8ZujuzO84SjGUZ7Gy94m kVqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=Amd/nRItNYRX+C1HJMuwDFtEYmXkU8TA0VXRkM7jWK4=; b=P48PlhEU6+/Lu4Y7+KB64DyHbvyDTLvxAWiLEh/YiibCrSYHVPRLRCfrZJUx/JxPG2 LlGT0qA4VMNRxJawrKmi72R7jF53itjnGm0uT3ezcPamcHU4pb3g1qjv8VjeKo9FVR4a UyUKWRLZry8xY10w4gh8AfEbE7vrKqLrwpcLXqqIJfkAgVPTRdRLQp27ZIO6I6Kk0orB UTfC9oNuxVeED2fRM/fkRSR0p+DbkyLhOsoSERa5BuGaGCiIOhzw6YxfVg06EwVrYgUZ MnWt2CZ84COya5LEra+7husoipX4vvr8C+C5EiGZI3C+hjonbFn0StFfEZk7h0J1hTP/ SOLA== X-Gm-Message-State: AKS2vOzjF59TLlEsDq/rIlWkHwi86hjYlI+wCpvOwREsbat93hkG7OJl ItzuN9cMP3HkwS5tZvNnMQ== X-Received: by 10.25.160.66 with SMTP id j63mr6298171lfe.38.1498847684416; Fri, 30 Jun 2017 11:34:44 -0700 (PDT) Received: from gizmo.my.domain ([83.102.217.153]) by smtp.gmail.com with ESMTPSA id 98sm1803179ljb.23.2017.06.30.11.34.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 11:34:42 -0700 (PDT) From: Oleg Ginzburg To: FreeBSD Current , "kib@FreeBSD.org" , eugen@freebsd.org, Jilles Tjoelker , emaste@freebsd.org, Eric van Gyzen Subject: column regression after https://svnweb.freebsd.org/base?view=revision&revision=r320472 Date: Fri, 30 Jun 2017 21:34:42 +0300 Message-ID: <1578549.T7vdc21kZj@gizmo.my.domain> User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Fri, 30 Jun 2017 18:42:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 18:34:47 -0000 Hi, This commit https://svnweb.freebsd.org/base?view=revision&revision=r320472 breaks column(1) (and can affect something else this way ). Try to execute sample from man r320472: ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY " ; printf "HH:MM/YEAR NAME\n" ; ls -l | sed 1d ) | column -t column: line too long From owner-freebsd-current@freebsd.org Fri Jun 30 18:53:34 2017 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 B0882D980B5 for ; Fri, 30 Jun 2017 18:53:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 36E9E78A39; Fri, 30 Jun 2017 18:53:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5UIrS57005582 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jun 2017 21:53:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5UIrS57005582 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5UIrSkS005581; Fri, 30 Jun 2017 21:53:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Jun 2017 21:53:28 +0300 From: Konstantin Belousov To: Oleg Ginzburg Cc: FreeBSD Current , eugen@freebsd.org, Jilles Tjoelker , emaste@freebsd.org, Eric van Gyzen Subject: Re: column regression after https://svnweb.freebsd.org/base?view=revision&revision=r320472 Message-ID: <20170630185328.GW1935@kib.kiev.ua> References: <1578549.T7vdc21kZj@gizmo.my.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1578549.T7vdc21kZj@gizmo.my.domain> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 18:53:34 -0000 On Fri, Jun 30, 2017 at 09:34:42PM +0300, Oleg Ginzburg wrote: > Hi, > > This commit https://svnweb.freebsd.org/base?view=revision&revision=r320472 > breaks column(1) (and can affect something else this way ). Try to execute > sample from man r320472: > > ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY " ; printf "HH:MM/YEAR NAME\n" > ; ls -l | sed 1d ) | column -t > > column: line too long > Indeed, there is a typo. The following fixed the issue for me. diff --git a/lib/libc/stdio/fgetws.c b/lib/libc/stdio/fgetws.c index 83d697ea958..f47fea79934 100644 --- a/lib/libc/stdio/fgetws.c +++ b/lib/libc/stdio/fgetws.c @@ -116,7 +116,7 @@ ok: ret = ws; end: FUNLOCKFILE_CANCELSAFE(); - return (ws); + return (ret); error: ret = NULL; From owner-freebsd-current@freebsd.org Fri Jun 30 19:06:03 2017 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 432F2D98366 for ; Fri, 30 Jun 2017 19:06:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 272E078F8B for ; Fri, 30 Jun 2017 19:06:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 24dbb7e1-5dc7-11e7-bfce-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 24dbb7e1-5dc7-11e7-bfce-afd4446ba3af; Fri, 30 Jun 2017 19:05:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v5UJ5sP8001714; Fri, 30 Jun 2017 13:05:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1498849554.86861.65.camel@freebsd.org> Subject: Re: about history:) From: Ian Lepore To: Toomas Soome , freebsd-current Date: Fri, 30 Jun 2017 13:05:54 -0600 In-Reply-To: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> References: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 19:06:03 -0000 On Fri, 2017-06-30 at 21:19 +0300, Toomas Soome wrote: > hi! > > there is an question about the tty line (canonical) mode the > internal implementation is using 2k buffer, but the related (public) > constants are claiming buffer size about 255 chars. Why it is so - > any hints about the background there? > > #define MAX_CANON255/* max bytes in term canon > input line */ > #define MAX_INPUT255/* max bytes in terminal > input */ > > rgds, > toomas I don't have a direct answer to the question, but I do remember even before the rewrite that gave us the current kern/tty.c and friends, the old tty code had a #undef MAX_INPUT and then redefined it to 8K, with a comment that the value in limits.h was "wrong". From that I might surmise that people over the years were afraid of changing values in public header files that were handed down from the depths of unix history and that might break something if changed. I'm not sure MAX_CANON has a separate meaning from MAX_INPUT with the current code. I think both raw and canonical input use the same buffering scheme that's based on a linked list of 128-byte chunks. The total size of all the chunks on the list isn't compile-time constant, it's choosen at device open time to provide a buffer that is the smaller of 64K or 2 seconds of incoming data. (The code comment for years said 0.2 seconds of data, and perhaps that was the intent, but I corrected the comment rather than the code because .2s just isn't enough for slow embedded systems). You mention a 2k buffer... at the default input speed of 9600 baud the 2-seconds-size buffer is 1920 bytes. Pseudo-ttys and video consoles all seem to get this size. I just noticed there's nothing in the current code to prevent a pathologic buffer size of 0 if the input line speed is set to 0 but theCREAD flag is set (I think maybe a /dev/.init or .lock file could set the speed to 0). -- Ian From owner-freebsd-current@freebsd.org Sat Jul 1 01:33:09 2017 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 30074DA04E9; Sat, 1 Jul 2017 01:33:09 +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.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 C46DEEC0; Sat, 1 Jul 2017 01:33:08 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-d83ff7000000498b-62-5956fa9ef05c 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 5C.4C.18827.E9AF6595; Fri, 30 Jun 2017 21:27:59 -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 v611RwHC025080; Fri, 30 Jun 2017 21:27:58 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v611RqN8022900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 21:27:57 -0400 Date: Fri, 30 Jun 2017 20:27:52 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Final Call for 2017Q2 Quarterly Status Reports Message-ID: <20170701012751.GN68391@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nojv/V1ikwatdLBZz3nxgsti++R+j A5PHjE/zWQIYo7hsUlJzMstSi/TtErgyNr3pYi2YIlyxZMVttgbGswJdjJwcEgImEiemv2Hv YuTiEBJYzCRx5NBdNghnI6PE9Nb1LBDOVSaJb3OWsYC0sAioSlxaN5EZxGYTUJNYv+IamC0i IC+xr+k9O4jNDGT/2toEZgsLmEss+/WdFcTmBVq3ZFobI4QtKHFy5hMWiPoyiaYDj5m6GDmA bGmJ5f84QMKiAsoSfw/fY5nAyDcLSccsJB2zEDogwloSN/69xBS2lVi37j3LAka2VYyyKblV urmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEEhyynJu4Px312vQ4wCHIxKPLwbQsIihVgT y4orcw8xSnIwKYnyrrwWGinEl5SfUpmRWJwRX1Sak1p8iFEFaNejDasvMEqx5OXnpSqJ8D57 C9TKm5JYWZValA9TJs3BoiTOK67RGCEkkJ5YkpqdmlqQWgSTleHgUJLgdf4J1ChYlJqeWpGW mVOCkGbi4DzEKMHBAzR8yhmQ4cUFibnFmekQ+VOMilLivPEgzQIgiYzSPLheUKqRyN5f84pR HOgtYV6TH0BVPMA0Bdf9CmgwE9Bg4RkhIINLEhFSUg2M+mdS82sWiG+cXXXapKou0n2LcrrJ i7evl+fekbc35sr6Ws0QUrzsneFro2brH4Ktm47cEtzntPHdF44UGS2vdfrtEW8Uwy0/iXVM yX8zS7ziBuPO8FnO80USo7iurtn46ZCOoKRg9p9JRVcXXXr18eaUTfLpoQn/TzwNW72Hozog 49jbVQ29SizFGYmGWsxFxYkATUlMghADAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 01:33:09 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, Only one week remains before the July 7 deadline for submitting entries for the next FreeBSD Quarterly Status update, covering work done in April through June. Please consider submitting an entry for work you have done this quarter, even if it seems minor to you. Status report submissions do not need 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 work that is underway and completed. 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@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that 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 look forward to seeing your 2017 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html [5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZVvqSAAoJECjZpvNk63USigIMH2uZpCt+ofKjIx8T5oWRWVrd y8C2iNPcaFO6dvWPTV+UjMjvAlAMSV3wvLhxTW98Mw1uUkm1e1XnQ3JebXVEMPNi +PyNao3UTCKr63T6YKKCH7vqmFZRLebjCqTIhexlHxJl7S7ZcWfbddFuSMN62ASb 6enV8w+B3UY9KagbAh5S2LYk3gYuqhXMaqaecnCGbBn5O54WYzwRbRK13ekXsWXm k6jtF6GE7Pcoe1LsOIhrBawpgMCVxRaOvdjW2WhC/Ozd10Tg9wX6yQ6PEw1IgD6W Npmi3EYO3XIS4gp1z1LLkjE6i0V4elJ1a3AbIfCUQU2/6AsnOpvxF9zET874fMIq U/dGy7642IeSuAwQrWBk3/HdNnB1Dc5x2u2lq3pOAs6iI8pBpzTVL4CZETITNpoO h+24u51/4BKm+nZJHJvCm383eH1LfZFfT7/kzcjoUhb63bCimuknvFDQyeriEao1 7vK262ZC0OGV5LH658vxeR4vTMjZimWoMWxBsvwGE1hxZGw= =3b6G -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-current@freebsd.org Sat Jul 1 01:50:44 2017 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 491CDDA11DF for ; Sat, 1 Jul 2017 01:50:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 0927D1A9D for ; Sat, 1 Jul 2017 01:50:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28189 invoked from network); 1 Jul 2017 01:50:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Jul 2017 01:50:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 21:50:42 -0400 (EDT) Received: (qmail 18686 invoked from network); 1 Jul 2017 01:50:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jul 2017 01:50:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 47185EC81E6; Fri, 30 Jun 2017 18:50:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (involves ->sol_upcall pointing to ->so_rdsel) bugzilla 220404 From: Mark Millard In-Reply-To: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> Date: Fri, 30 Jun 2017 18:50:40 -0700 Cc: Justin Hibbits , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <3C743FFC-2E40-4077-988C-8C4BFBA7556B@dsl-only.net> References: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> To: glebius@FreeBSD.org, FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 01:50:44 -0000 [It looks like the 2 anonymous structs in the union in the new "struct socket" are being abused such that the ->sol_upcall from the 2nd struct is being access when it has a value that was apparently assigned via ->so_rcv->sb_sel . Details follow, added to prior notes that I sent out. I've submitted bugzilla 220404 for this. The new detailed material is interlaced with earlier material that I'd sent out.] On 2017-Jun-30, at 2:07 AM, Mark Millard wrote: > The -r320482 kernel build is via gcc 4.2.1. > Both gcc 4.2.1 and clang based worlds show > the same problems. TARGET_ARCH=3Dpowerpc64 > is not showing the problems. >=20 > The production kernel build fails > but the debug works --each built > from the same /usr/src/ tree. >=20 > I'll note what a normal boot does > before getting to the login prompt but > after "Starting nfsd." ("Updating motd:" > can be mixed in the trap text: not shown > below.) >=20 > I use an example and note a lot about what > varies and what stays the same from example > boot to example boot of the production > kernel. >=20 > [Manually entered from camera pictures > of the screen.] >=20 > fatal kernel trap > exception =3D 0x700 (program) (for "illegal instruction") > srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) > (note: r0 always matches srr0) > (note: ctr always matches srr0) > srr1 =3D 0x89032 (stays the same) > lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) > curthread =3D 0x5ab8ae0 (varies) > pid =3D 920 (varies), comm =3D mountd (stays the same) >=20 > Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 = (varies)(CPU 1) > (stack addr > range varies) > 0xd250a500: at soisconnected+0x21c (at stays the same) > 0xd250a540: at unp_connect2+0xf0 (at stays the same) > 0xd250a560: at unp_connectat+0x658 (at stays the same) > 0xd250a770: at unp_connect+0x2c (at stays the same) > 0xd250a790: at uipc_connect+0xc0 (at stays the same) > 0xd250a7d0: at soconnectat+0xa0 (at stays the same) > 0xd250a800: at soconnect+0x2c (at stays the same) > 0xd250a820: at kern_connect+0134 (at stays the same) > 0xd250a870: at sys_connect+0x64 (at stays the same) > 0xd250a8b0: at trap+0x638 (at stays the same) > 0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same) > 0xd250aa80: at user SC trap (at stays the same) > by 0x419db168 (stays the same) > srr1=3D0xf032 (stays the same) > r1 =3D0xffffd5e0 (stays the same) > cr =3D0x24440840 (stays the same) > xer =3D0x20000000 (stays the same) > ctr =3D0x419db160 (stays the same) (these are objdump reported addresses) > 005b7b48 stwu r1,-32(r1) > 005b7b4c mflr r0 > 005b7b50 stw r29,20(r1) > 005b7b54 stw r30,24(r1) > 005b7b58 stw r31,28(r1) > 005b7b5c stw r0,36(r1) > 005b7b60 mr r31,r1 > 005b7b64 bcl- 20,4*cr7+so,005b7b68 = > 005b7b68 mflr r30 > 005b7b6c lwz r0,-36(r30) > 005b7b70 add r30,r0,r30 > 005b7b74 mr r29,r3 > 005b7b78 lwz r0,232(r3) > 005b7b7c cmpwi cr7,r0,0 > 005b7b80 beq- cr7,005b7b98 = > 005b7b84 lwz r4,236(r3) > 005b7b88 li r5,1 > 005b7b8c mtctr r0 > 005b7b90 bctrl > lr: > 005b7b94 b 005b7bb4 = > . . . >=20 > Apparently this means that sol->sol_upcall is not > pointing to code at all yet is not null. Given the > variability observed, it might be uninitialized > --or sol itself is junk. . . Note: r3 reported as: 0x70bf860 void solisten_wakeup(struct socket *sol) { if (sol->sol_upcall !=3D NULL) (void )sol->sol_upcall(sol, sol->sol_upcallarg, = M_NOWAIT); else { selwakeuppri(&sol->so_rdsel, PSOCK); KNOTE_LOCKED(&sol->so_rdsel.si_note, 0); } SOLISTEN_UNLOCK(sol); wakeup_one(&sol->sol_comp); } (kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall $3 =3D 0x70bf948 (kgdb) print/x ((struct socket*)0x70bf860)->sol_upcall $2 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel $7 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist $8 =3D 0x70bf878 (kgdb) print/x &((struct = socket*)0x70bf860)->so_rdsel.si_tdlist.tqh_first $9 =3D 0x70bf878 But comparing to the first anonymous struct in the union in the new "struct socket": (kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall $15 =3D 0x70bf948 (kgdb) print/x &((struct socket*)0x70bf860)->so_rcv->sb_sel $22 =3D 0x70bf948 ->so_rcv is a struct sockbuf and ->so_rcv->sb_sel is a struct slinfo* . So pointing back to ->so_rdsel might well make sense. The rest is just supporting notes from things that I looked at before isolating the above relationship. (these are kgdb reported addresses, not vmcore.5 file offsets) 0x70bf860: 0x00c4a0b4 0x01430000 0x00000000 = 0x00000000 . . . 0x70bf940: 0x00000000 0x00000000 0x070bf878 = 0x00000000 but: 0x70bf870: 0x05ab8ae0 0x00000002 0x07271f80 = 0x07271f84 (kgdb) print/x *((struct socket*)0x70bf860) =20 $4 =3D {so_lock =3D {lock_object =3D {lo_name =3D 0xc4a0b4, lo_flags =3D = 0x1430000, lo_data =3D 0x0, lo_witness =3D 0x0}, mtx_lock =3D = 0x5ab8ae0}, so_count =3D 0x2, so_rdsel =3D {si_tdlist =3D {tqh_first =3D = 0x7271f80,=20 tqh_last =3D 0x7271f84}, si_note =3D {kl_list =3D {slh_first =3D = 0x0}, kl_lock =3D 0x5b6e84, kl_unlock =3D 0x5b6c64, kl_assert_locked =3D = 0x5b65d4, kl_assert_unlocked =3D 0x5b65f0, kl_lockarg =3D 0x70bf860,=20 kl_autodestroy =3D 0x0}, si_mtx =3D 0x5ab01f0}, so_wrsel =3D = {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, si_note =3D = {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0x5b6d64, kl_unlock =3D = 0x5b6b64,=20 kl_assert_locked =3D 0x5b660c, kl_assert_unlocked =3D 0x5b6628, = kl_lockarg =3D 0x70bf860, kl_autodestroy =3D 0x0}, si_mtx =3D 0x0}, = so_type =3D 0x1, so_options =3D 0x2, so_linger =3D 0x0, so_state =3D = 0x0,=20 so_pcb =3D 0x70b08a0, so_vnet =3D 0x0, so_proto =3D 0xd03060, so_timeo = =3D 0x0, so_error =3D 0x0, so_sigio =3D 0x0, so_cred =3D 0x5b2e600, = so_label =3D 0x0, so_gencnt =3D 0x1285, so_emuldata =3D 0x0, osd =3D { osd_nslots =3D 0x0, osd_slots =3D 0x0, osd_next =3D {le_next =3D = 0x0, le_prev =3D 0x0}}, so_fibnum =3D 0x0, so_user_cookie =3D 0x0, = so_ts_clock =3D 0x0, so_max_pacing_rate =3D 0x0, {{so_rcv =3D {sb_mtx =3D = { lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0x70bf920, = lo_data =3D 0x5d17860, lo_witness =3D 0x5d17a60}, mtx_lock =3D 0x1}, = sb_sx =3D {lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0x80, lo_data = =3D 0x0,=20 lo_witness =3D 0x0}, sx_lock =3D 0x0}, sb_sel =3D 0x70bf878, = sb_state =3D 0x0, sb_mb =3D 0x1, sb_mbtail =3D 0x800, sb_lastrecord =3D = 0x2000, sb_sndptr =3D 0x2000, sb_fnrdy =3D 0x0, sb_sndptroff =3D 0x0,=20 sb_acc =3D 0x0, sb_ccc =3D 0x0, sb_hiwat =3D 0x0, sb_mbcnt =3D = 0x0, sb_mcnt =3D 0x0, sb_ccnt =3D 0x0, sb_mbmax =3D 0x0, sb_ctl =3D 0x0, = sb_lowat =3D 0x1, sb_timeo =3D 0x0, sb_flags =3D 0x0, sb_upcall =3D 0x0,=20= sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, = tqh_last =3D 0x70bf9a4}, sb_aiotask =3D {ta_link =3D {stqe_next =3D = 0x0}, ta_pending =3D 0x0, ta_priority =3D 0x0, ta_func =3D 0x58eeb4,=20 ta_context =3D 0x70bf860}}, so_snd =3D {sb_mtx =3D = {lock_object =3D {lo_name =3D 0xc588cc, lo_flags =3D 0x1020000, lo_data = =3D 0x0, lo_witness =3D 0x0}, mtx_lock =3D 0x6}, sb_sx =3D {lock_object = =3D { lo_name =3D 0xc58efc, lo_flags =3D 0x2320000, lo_data =3D = 0x0, lo_witness =3D 0x0}, sx_lock =3D 0x6}, sb_sel =3D 0x70bf8a0, = sb_state =3D 0x0, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D = 0x0,=20 sb_sndptr =3D 0x0, sb_fnrdy =3D 0x0, sb_sndptroff =3D 0x0, = sb_acc =3D 0x0, sb_ccc =3D 0x0, sb_hiwat =3D 0x0, sb_mbcnt =3D 0x0, = sb_mcnt =3D 0x0, sb_ccnt =3D 0x0, sb_mbmax =3D 0x0, sb_ctl =3D 0x0, = sb_lowat =3D 0x800,=20 sb_timeo =3D 0x0, sb_flags =3D 0x0, sb_upcall =3D 0x0, = sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, tqh_last =3D = 0x70bfa44}, sb_aiotask =3D {ta_link =3D {stqe_next =3D 0x0}, ta_pending = =3D 0x0,=20 ta_priority =3D 0x0, ta_func =3D 0x58ee80, ta_context =3D = 0x70bf860}}, so_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, so_listen = =3D 0x0, so_qstate =3D 0x0, so_peerlabel =3D 0x0, so_oobmark =3D 0x0}, { sol_incomp =3D {tqh_first =3D 0x0, tqh_last =3D 0x70bf920}, = sol_comp =3D {tqh_first =3D 0x5d17860, tqh_last =3D 0x5d17a60}, sol_qlen = =3D 0x1, sol_incqlen =3D 0x0, sol_qlimit =3D 0x80, sol_accept_filter =3D = 0x0,=20 sol_accept_filter_arg =3D 0x0, sol_accept_filter_str =3D 0x0, = sol_upcall =3D 0x70bf878, sol_upcallarg =3D 0x0, sol_sbrcv_lowat =3D = 0x1, sol_sbsnd_lowat =3D 0x800, sol_sbrcv_hiwat =3D 0x2000,=20 sol_sbsnd_hiwat =3D 0x2000, sol_sbrcv_flags =3D 0x0, = sol_sbsnd_flags =3D 0x0, sol_sbrcv_timeo =3D 0x0, sol_sbsnd_timeo =3D = 0x0}}} For lo_name in sb_sx's lock_object: (kgdb) x/64c 0xc58ef0 0xc58ef0 <.rodata.str1.4+376864>: 116 't' 109 'm' 99 'c' 111 'o' = 112 'p' 121 'y' 105 'i' 110 'n' 0xc58ef8 <.rodata.str1.4+376872>: 0 '\0' 0 '\0' 0 '\0' 0 '\0' = 115 's' 111 'o' 95 '_' 115 's' 0xc58f00 <.rodata.str1.4+376880>: 110 'n' 100 'd' 95 '_' 115 's' = 120 'x' 0 '\0' 0 '\0' 0 '\0' which looks coherent to me: so_snd_sx For ta_func in sb_aiotask: (kgdb) x/64i 0x58ee80 0x58ee80 : stwu r1,-32(r1) . . . Looks coherent to me. But sol_upcall does not. >=20 >=20 > 005b8548 li r10,1 > 005b854c b 005b8558 > 005b8550 stwcx. r10,0,r9 > 005b8554 li r10,0 > 005b8558 cmpwi cr7,r10,0 > 005b855c bne- cr7,005b8568 = > 005b8560 addi r3,r28,16 > 005b8564 bl 004d4218 <__mtx_unlock_sleep> > 005b8568 mr r3,r27 > at soisconnected+0x21c: > 005b856c bl 005b7b48 > 005b8570 b 005b89f0 > . . . >=20 > void > soisconnected(struct socket *so) > { > struct socket *head; > . . . > restart: =20 > SOCK_LOCK(so); > if ((head =3D so->so_listen) !=3D NULL && > __predict_false(SOLISTEN_TRYLOCK(head) =3D=3D 0)) { > SOCK_UNLOCK(so); > goto restart; > } =20 > so->so_state &=3D = ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); > so->so_state |=3D SS_ISCONNECTED; > if (head !=3D NULL && (so->so_qstate =3D=3D SQ_INCOMP)) { > again: > if ((so->so_options & SO_ACCEPTFILTER) =3D=3D 0) { > TAILQ_REMOVE(&head->sol_incomp, so, so_list); > head->sol_incqlen--; > TAILQ_INSERT_TAIL(&head->sol_comp, so, = so_list); > head->sol_qlen++; > so->so_qstate =3D SQ_COMP; > SOCK_UNLOCK(so); > solisten_wakeup(head); /* unlocks */ > . . . Exception and its struct trapframe: (these are vmcore file offsets: subtract 0x1000 to get address) [ lr#0 ]: inside dbtrap 00c83f40 d2 50 a4 e0 00 10 0c 54 07 0b f8 78 d2 50 a4 e0 = |.P.....T...x.P..| 00c83f50 05 ab 8a e0 07 0b f8 60 00 00 00 00 00 00 00 01 = |.......`........| [ r3 ] 00c83f60 00 00 00 00 00 00 00 01 00 00 00 00 05 d1 78 70 = |..............xp| 00c83f70 00 00 00 01 05 ab 8a e0 00 00 00 00 00 00 00 00 = |................| 00c83f80 01 81 00 00 01 82 00 00 00 00 00 00 01 82 00 00 = |................| 00c83f90 01 82 00 00 00 03 8d 6c 00 03 8d 6c 00 00 00 00 = |.......l...l....| 00c83fa0 ff ff d7 58 00 00 00 00 00 d1 1a 84 00 d1 1a 84 = |...X............| 00c83fb0 d2 50 a5 1c 07 0b f8 60 05 d1 78 60 07 0b f8 60 = |.P.....`..x`...`| [ r28 ] 00c83fc0 00 d2 aa a0 d2 50 a4 e0 00 5b 7b 94 20 00 f0 44 = |.....P...[{. ..D| [ lr#1 ]: solisten_wakeup+0x4c 00c83fd0 00 00 00 00 07 0b f8 78 07 0b f8 78 00 08 90 32 = |.......x...x...2| [ srr0 ] [exception] 00c83fe0 00 00 07 00 00 00 00 00 00 00 00 00 01 c4 5f 00 = |.............._.| 00c83ff0 00 00 00 00 00 10 01 40 00 00 00 00 00 00 00 00 = |.......@........| solisten_wakeup+0x4c's related stack frame: 0b4004e0 d2 50 a5 00 00 50 8d f8 00 d2 b0 60 00 00 00 04 = |.P...P.....`....| 0b4004f0 05 d1 7a 78 05 d1 79 30 00 d2 aa a0 d2 50 a5 00 = |..zx..y0.....P..| 0xd250a500: at soisconnected+0x21c (at stays the same) 0b400500 d2 50 a5 40 00 5b 85 70 00 d2 aa a0 d2 50 a5 10 = |.P.@.[.p.....P..| 0b400510 d2 50 a5 60 00 5b d0 d8 00 d2 ab 90 00 00 00 04 = |.P.`.[..........| 0b400520 05 d1 78 60 05 ab 8a e0 07 25 94 80 05 d1 7a 78 = |..x`.....%....zx| 0b400530 07 0b 7a 10 05 d1 78 60 00 d2 ab 90 d2 50 a5 40 = |..z...x`.....P.@| 0xd250a540: at unp_connect2+0xf0 (at stays the same) 0b400540 d2 50 a5 60 00 5c 38 34 07 25 94 80 05 d1 7a 78 = |.P.`.\84.%....zx| 0b400550 07 0b 7a 10 07 0b 79 58 00 d2 ab 90 d2 50 a5 60 = |..z...yX.....P.`| "so" first then "so2" second, with so2 failing: 0x005c3824 : mr r3,r8 0x005c3828 : bl 0x5b8350 0x005c382c : mr r3,r29 0x005c3830 : bl 0x5b8350 0x005c3834 : li r3,0 static int unp_connect2(struct socket *so, struct socket *so2, int req) . . . case SOCK_STREAM: case SOCK_SEQPACKET: unp2->unp_conn =3D unp; if (req =3D=3D PRU_CONNECT && ((unp->unp_flags | unp2->unp_flags) & UNP_CONNWAIT)) soisconnecting(so); else soisconnected(so); soisconnected(so2); break; . . . 0xd250a560: at unp_connectat+0x658 (at stays the same) 0b400560 d2 50 a7 70 00 5c 3e c4 05 ab 8a e0 00 fd c1 c0 = |.P.p.\>.........| 0b400570 d2 50 a6 3d 00 00 00 01 02 00 01 00 00 00 04 00 = |.P.=3D............| 0b400580 04 00 00 00 00 00 00 00 00 00 00 00 05 a3 7c 60 = |..............|`| 0b400590 00 00 00 00 ff ff ff 9c 00 00 00 00 00 fd c1 c0 = |................| 0b4005a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 0b4005b0 00 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 = |................| 0b4005c0 07 25 94 80 05 a3 72 40 00 00 00 01 05 b2 10 15 = |.%....r@........| 0b4005d0 00 00 00 00 00 8c 05 bc 00 00 00 00 44 eb 41 81 = |............D.A.| 0b4005e0 00 00 00 00 00 00 c1 44 05 ab 8a e0 05 b2 e6 00 = |.......D........| 0b4005f0 00 20 00 00 05 b2 10 00 05 b2 10 09 00 00 00 0c |. = ..............| 0b400600 00 00 00 00 d2 50 a6 00 00 d3 23 bc 00 ce eb 40 = |.....P....#....@| 0b400610 07 25 94 80 d2 50 a6 38 05 b2 e6 00 05 ab 8a e0 = |.%...P.8........| 0b400620 02 00 01 00 00 00 04 00 04 00 00 00 00 00 00 00 = |................| 0b400630 05 c9 91 ec 00 00 00 04 07 0b 79 58 d2 2f 76 61 = |..........yX./va| 0b400640 72 2f 72 75 6e 2f 72 70 63 62 69 6e 64 2e 73 6f = |r/run/rpcbind.so| 0b400650 63 6b 00 70 00 00 00 05 00 00 00 00 00 00 00 10 = |ck.p............| 0b400660 05 d8 c4 80 d0 21 56 d4 00 d3 23 bc 00 00 00 04 = |.....!V...#.....| 0b400670 d2 50 a6 a0 40 00 f0 34 00 d1 1a 84 00 f5 0d 00 = |.P..@..4........| 0b400680 00 f5 0d 00 00 d1 1a 84 05 c9 91 ec 00 00 00 08 = |................| 0b400690 41 99 00 00 05 c2 49 d8 41 98 80 00 41 98 c0 00 = |A.....I.A...A...| 0b4006a0 00 00 00 07 00 00 00 05 d0 21 57 c8 41 99 00 00 = |.........!W.A...| 0b4006b0 05 c9 91 ec 00 fd c1 c0 00 d3 36 8c d2 50 a6 c0 = |..........6..P..| 0b4006c0 d2 50 a6 e0 00 8c 74 c0 05 c9 91 38 00 00 00 04 = |.P....t....8....| 0b4006d0 d2 50 a6 f0 00 fd c1 c0 d2 50 a6 e0 d2 50 a6 e0 = |.P.......P...P..| 0b4006e0 d2 50 a7 10 00 8f a0 94 d2 50 a6 f0 d2 50 a6 f0 = |.P.......P...P..| 0b4006f0 d2 50 a7 10 00 00 00 00 00 00 01 21 00 00 00 41 = |.P.........!...A| 0b400700 00 00 00 06 05 be e4 c0 00 d2 ab 64 d2 50 a7 10 = |...........d.P..| 0b400710 d2 50 a7 80 00 48 f2 70 00 d3 11 94 d2 50 a7 20 = |.P...H.p.....P. | 0b400720 d2 50 a7 40 00 87 1c 04 02 00 07 ff ff ff ff ff = |.P.@............| 0b400730 04 00 00 00 00 1f ff ff 00 d3 10 54 68 a4 aa 22 = |...........Th.."| 0b400740 d2 50 a7 60 00 87 1c 40 00 00 00 00 05 ab 8a e0 = |.P.`...@........| 0b400750 05 ab 8a e0 ff ff ff 9c 05 ab 8a e0 05 ab 8a e0 = |................| 0b400760 05 b1 54 20 05 d1 7a 78 00 d2 ab 90 d2 50 a7 70 |..T = ..zx.....P.p| The unp_connectat context is more complicated so I stop quoting code here. 0xd250a770: at unp_connect+0x2c (at stays the same) 0b400770 d2 50 a7 90 00 5c 41 c8 00 d2 ab 64 d2 50 a7 80 = |.P...\A....d.P..| 0b400780 d2 50 a7 e0 00 48 f5 e0 d2 50 a7 90 00 00 00 00 = |.P...H...P......| 0xd250a790: at uipc_connect+0xc0 (at stays the same) 0b400790 d2 50 a7 d0 00 5c 7b cc 00 00 00 06 05 be e4 c0 = |.P...\{.........| 0b4007a0 d2 50 a8 10 00 86 32 e8 20 00 f0 38 00 00 00 01 |.P....2. = ..8....| 0b4007b0 00 03 8d 6c 00 00 00 00 ff ff d7 58 05 b1 54 20 = |...l.......X..T | 0b4007c0 ff ff ff 9c 05 d1 7a 78 00 d2 ab 64 d2 50 a7 d0 = |......zx...d.P..| 0xd250a7d0: at soconnectat+0xa0 (at stays the same) 0b4007d0 d2 50 a8 00 00 5b 61 68 00 d2 ab 64 d2 50 a7 e0 = |.P...[ah...d.P..| 0b4007e0 d2 50 a8 20 00 5b ff 64 05 b1 54 20 05 ab 8a e0 |.P. .[.d..T = ....| 0b4007f0 00 00 00 00 05 d1 7a 78 00 d2 ab 64 d2 50 a8 00 = |......zx...d.P..| 0xd250a800: at soconnect+0x2c (at stays the same) 0b400800 d2 50 a8 20 00 5b 61 f4 05 b1 54 20 05 ab 8a e0 |.P. .[a...T = ....| 0b400810 00 00 00 25 05 d1 7a 78 d2 50 a8 20 d2 50 a8 20 |...%..zx.P. = .P. | 0xd250a820: at kern_connect+0134 (at stays the same) 0b400820 d2 50 a8 70 00 5c 19 14 ff ff d7 68 00 00 00 16 = |.P.p.\.....h....| 0b400830 00 00 00 17 05 b1 54 20 02 00 00 00 80 00 00 00 |......T = ........| 0b400840 04 00 00 00 00 00 00 00 41 98 c0 00 05 be e4 c0 = |........A.......| 0b400850 05 ab 8a e0 00 00 00 00 d2 50 aa 88 05 ab 8a e0 = |.........P......| 0b400860 00 00 00 00 05 ab 8d 78 00 d2 ab 64 d2 50 a8 70 = |.......x...d.P.p| 0xd250a870: at sys_connect+0x64 (at stays the same) 0b400870 d2 50 a8 b0 00 5c 1c 58 d2 50 aa 88 00 00 04 00 = |.P...\.X.P......| 0b400880 00 00 00 01 d2 50 aa 88 00 00 00 80 05 b1 54 20 = |.....P........T | 0b400890 d2 50 a8 b0 00 8f c3 b0 d2 50 aa 88 00 00 00 00 = |.P.......P......| 0b4008a0 05 ab 8d 70 05 d9 5a b0 00 d3 37 e8 d2 50 a8 b0 = |...p..Z...7..P..| 0xd250a8b0: at trap+0x638 (at stays the same) 0b4008b0 d2 50 aa 50 00 8f cc 3c 5a 2e a6 14 b1 ae c2 60 = |.P.P... 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 4C63CD912F9 for ; Sat, 1 Jul 2017 05:45:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 EF2CD7A131 for ; Sat, 1 Jul 2017 05:45:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21670 invoked from network); 1 Jul 2017 05:45:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jul 2017 05:45:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 01:45:41 -0400 (EDT) Received: (qmail 21030 invoked from network); 1 Jul 2017 05:45:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jul 2017 05:45:40 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0C279EC81E6; Fri, 30 Jun 2017 22:45:40 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ] Message-Id: <285F63EB-9DC3-46DC-9849-3B47FDC719AE@dsl-only.net> Date: Fri, 30 Jun 2017 22:45:39 -0700 Cc: imb@protected-networks.net, Hans Petter Selasky , iz-rpi03@hs-karlsruhe.de To: oleg@theweb.org.ua, FreeBSD Current , glebius@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 05:45:43 -0000 [Just for the 3rd backtrace example. . .] Oleg V. Nauman oleg at theweb.org.ua wrote on Fri Jun 23 16:58:07 UTC 2017 : . . . > __curthread () at ./machine/pcpu.h:225 > 225 __asm("movl %%fs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:225 > #1 doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318 > #2 0xc06e88c4 in kern_reboot (howto=) > at ../../../kern/kern_shutdown.c:386 > #3 0xc06e8c5b in vpanic (fmt=, > ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001") > at ../../../kern/kern_shutdown.c:779 > #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s") > at ../../../kern/kern_shutdown.c:710 > #5 0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=) > at ../../../i386/i386/trap.c:978 > #6 0xc08eea38 in trap (frame=) > at ../../../i386/i386/trap.c:704 > #7 > #8 0xc6bcda1b in ?? () > #9 0xc0770281 in unp_connect2 (so=, so2=, > req=) at ../../../kern/uipc_usrreq.c:1497 > #10 0xc076ff17 in unp_connectat (fd=, so=, > nam=, td=) > at ../../../kern/uipc_usrreq.c:1446 > #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500, > td=) at ../../../kern/uipc_usrreq.c:1310 > #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=) > at ../../../kern/uipc_usrreq.c:587 > #13 0xc076a042 in kern_connectat (td=, dirfd=-100, > fd=, sa=0xc662d500) at ../../../kern/uipc_syscalls.c:505 > #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988) > at ../../../kern/uipc_syscalls.c:470 > #15 0xc08ef679 in syscallenter (td=) > at ../../../i386/i386/../../kern/subr_syscall.c:132 > #16 syscall (frame=) at ../../../i386/i386/trap.c:1103 > #17 > #18 0x283a4747 in ?? () > Backtrace stopped: Cannot access memory at address 0xbfbfe794 There are problems with a union having fields that interfere with each other. The details of the layout and interference likely vary from TARGET_ARCH to TARGET_ARCH. This is from new material added in head -r319722 and involves /head/sys/sys/socketvar.h and the new union in struct socket. See bugzilla 220404 and its analysis of a repeatable crash on 32-bit powerpc for head -r320482 (I'd made a large jump from well before -r319722): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404 It also involves unp_connect2, unp_connect, kern_connectat, sys_connect and is likely involved. But different aliasing in the union across architectures likely lead to varying details for the behavior that results from the bad handling of union use. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jul 1 11:26:28 2017 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 BB8D8DAAAF4 for ; Sat, 1 Jul 2017 11:26:28 +0000 (UTC) (envelope-from david@catwhisker.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 A350782764 for ; Sat, 1 Jul 2017 11:26:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9F551DAAAF3; Sat, 1 Jul 2017 11:26:28 +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 9ECC9DAAAF2 for ; Sat, 1 Jul 2017 11:26:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 AFB5E82763; Sat, 1 Jul 2017 11:26:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v61BQJBq081804; Sat, 1 Jul 2017 11:26:19 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v61BQJf3081803; Sat, 1 Jul 2017 04:26:19 -0700 (PDT) (envelope-from david) Date: Sat, 1 Jul 2017 04:26:19 -0700 From: David Wolfskill To: current@freebsd.org Cc: jah@freebsd.org Subject: r320528? "undefined reference to `_bus_dma*" linking kernel Message-ID: <20170701112619.GV1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org, jah@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A++lktL53qannAg6" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 11:26:28 -0000 --A++lktL53qannAg6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is for a transition from r320495 --> r32053ng: FreeBSD g1-227.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #396 r3204= 95M/320496:1200036: Fri Jun 30 05:20:04 PDT 2017 root@g1-227.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 =2E.. >>> World build completed on Sat Jul 1 04:00:34 PDT 2017 =2E.. >>> Kernel build for CANARY started on Sat Jul 1 04:00:34 PDT 2017 =2E.. >>> stage 1: configuring the kernel =2E.. >>> stage 2.2: rebuilding the object tree =2E.. >>> stage 2.3: build tools =2E.. >>> stage 3.1: building everything =2E.. =3D=3D=3D> de (all) --- all_subdir_cxgbe --- Building /common/S4/obj/usr/src/sys/CANARY/modules/usr/src/sys/modules/cxgb= e/ccr/t4_crypto.o --- all_subdir_dpms --- =3D=3D=3D> dpms (all) --- all_subdir_drm --- =3D=3D=3D> drm (all) --- all_subdir_drm/drm --- =3D=3D=3D> drm/drm (all) --- kernel.full --- /usr/src/sys/dev/advansys/adwcam.c:302: undefined reference to `_bus_dmamap= _sync' /usr/src/sys/dev/advansys/adwcam.c:316: undefined reference to `_bus_dmamap= _unload' if_ae.o: In function `ae_alloc_rings': /usr/src/sys/dev/ae/if_ae.c:1162: undefined reference to `bus_dmamem_alloc' /usr/src/sys/dev/ae/if_ae.c:1182: undefined reference to `bus_dmamem_alloc' /usr/src/sys/dev/ae/if_ae.c:1202: undefined reference to `bus_dmamem_alloc' if_ae.o: In function `ae_dma_free': /usr/src/sys/dev/ae/if_ae.c:1230: undefined reference to `_bus_dmamap_unloa= d' /usr/src/sys/dev/ae/if_ae.c:1232: undefined reference to `bus_dmamem_free' /usr/src/sys/dev/ae/if_ae.c:1241: undefined reference to `_bus_dmamap_unloa= d' /usr/src/sys/dev/ae/if_ae.c:1243: undefined reference to `bus_dmamem_free' /usr/src/sys/dev/ae/if_ae.c:1252: undefined reference to `_bus_dmamap_unloa= d' /usr/src/sys/dev/ae/if_ae.c:1254: undefined reference to `bus_dmamem_free' if_ae.o: In function `ae_tx_intr': /usr/src/sys/dev/ae/if_ae.c:1823: undefined reference to `_bus_dmamap_sync' /usr/src/sys/dev/ae/if_ae.c:1825: undefined reference to `_bus_dmamap_sync' /usr/src/sys/dev/ae/if_ae.c:1875: undefined reference to `_bus_dmamap_sync' --- modules-all --- --- all_subdir_cxgbe --- --- all_subdir_cxgbe/cxgbei --- Building /common/S4/obj/usr/src/sys/CANARY/modules/usr/src/sys/modules/cxgb= e/cxgbei/icl_cxgbei.o --- kernel.full --- /usr/src/sys/dev/ae/if_ae.c:1877: undefined reference to `_bus_dmamap_sync' =2E.. --- kernel.full --- *** [kernel.full] Error code 1 make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY =2EERROR_TARGET=3D'kernel.full' =2EERROR_META_FILE=3D'/common/S4/obj/usr/src/sys/CANARY/kernel.full.meta' =2EMAKE.LEVEL=3D'2' MAKEFILE=3D'' =2EMAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' _ERROR_CMD=3D'@rm -f kernel.full; @echo linking kernel.full; @ld -m elf_x86= _64_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.amd64 --no-warn-mismatch= --warn-common --export-dynamic --dynamic-linker /red/herring -o kernel.f= ull -X locore.o cam.o cam_compat.o cam_iosched.o cam_periph.o cam_queue.o = cam_sim.o cam_xpt.o ata_all.o ata_xpt.o ata_pmp.o scsi_xpt.o scsi_all.o s= csi_cd.o scsi_ch.o ata_da.o scsi_da.o scsi_pass.o scsi_sa.o scsi_enc.o scs= i_enc_ses.o scsi_enc_safte.o smp_all.o freebsd32_capability.o freebsd32_io= ctl.o freebsd32_misc.o freebsd32_syscalls.o freebsd32_sysent.o ck_array.o = ck_barrier_centralized.o ck_barrier_combining.o ck_barrier_dissemination.= o ck_barrier_mcs.o ck_barrier_tournament.o ck_epoch.o ck_hp.o ck_hs.o ck_h= t.o ck_rhs.o dsargs.o dscontrol.o dsdebug.o dsfield.o dsinit.o dsmethod.o= dsmthdat.o dsobject.o dsopcode.o dsutils.o dswexec.o dswload.o dswload2.o= dswscope.o dswstate.o evevent.o evglock.o evgpe.o evgpeblk.o evgpeinit.o = evgpeutil.o evhandler.o evmisc.o evregion.o evrgnini.o evsci.o evxface.o e= vxfevnt.o evxfgpe.o evxfregn.o exconcat.o exconfig.o exconvrt.o excreate.o= exdebug.o exdump.o exfield.o exfldio.o exmisc.o exmutex.o exnames.o exop= arg1.o exoparg2.o exoparg3.o exoparg6.o exprep.o exregion.o exresnte.o exr= esolv.o exresop.o exstore.o exstoren.o exstorob.o exsystem.o extrace.o exu= tils.o hwacpi.o hwesleep.o hwgpe.o hwpci.o hwregs.o hwsleep.o hwtimer.o hw= valid.o hwxface.o hwxfsleep.o nsaccess.o nsalloc.o nsarguments.o nsconvert= =2Eo nsdump.o nseval.o nsinit.o nsload.o nsnames.o nsobject.o nsparse.o n= spredef.o nsprepkg.o nsrepair.o nsrepair2.o nssearch.o nsutils.o nswalk.o = nsxfeval.o nsxfname.o nsxfobj.o psargs.o psloop.o psobject.o psopcode.o ps= opinfo.o psparse.o psscope.o pstree.o psutils.o pswalk.o psxface.o rsaddr.= o rscalc.o rscreate.o rsdumpinfo.o rsinfo.o rsio.o rsirq.o rslist.o rsmem= ory.o rsmisc.o rsserial.o rsutils.o rsxface.o tbdata.o tbfadt.o tbfind.o t= binstal.o tbprint.o tbutils.o tbxface.o tbxfload.o tbxfroot.o utaddress.o = utalloc.o utascii.o utbuffer.o utcache.o utcopy.o utdebug.o utdecode.o utd= elete.o uterror.o uteval.o utexcep.o utglobal.o uthex.o utids.o utinit.o = utlock.o utmath.o utmisc.o utmutex.o utnonansi.o utobject.o utosi.o utowne= rid.o utpredef.o utresrc.o utstate.o utstring.o utstrtoul64.o utxface.o ut= xferror.o utxfinit.o cnvlist.o dnvlist.o nvlist.o nvpair.o bf_ecb.o bf_ske= y.o camellia.o camellia-api.o des_ecb.o des_setkey.o rijndael-alg-fst.o r= ijndael-api-fst.o rijndael-api.o sha1.o sha256c.o sha512c.o skein.o skein_= block.o siphash.o siphash_test.o db_access.o db_break.o db_capture.o db_co= mmand.o db_examine.o db_expr.o db_input.o db_lex.o db_main.o db_output.o d= b_print.o db_ps.o db_run.o db_script.o db_sym.o db_thread.o db_textdump.o = db_variables.o db_watch.o db_write_cmd.o aacraid.o aacraid_cam.o aacraid_= debug.o aacraid_pci.o OsdDebug.o OsdHardware.o OsdInterrupt.o OsdMemory.o = OsdSchedule.o OsdStream.o OsdSynch.o OsdTable.o acpi.o acpi_acad.o acpi_ba= ttery.o acpi_button.o acpi_cmbat.o acpi_cpu.o acpi_ec.o acpi_isab.o acpi_l= id.o acpi_package.o acpi_perf.o acpi_powerres.o acpi_quirk.o acpi_resourc= e.o acpi_container.o acpi_smbat.o acpi_thermal.o acpi_throttle.o adv_pci.o= advansys.o advlib.o advmcode.o adw_pci.o adwcam.o adwlib.o adwmcode.o if_= ae.o if_age.o agp.o agp_if.o ahci.o ahciem.o ahci_pci.o aic.o aic_pccard.o= ahc_isa.o ahc_pci.o ahd_pci.o aic7770.o aic79xx.o aic79xx_osm.o aic79xx_= pci.o aic79xx_reg_print.o aic7xxx.o aic7xxx_93cx6.o aic7xxx_osm.o aic7xxx_= pci.o aic7xxx_reg_print.o if_alc.o if_ale.o ata_if.o ata-all.o ata-dma.o a= ta-lowlevel.o ata-sata.o ata-card.o ata-isa.o ata-pci.o ata-acard.o ata-ac= erlabs.o ata-amd.o ata-ati.o ata-cenatek.o ata-cypress.o ata-cyrix.o ata-= highpoint.o ata-intel.o ata-ite.o ata-jmicron.o ata-marvell.o ata-micron.o= ata-national.o ata-netcell.o ata-nvidia.o ata-promise.o ata-serverworks.o= ata-siliconimage.o ata-sis.o ata-via.o if_ath_pci.o if_ath.o if_ath_alq.o= if_ath_beacon.o if_ath_btcoex.o if_ath_btcoex_mci.o if_ath_debug.o if_at= h_descdma.o if_ath_keycache.o if_ath_ioctl.o if_ath_led.o if_ath_lna_div.o= if_ath_tx.o if_ath_tx_edma.o if_ath_tx_ht.o if_ath_tdma.o if_ath_sysctl.o= if_ath_rx.o if_ath_rx_edma.o if_ath_spectral.o ah_osdep.o ah.o ah_eeprom= _v1.o ah_eeprom_v3.o ah_eeprom_v14.o ah_eeprom_v4k.o ah_eeprom_9287.o ah_r= egdomain.o ar5210_attach.o ar5210_beacon.o ar5210_interrupts.o ar5210_keyc= ache.o ar5210_misc.o ar5210_phy.o ar5210_power.o ar5210_recv.o ar5210_rese= t.o ar5210_xmit.o ar5211_attach.o ar5211_beacon.o ar5211_interrupts.o ar5= 211_keycache.o ar5211_misc.o ar5211_phy.o ar5211_power.o ar5211_recv.o ar5= 211_reset.o ar5211_xmit.o ar5212_ani.o ar5212_attach.o ar5212_beacon.o ar5= 212_eeprom.o ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o ar5212_mi= sc.o ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o ar5212_rfgai= n.o ar5212_xmit.o ar5416_ani.o ar5416_attach.o ar5416_beacon.o ar5416_btc= oex.o ar5416_cal.o ar5416_cal_iq.o ar5416_cal_adcgain.o ar5416_cal_adcdc.o= ar5416_eeprom.o ar5416_gpio.o ar5416_interrupts.o ar5416_keycache.o ar54= 16_misc.o ar5416_phy.o ar5416_power.o ar5416_radar.o ar5416_recv.o ar5416_= reset.o ar5416_spectral.o ar5416_xmit.o ar9160_attach.o ar9280_attach.o ar= 9280_olc.o ar9285_attach.o ar9285_btcoex.o ar9285_reset.o ar9285_cal.o ar9= 285_phy.o ar9285_diversity.o ar9287_attach.o ar9287_reset.o ar9287_cal.o = ar9287_olc.o ar9300_ani.o ar9300_attach.o ar9300_beacon.o ar9300_eeprom.o = ar9300_freebsd.o ar9300_gpio.o ar9300_interrupts.o ar9300_keycache.o ar930= 0_mci.o ar9300_misc.o ar9300_paprd.o ar9300_phy.o ar9300_power.o ar9300_ra= dar.o ar9300_radio.o ar9300_recv.o ar9300_recv_ds.o ar9300_reset.o ar9300= _stub.o ar9300_stub_funcs.o ar9300_spectral.o ar9300_timer.o ar9300_xmit.o= ar9300_xmit_ds.o ar2413.o ar2425.o ar5111.o ar5112.o ar5413.o ar2133.o ar= 9280.o ar9285.o ar9287.o sample.o dfs_null.o if_bce.o if_bfe.o if_bge.o bt= =2Eo bt_isa.o bt_pci.o cardbus.o cardbus_cis.o cardbus_device.o if_cas.o = ichss.o if_dc.o dcphy.o pnphy.o if_de.o if_em.o em_txrx.o igb_txrx.o e1000= _80003es2lan.o e1000_82540.o e1000_82541.o e1000_82542.o e1000_82543.o e10= 00_82571.o e1000_82575.o e1000_ich8lan.o e1000_i210.o e1000_api.o e1000_ma= c.o e1000_manage.o e1000_nvm.o e1000_phy.o e1000_vf.o e1000_mbx.o e1000_o= sdep.o if_et.o esp_pci.o ncr53c9x.o exca.o fbd.o fb_if.o splash.o if_fxp.o= inphy.o if_gem.o if_gem_pci.o if_hme.o if_hme_pci.o hptiop.o ichsmb.o ich= smb_pci.o if_ic.o iic.o iic_recover_bus.o iicbb.o iicbb_if.o iicbus.o iicb= us_if.o iiconf.o iicsmb.o intpm.o if_ipw.o isp.o isp_freebsd.o isp_librar= y.o isp_pci.o isp_target.o if_iwi.o if_iwn.o if_ix.o if_ixv.o ix_txrx.o ix= gbe_osdep.o ixgbe_phy.o ixgbe_api.o ixgbe_common.o ixgbe_mbx.o ixgbe_vf.o = ixgbe_82598.o ixgbe_82599.o ixgbe_x540.o ixgbe_x550.o ixgbe_dcb.o ixgbe_d= cb_82598.o ixgbe_dcb_82599.o if_jme.o kbd.o kbdmux.o am7990.o am79900.o if= _le_pci.o lance.o led.o if_lge.o if_malo.o if_malohal.o if_malo_pci.o md.o= memdev.o memutil.o mfi.o mfi_debug.o mfi_pci.o mfi_disk.o mfi_syspd.o mfi= _tbolt.o acphy.o amphy.o atphy.o axphy.o bmtphy.o brgphy.o ciphy.o e1000ph= y.o gentbi.o icsphy.o ip1000phy.o jmphy.o lxtphy.o mii.o mii_bitbang.o mi= i_physubr.o miibus_if.o mlphy.o nsgphy.o nsphy.o nsphyter.o pnaphy.o qsphy= =2Eo rdcphy.o rgephy.o rlphy.o smcphy.o smscphy.o tdkphy.o tlphy.o truephy= =2Eo ukphy.o ukphy_subr.o vscphy.o xmphy.o mmc_subr.o mmc.o mmcbr_if.o mmc= bus_if.o mmcsd.o mpr.o mpr_config.o mpr_mapping.o mpr_pci.o mpr_sas.o mpr= _sas_lsi.o mpr_table.o mpr_user.o mps.o mps_config.o mps_mapping.o mps_pci= =2Eo mps_sas.o mps_sas_lsi.o mps_table.o mps_user.o mpt.o mpt_cam.o mpt_de= bug.o mpt_pci.o mpt_raid.o mpt_user.o mrsas.o mrsas_cam.o mrsas_ioctl.o mr= sas_fp.o if_msk.o mvs.o mvs_if.o mvs_pci.o if_mwl.o if_mwl_pci.o mwlhal.o = if_ptnet.o netmap.o netmap_freebsd.o netmap_generic.o netmap_mbq.o netmap= _mem2.o netmap_monitor.o netmap_offloadings.o netmap_pipe.o netmap_pt.o ne= tmap_vale.o if_nge.o null.o card_if.o pccard.o pccard_cis.o pccard_cis_qui= rks.o pccard_device.o power_if.o pccbb.o pccbb_isa.o pccbb_pci.o pcf.o fi= xup_pci.o hostb_pci.o ignore_pci.o isa_pci.o pci.o pci_if.o pci_iov.o pci_= iov_if.o pci_iov_schema.o pci_pci.o pci_subr.o pci_user.o pcib_if.o pcib_s= upport.o vga_pci.o if_pcn.o agtiapi.o sadisc.o mpi.o saframe.o sahw.o sain= it.o saint.o sampicmd.o sampirsp.o saphy.o saport.o sasata.o sasmp.o sassp= =2Eo satimer.o sautil.o saioctlcmd.o mpidebug.o dminit.o dmsmp.o dmdisc.o = dmport.o dmtimer.o dmmisc.o sminit.o smmisc.o smsat.o smsatcb.o smsathw.o= smtimer.o tdinit.o tdmisc.o tdesgl.o tdport.o tdint.o tdioctl.o tdhw.o os= sacmnapi.o tddmcmnapi.o tdsmcmnapi.o tdtimers.o itdio.o itdcb.o itdinit.o = itddisc.o sat.o ossasat.o sathw.o lpt.o ppb_1284.o ppb_base.o ppb_msq.o pp= bconf.o ppbus_if.o ppi.o ppc.o ppc_acpi.o ppc_isa.o ppc_pci.o ppc_puc.o p= uc.o puc_cfg.o puc_pccard.o puc_pci.o pucdata.o rt2560.o rt2661.o rt2860.o= if_ral_pci.o random_infra.o random_harvestq.o randomdev.o fortuna.o hash.= o if_re.o if_rl.o sdhci.o sdhci_if.o sdhci_acpi.o sdhci_pci.o if_sf.o if_s= ge.o siis.o if_sis.o if_sk.o smb.o smbconf.o smbus.o smbus_if.o clone.o un= it.o sndbuf_dma.o cmi.o csa.o csapcm.o emu10kx.o emu10kx-pcm.o emu10kx-mi= di.o es137x.o ich.o via8233.o hdaa.o hdaa_patches.o hdac.o hdac_if.o hdacc= =2Eo ac97.o ac97_if.o ac97_patch.o buffer.o channel.o channel_if.o dsp.o f= eeder.o feeder_chain.o feeder_eq.o feeder_if.o feeder_format.o feeder_matr= ix.o feeder_mixer.o feeder_rate.o feeder_volume.o mixer.o mixer_if.o sndst= at.o sound.o vchan.o midi.o mpu401.o mpu_if.o mpufoi_if.o sequencer.o syn= th_if.o if_ste.o if_stge.o sym_hipd.o schistory.o scmouse.o scterm.o scvid= ctl.o syscons.o sysmouse.o if_ti.o if_tl.o trm.o tws.o tws_cam.o tws_hdm.o= tws_services.o tws_user.o if_tx.o if_txp.o uart_bus_acpi.o uart_bus_isa.o= uart_bus_pccard.o uart_bus_pci.o uart_bus_puc.o uart_core.o uart_dbg.o u= art_dev_ns8250.o uart_if.o uart_subr.o uart_tty.o ehci.o ehci_pci.o ohci.o= ohci_pci.o uhci.o uhci_pci.o xhci.o xhci_pci.o usb_controller.o umass.o u= sb_busdma.o usb_core.o usb_debug.o usb_dev.o usb_device.o usb_dynamic.o us= b_error.o usb_generic.o usb_handle_request.o usb_hid.o usb_hub.o usb_if.o = usb_lookup.o usb_mbuf.o usb_msctest.o usb_parse.o usb_pf.o usb_process.o = usb_request.o usb_transfer.o usb_util.o ukbd.o usb_quirk.o if_vge.o virtio= =2Eo virtqueue.o virtio_bus_if.o virtio_if.o virtio_pci.o if_vtnet.o virti= o_blk.o virtio_balloon.o virtio_scsi.o if_vr.o vt_termcolors.o vt_font_def= ault.o vt_mouse_cursor.o efifb.o vt_fb.o vt_vga.o logo_freebsd.o logo_bea= stie.o vt_buf.o vt_consolectl.o vt_core.o vt_cpulogos.o vt_font.o vt_sysmo= use.o if_vx.o if_vx_pci.o watchdog.o if_wb.o if_wpi.o balloon.o blkfront.o= blkback.o xen_console.o control.o grant_table.o netback.o netfront.o xenp= ci.o timer.o pvcpu.o xenstore.o xenstore_dev.o xenstored_dev.o evtchn_dev.= o privcmd.o gntdev.o debug.o if_xl.o xlphy.o dead_vnops.o devfs_devs.o de= vfs_dir.o devfs_rule.o devfs_vfsops.o devfs_vnops.o fifo_vnops.o msdosfs_c= onv.o msdosfs_denode.o msdosfs_fat.o msdosfs_lookup.o msdosfs_vfsops.o msd= osfs_vnops.o nfs_commonkrpc.o nfs_commonsubs.o nfs_commonport.o nfs_commo= nacl.o nfs_clcomsubs.o nfs_clsubs.o nfs_clstate.o nfs_clkrpc.o nfs_clrpcop= s.o nfs_clvnops.o nfs_clnode.o nfs_clvfsops.o nfs_clport.o nfs_clbio.o nfs= _clnfsiod.o nfs_fha_new.o nfs_nfsdsocket.o nfs_nfsdsubs.o nfs_nfsdstate.o = nfs_nfsdkrpc.o nfs_nfsdserv.o nfs_nfsdport.o nfs_nfsdcache.o procfs.o pro= cfs_dbregs.o procfs_fpregs.o procfs_ioctl.o procfs_map.o procfs_mem.o proc= fs_note.o procfs_osrel.o procfs_regs.o procfs_rlimit.o procfs_status.o pro= cfs_type.o pseudofs.o pseudofs_fileno.o pseudofs_vncache.o pseudofs_vnops.= o gdb_cons.o gdb_main.o gdb_packet.o geom_bsd_enc.o geom_ctl.o geom_dev.o= geom_disk.o geom_dump.o geom_event.o geom_flashmap.o geom_io.o geom_kern.= o geom_slice.o geom_subr.o geom_vfs.o g_label.o g_label_ext2fs.o g_label_i= so9660.o g_label_msdosfs.o g_label_ntfs.o g_label_reiserfs.o g_label_ufs.o= g_label_gpt.o g_label_disk_ident.o g_part.o g_part_if.o g_part_bsd.o g_p= art_ebr.o g_part_gpt.o g_part_mbr.o g_raid.o g_raid_ctl.o g_raid_md_if.o g= _raid_tr_if.o md_ddf.o md_intel.o md_jmicron.o md_nvidia.o md_promise.o md= _sii.o tr_concat.o tr_raid0.o tr_raid1.o tr_raid1e.o tr_raid5.o isa_if.o i= sa_common.o isahint.o cd9660_bmap.o cd9660_lookup.o cd9660_node.o cd9660_= rrip.o cd9660_util.o cd9660_vfsops.o cd9660_vnops.o bus_if.o clock_if.o cp= ufreq_if.o device_if.o imgact_elf.o imgact_elf32.o imgact_shell.o init_mai= n.o init_sysent.o ksched.o kern_acct.o kern_clock.o kern_condvar.o kern_co= nf.o kern_cons.o kern_cpu.o kern_cpuset.o kern_context.o kern_descrip.o k= ern_dtrace.o kern_dump.o kern_environment.o kern_et.o kern_event.o kern_ex= ec.o kern_exit.o kern_fail.o kern_ffclock.o kern_fork.o kern_hhook.o kern_= idle.o kern_intr.o kern_jail.o kern_khelp.o kern_kthread.o kern_ktrace.o k= ern_linker.o kern_lock.o kern_lockf.o kern_lockstat.o kern_loginclass.o k= ern_malloc.o kern_mbuf.o kern_mib.o kern_module.o kern_mtxpool.o kern_mute= x.o kern_ntptime.o kern_numa.o kern_osd.o kern_physio.o kern_pmc.o kern_pr= iv.o kern_proc.o kern_procctl.o kern_prot.o kern_racct.o kern_rangelock.o = kern_rctl.o kern_resource.o kern_rmlock.o kern_rwlock.o kern_sdt.o kern_s= ema.o kern_sendfile.o kern_sharedpage.o kern_shutdown.o kern_sig.o kern_sw= itch.o kern_sx.o kern_synch.o kern_syscalls.o kern_sysctl.o kern_tc.o kern= _thr.o kern_thread.o kern_time.o kern_timeout.o kern_umtx.o kern_uuid.o ke= rn_xxx.o link_elf.o linker_if.o md5c.o p1003_1b.o posix4_mib.o sched_ule.= o serdev_if.o stack_protector.o subr_acl_nfs4.o subr_acl_posix1e.o subr_au= toconf.o subr_blist.o subr_bus.o subr_bus_dma.o subr_bufring.o subr_capabi= lity.o subr_clock.o subr_counter.o subr_devstat.o subr_disk.o subr_eventha= ndler.o subr_fattime.o subr_firmware.o subr_gtaskqueue.o subr_hash.o subr= _hints.o subr_kdb.o subr_kobj.o subr_lock.o subr_log.o subr_module.o subr_= msgbuf.o subr_param.o subr_pcpu.o subr_pctrie.o subr_power.o subr_prf.o su= br_prof.o subr_rman.o subr_rtc.o subr_sbuf.o subr_scanf.o subr_sglist.o s= ubr_sleepqueue.o subr_smp.o subr_stack.o subr_taskqueue.o subr_terminal.o = subr_trap.o subr_turnstile.o subr_uio.o subr_unit.o subr_vmem.o subr_witne= ss.o sys_capability.o sys_generic.o sys_pipe.o sys_procdesc.o sys_process.= o sys_socket.o syscalls.o sysv_ipc.o sysv_msg.o sysv_sem.o sysv_shm.o tty= =2Eo tty_info.o tty_inq.o tty_outq.o tty_pts.o tty_tty.o tty_ttydisc.o uip= c_accf.o uipc_debug.o uipc_domain.o uipc_mbuf.o uipc_mbuf2.o uipc_mbufhash= =2Eo uipc_shm.o uipc_sockbuf.o uipc_socket.o uipc_syscalls.o uipc_usrreq.o= vfs_acl.o vfs_aio.o vfs_bio.o vfs_cache.o vfs_cluster.o vfs_default.o vf= s_export.o vfs_extattr.o vfs_hash.o vfs_init.o vfs_lookup.o vfs_mount.o vf= s_mountroot.o vfs_subr.o vfs_syscalls.o vfs_vnops.o arc4random.o chacha.o = asprintf.o bcd.o bsearch.o crc32.o explicit_bzero.o fnmatch.o inet_aton.o = inet_ntoa.o inet_ntop.o inet_pton.o jenkins_hash.o murmur3_32.o memcchr.o= memchr.o memcmp.o memmem.o qsort.o qsort_r.o random.o scanc.o strcasecmp.= o strcat.o strchr.o strcmp.o strcpy.o strcspn.o strdup.o strndup.o strlcat= =2Eo strlcpy.o strlen.o strncat.o strncmp.o strncpy.o strnlen.o strrchr.o = strsep.o strspn.o strstr.o strtol.o strtoq.o strtoul.o strtouq.o strvalid= =2Eo timingsafe_bcmp.o zlib.o bpf.o bpf_buffer.o bpf_filter.o bpf_zerocopy= =2Eo if.o if_clone.o if_dead.o if_debug.o if_ethersubr.o if_gif.o if_ipsec= =2Eo if_loop.o if_llatbl.o if_media.o if_mib.o if_tun.o if_vlan.o ifdi_if.= o iflib.o mp_ring.o netisr.o pfil.o radix.o radix_mpath.o raw_cb.o raw_us= rreq.o route.o rtsock.o ieee80211.o ieee80211_action.o ieee80211_ageq.o ie= ee80211_adhoc.o ieee80211_amrr.o ieee80211_crypto.o ieee80211_crypto_ccmp.= o ieee80211_crypto_none.o ieee80211_crypto_tkip.o ieee80211_crypto_wep.o = ieee80211_ddb.o ieee80211_dfs.o ieee80211_freebsd.o ieee80211_hostap.o iee= e80211_ht.o ieee80211_hwmp.o ieee80211_input.o ieee80211_ioctl.o ieee8021= 1_mesh.o ieee80211_monitor.o ieee80211_node.o ieee80211_output.o ieee80211= _phy.o ieee80211_power.o ieee80211_proto.o ieee80211_radiotap.o ieee80211_= ratectl.o ieee80211_ratectl_none.o ieee80211_regdomain.o ieee80211_scan.o = ieee80211_scan_sta.o ieee80211_sta.o ieee80211_scan_sw.o ieee80211_vht.o = ieee80211_wds.o accf_data.o accf_http.o if_ether.o igmp.o in.o in_debug.o = in_kdtrace.o in_fib.o in_gif.o ip_id.o in_jail.o in_mcast.o in_pcb.o in_pr= ot.o in_proto.o in_rmx.o ip_divert.o ip_ecn.o ip_encap.o ip_fastfwd.o ip_i= cmp.o ip_input.o ip_options.o ip_output.o ip_reass.o raw_ip.o cc.o cc_new= reno.o sctp_asconf.o sctp_auth.o sctp_bsd_addr.o sctp_cc_functions.o sctp_= crc32.o sctp_indata.o sctp_input.o sctp_output.o sctp_pcb.o sctp_peeloff.o= sctp_ss_functions.o sctp_syscalls.o sctp_sysctl.o sctp_timer.o sctp_usrre= q.o sctputil.o tcp_hostcache.o tcp_input.o tcp_lro.o tcp_output.o tcp_off= load.o tcp_reass.o tcp_sack.o tcp_subr.o tcp_syncache.o tcp_timer.o tcp_ti= mewait.o tcp_usrreq.o udp_usrreq.o alias.o alias_db.o alias_mod.o alias_pr= oxy.o alias_util.o alias_sctp.o dest6.o frag6.o icmp6.o in6.o in6_cksum.o = in6_fib.o in6_gif.o in6_ifattach.o in6_jail.o in6_mcast.o in6_pcb.o in6_pr= oto.o in6_rmx.o in6_src.o ip6_fastfwd.o ip6_forward.o ip6_id.o ip6_input.= o ip6_output.o mld6.o nd6.o nd6_nbr.o nd6_rtr.o raw_ip6.o route6.o scope6.= o sctp6_usrreq.o udp6_usrreq.o ipsec.o ipsec_input.o ipsec_mbuf.o ipsec_mo= d.o ipsec_output.o ipsec_pcb.o key.o key_debug.o keysock.o subr_ipsec.o ud= pencap.o xform_ah.o xform_esp.o xform_ipcomp.o dn_aqm_codel.o dn_aqm_pie.= o dn_heap.o dn_sched_fifo.o dn_sched_fq_codel.o dn_sched_fq_pie.o dn_sched= _prio.o dn_sched_qfq.o dn_sched_rr.o dn_sched_wf2q.o ip_dummynet.o ip_dn_i= o.o ip_dn_glue.o ip_fw2.o ip_fw_bpf.o ip_fw_dynamic.o ip_fw_eaction.o ip_f= w_log.o ip_fw_pfil.o ip_fw_sockopt.o ip_fw_table.o ip_fw_table_algo.o ip_= fw_table_value.o ip_fw_iface.o nfs_diskless.o nfs_fha.o nfs_lock.o nfs_nfs= svc.o nlm_advlock.o nlm_prot_clnt.o nlm_prot_impl.o nlm_prot_server.o nlm_= prot_svc.o nlm_prot_xdr.o sm_inter_xdr.o cast.o criov.o crypto.o cryptodev= _if.o cryptosoft.o cryptodeflate.o gmac.o gfmult.o rmd160.o skipjack.o xf= orm.o auth_none.o auth_unix.o authunix_prot.o clnt_bck.o clnt_dg.o clnt_rc= =2Eo clnt_vc.o getnetconfig.o replay.o rpc_callmsg.o rpc_generic.o rpc_pro= t.o rpcb_clnt.o rpcb_prot.o svc.o svc_auth.o svc_auth_unix.o svc_dg.o svc_= generic.o svc_vc.o audit.o audit_arg.o audit_bsm.o audit_bsm_db.o audit_bs= m_klib.o audit_pipe.o audit_syscalls.o audit_trigger.o audit_worker.o bsm= _domain.o bsm_errno.o bsm_fcntl.o bsm_socket_type.o bsm_token.o mac_audit.= o mac_cred.o mac_framework.o mac_inet.o mac_inet6.o mac_label.o mac_net.o = mac_pipe.o mac_posix_sem.o mac_posix_shm.o mac_priv.o mac_process.o mac_so= cket.o mac_syscalls.o mac_system.o mac_sysv_msg.o mac_sysv_sem.o mac_sysv= _shm.o mac_vfs.o teken.o ffs_alloc.o ffs_balloc.o ffs_inode.o ffs_snapshot= =2Eo ffs_softdep.o ffs_subr.o ffs_tables.o ffs_vfsops.o ffs_vnops.o ffs_su= spend.o ufs_acl.o ufs_bmap.o ufs_dirhash.o ufs_extattr.o ufs_gjournal.o uf= s_inode.o ufs_lookup.o ufs_quota.o ufs_vfsops.o ufs_vnops.o default_pager= =2Eo device_pager.o phys_pager.o redzone.o sg_pager.o swap_pager.o uma_cor= e.o uma_dbg.o memguard.o vm_fault.o vm_glue.o vm_init.o vm_kern.o vm_map.o= vm_meter.o vm_mmap.o vm_object.o vm_page.o vm_pageout.o vm_pager.o vm_phy= s.o vm_radix.o vm_reserv.o vm_domain.o vm_unix.o vnode_pager.o features.o= xenbus_if.o xenbus.o xenbusb_if.o xenbusb.o xenbusb_front.o xenbusb_back.= o xenmem_if.o xdr.o xdr_array.o xdr_mbuf.o xdr_mem.o xdr_reference.o xdr_s= izeof.o hptnr_lib.o hptrr_lib.o acpi_machdep.o atomic.o bios.o cpu_switch.= o db_disasm.o db_interface.o db_trace.o elf_machdep.o exception.o fpu.o g= db_machdep.o in_cksum.o initcpu.o io.o xen-locore.o machdep.o mem.o minidu= mp_machdep.o mp_machdep.o mpboot.o pmap.o ptrace_machdep.o sigtramp.o supp= ort.o sys_machdep.o trap.o uio_machdep.o uma_machdep.o vm_machdep.o pci_cf= greg.o bf_enc.o des_enc.o acpi_if.o acpi_hpet.o acpi_pci.o acpi_pci_link.o= acpi_pcib.o acpi_pcib_acpi.o acpi_pcib_pci.o acpi_timer.o acpi_wmi_if.o = agp_amd64.o agp_i810.o agp_via.o atkbd.o atkbd_atkbdc.o atkbdc.o atkbdc_is= a.o atkbdc_subr.o psm.o bxe.o bxe_stats.o bxe_debug.o ecore_sp.o bxe_elink= =2Eo 57710_init_values.o 57711_init_values.o 57712_init_values.o fb.o ves= a.o vga.o iodev.o if_ixl.o ixl_pf_main.o ixl_pf_qmgr.o ixl_pf_iov.o ixl_pf= _i2c.o ixl_iw.o if_ixlv.o ixlvc.o ixl_txrx.o i40e_osdep.o i40e_lan_hmc.o i= 40e_hmc.o i40e_common.o i40e_nvm.o i40e_adminq.o fdc.o fdc_acpi.o fdc_isa.= o fdc_pccard.o hptnr_os_bsd.o hptnr_osm_bsd.o hptnr_config.o hptrr_os_bsd.= o hptrr_osm_bsd.o hptrr_config.o hv_kbd.o hv_kbdc.o vmbus_pcib.o hn_nvs.o= hn_rndis.o if_hn.o hv_storvsc_drv_freebsd.o hv_kvp.o hv_snapshot.o vmbus_= heartbeat.o vmbus_ic.o vmbus_shutdown.o vmbus_timesync.o hyperv.o hyperv_b= usdma.o vmbus.o vmbus_br.o vmbus_chan.o vmbus_et.o vmbus_if.o vmbus_res.o = vmbus_xact.o hyperv_machdep.o vmbus_vector.o if_nfe.o nvd.o nvme.o nvme_c= trlr.o nvme_ctrlr_cmd.o nvme_ns.o nvme_ns_cmd.o nvme_qpair.o nvme_sysctl.o= nvme_test.o nvme_util.o ivy.o nehemiah.o spkr.o scterm-teken.o scvesactl.= o scvgarndr.o scvtb.o uart_cpu_x86.o if_vmx.o xen_acpi_pci.o xen_pci.o isc= i.o isci_controller.o isci_domain.o isci_interrupt.o isci_io_request.o is= ci_logger.o isci_oem_parameters.o isci_remote_device.o isci_sysctl.o isci_= task_request.o isci_timer.o sati.o sati_abort_task_set.o sati_atapi.o sat= i_device.o sati_inquiry.o sati_log_sense.o sati_lun_reset.o sati_mode_page= s.o sati_mode_select.o sati_mode_sense.o sati_mode_sense_10.o sati_mode_se= nse_6.o sati_move.o sati_passthrough.o sati_read.o sati_read_buffer.o sat= i_read_capacity.o sati_reassign_blocks.o sati_report_luns.o sati_request_s= ense.o sati_start_stop_unit.o sati_synchronize_cache.o sati_test_unit_read= y.o sati_unmap.o sati_util.o sati_verify.o sati_write.o sati_write_and_ver= ify.o sati_write_buffer.o sati_write_long.o sci_abstract_list.o sci_base_= controller.o sci_base_domain.o sci_base_iterator.o sci_base_library.o sci_= base_logger.o sci_base_memory_descriptor_list.o sci_base_memory_descripto= r_list_decorator.o sci_base_object.o sci_base_observer.o sci_base_phy.o sc= i_base_port.o sci_base_remote_device.o sci_base_request.o sci_base_state_= machine.o sci_base_state_machine_logger.o sci_base_state_machine_observer.= o sci_base_subject.o sci_util.o scic_sds_controller.o scic_sds_library.o s= cic_sds_pci.o scic_sds_phy.o scic_sds_port.o scic_sds_port_configuration_= agent.o scic_sds_remote_device.o scic_sds_remote_node_context.o scic_sds_r= emote_node_table.o scic_sds_request.o scic_sds_sgpio.o scic_sds_smp_remote= _device.o scic_sds_smp_request.o scic_sds_ssp_request.o scic_sds_stp_pack= et_request.o scic_sds_stp_remote_device.o scic_sds_stp_request.o scic_sds_= unsolicited_frame_control.o scif_sas_controller.o scif_sas_controller_stat= e_handlers.o scif_sas_controller_states.o scif_sas_domain.o scif_sas_doma= in_state_handlers.o scif_sas_domain_states.o scif_sas_high_priority_reques= t_queue.o scif_sas_internal_io_request.o scif_sas_io_request.o scif_sas_i= o_request_state_handlers.o scif_sas_io_request_states.o scif_sas_library.o= scif_sas_remote_device.o scif_sas_remote_device_ready_substate_handlers.= o scif_sas_remote_device_ready_substates.o scif_sas_remote_device_startin= g_substate_handlers.o scif_sas_remote_device_starting_substates.o scif_sa= s_remote_device_state_handlers.o scif_sas_remote_device_states.o scif_sas_= request.o scif_sas_smp_activity_clear_affiliation.o scif_sas_smp_io_reque= st.o scif_sas_smp_phy.o scif_sas_smp_remote_device.o scif_sas_stp_io_reque= st.o scif_sas_stp_remote_device.o scif_sas_stp_task_request.o scif_sas_ta= sk_request.o scif_sas_task_request_state_handlers.o scif_sas_task_request_= states.o scif_sas_timer.o syscons_isa.o vga_isa.o kern_clocksource.o link_= elf_obj.o crc32_sse42.o memmove.o memset.o ia32_reg.o ia32_signal.o ia32_s= igtramp.o ia32_syscall.o ia32_misc.o ia32_sysvec.o x86bios.o x86emu.o Osd= Environment.o acpi_apm.o acpi_wakeup.o madt.o srat.o powernow.o est.o hwps= tate.o p4tcc.o busdma_dmar.o intel_ctx.o intel_drv.o intel_fault.o intel_g= as.o intel_idpgtbl.o intel_intrmap.o intel_qi.o intel_quirks.o intel_utils= =2Eo atrtc.o clock.o isa.o isa_dma.o nmi.o orm.o pci_bus.o qpi.o autoconf.= o bus_machdep.o busdma_bounce.o busdma_machdep.o cpu_machdep.o dump_machd= ep.o identcpu.o intr_machdep.o io_apic.o legacy.o local_apic.o mca.o x86_m= em.o mp_x86.o msi.o nexus.o pvclock.o stack_machdep.o tsc.o delay.o hvm.o = xen_intr.o pv.o pvcpu_enum.o xen_apic.o xenpv.o xen_nexus.o xen_msi.o xen_= pci_bus.o config.o env.o hints.o vnode_if.o hack.pico vers.o; @echo ctfmerg= e -L VERSION -g -o kernel.full ...; @ctfmerge -L VERSION -g -o kernel.full = locore.o cam.o cam_compat.o cam_iosched.o cam_periph.o cam_queue.o cam_si= m.o cam_xpt.o ata_all.o ata_xpt.o ata_pmp.o scsi_xpt.o scsi_all.o scsi_cd.= o scsi_ch.o ata_da.o scsi_da.o scsi_pass.o scsi_sa.o scsi_enc.o scsi_enc_s= es.o scsi_enc_safte.o smp_all.o freebsd32_capability.o freebsd32_ioctl.o f= reebsd32_misc.o freebsd32_syscalls.o freebsd32_sysent.o ck_array.o ck_bar= rier_centralized.o ck_barrier_combining.o ck_barrier_dissemination.o ck_ba= rrier_mcs.o ck_barrier_tournament.o ck_epoch.o ck_hp.o ck_hs.o ck_ht.o ck= _rhs.o dsargs.o dscontrol.o dsdebug.o dsfield.o dsinit.o dsmethod.o dsmthd= at.o dsobject.o dsopcode.o dsutils.o dswexec.o dswload.o dswload2.o dswsco= pe.o dswstate.o evevent.o evglock.o evgpe.o evgpeblk.o evgpeinit.o evgpeut= il.o evhandler.o evmisc.o evregion.o evrgnini.o evsci.o evxface.o evxfevnt= =2Eo evxfgpe.o evxfregn.o exconcat.o exconfig.o exconvrt.o excreate.o exde= bug.o exdump.o exfield.o exfldio.o exmisc.o exmutex.o exnames.o exoparg1.= o exoparg2.o exoparg3.o exoparg6.o exprep.o exregion.o exresnte.o exresolv= =2Eo exresop.o exstore.o exstoren.o exstorob.o exsystem.o extrace.o exutil= s.o hwacpi.o hwesleep.o hwgpe.o hwpci.o hwregs.o hwsleep.o hwtimer.o hwval= id.o hwxface.o hwxfsleep.o nsaccess.o nsalloc.o nsarguments.o nsconvert.o = nsdump.o nseval.o nsinit.o nsload.o nsnames.o nsobject.o nsparse.o nspred= ef.o nsprepkg.o nsrepair.o nsrepair2.o nssearch.o nsutils.o nswalk.o nsxfe= val.o nsxfname.o nsxfobj.o psargs.o psloop.o psobject.o psopcode.o psopinf= o.o psparse.o psscope.o pstree.o psutils.o pswalk.o psxface.o rsaddr.o rs= calc.o rscreate.o rsdumpinfo.o rsinfo.o rsio.o rsirq.o rslist.o rsmemory.o= rsmisc.o rsserial.o rsutils.o rsxface.o tbdata.o tbfadt.o tbfind.o tbinst= al.o tbprint.o tbutils.o tbxface.o tbxfload.o tbxfroot.o utaddress.o utall= oc.o utascii.o utbuffer.o utcache.o utcopy.o utdebug.o utdecode.o utdelete= =2Eo uterror.o uteval.o utexcep.o utglobal.o uthex.o utids.o utinit.o utl= ock.o utmath.o utmisc.o utmutex.o utnonansi.o utobject.o utosi.o utownerid= =2Eo utpredef.o utresrc.o utstate.o utstring.o utstrtoul64.o utxface.o utx= ferror.o utxfinit.o cnvlist.o dnvlist.o nvlist.o nvpair.o bf_ecb.o bf_skey= =2Eo camellia.o camellia-api.o des_ecb.o des_setkey.o rijndael-alg-fst.o = rijndael-api-fst.o rijndael-api.o sha1.o sha256c.o sha512c.o skein.o skein= _block.o siphash.o siphash_test.o db_access.o db_break.o db_capture.o db_c= ommand.o db_examine.o db_expr.o db_input.o db_lex.o db_main.o db_output.o = db_print.o db_ps.o db_run.o db_script.o db_sym.o db_thread.o db_textdump.o= db_variables.o db_watch.o db_write_cmd.o aacraid.o aacraid_cam.o aacraid= _debug.o aacraid_pci.o OsdDebug.o OsdHardware.o OsdInterrupt.o OsdMemory.o= OsdSchedule.o OsdStream.o OsdSynch.o OsdTable.o acpi.o acpi_acad.o acpi_b= attery.o acpi_button.o acpi_cmbat.o acpi_cpu.o acpi_ec.o acpi_isab.o acpi_= lid.o acpi_package.o acpi_perf.o acpi_powerres.o acpi_quirk.o acpi_resour= ce.o acpi_container.o acpi_smbat.o acpi_thermal.o acpi_throttle.o adv_pci.= o advansys.o advlib.o advmcode.o adw_pci.o adwcam.o adwlib.o adwmcode.o if= _ae.o if_age.o agp.o agp_if.o ahci.o ahciem.o ahci_pci.o aic.o aic_pccard.= o ahc_isa.o ahc_pci.o ahd_pci.o aic7770.o aic79xx.o aic79xx_osm.o aic79xx= _pci.o aic79xx_reg_print.o aic7xxx.o aic7xxx_93cx6.o aic7xxx_osm.o aic7xxx= _pci.o aic7xxx_reg_print.o if_alc.o if_ale.o ata_if.o ata-all.o ata-dma.o = ata-lowlevel.o ata-sata.o ata-card.o ata-isa.o ata-pci.o ata-acard.o ata-a= cerlabs.o ata-amd.o ata-ati.o ata-cenatek.o ata-cypress.o ata-cyrix.o ata= -highpoint.o ata-intel.o ata-ite.o ata-jmicron.o ata-marvell.o ata-micron.= o ata-national.o ata-netcell.o ata-nvidia.o ata-promise.o ata-serverworks.= o ata-siliconimage.o ata-sis.o ata-via.o if_ath_pci.o if_ath.o if_ath_alq.= o if_ath_beacon.o if_ath_btcoex.o if_ath_btcoex_mci.o if_ath_debug.o if_a= th_descdma.o if_ath_keycache.o if_ath_ioctl.o if_ath_led.o if_ath_lna_div.= o if_ath_tx.o if_ath_tx_edma.o if_ath_tx_ht.o if_ath_tdma.o if_ath_sysctl.= o if_ath_rx.o if_ath_rx_edma.o if_ath_spectral.o ah_osdep.o ah.o ah_eepro= m_v1.o ah_eeprom_v3.o ah_eeprom_v14.o ah_eeprom_v4k.o ah_eeprom_9287.o ah_= regdomain.o ar5210_attach.o ar5210_beacon.o ar5210_interrupts.o ar5210_key= cache.o ar5210_misc.o ar5210_phy.o ar5210_power.o ar5210_recv.o ar5210_res= et.o ar5210_xmit.o ar5211_attach.o ar5211_beacon.o ar5211_interrupts.o ar= 5211_keycache.o ar5211_misc.o ar5211_phy.o ar5211_power.o ar5211_recv.o ar= 5211_reset.o ar5211_xmit.o ar5212_ani.o ar5212_attach.o ar5212_beacon.o ar= 5212_eeprom.o ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o ar5212_m= isc.o ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o ar5212_rfga= in.o ar5212_xmit.o ar5416_ani.o ar5416_attach.o ar5416_beacon.o ar5416_bt= coex.o ar5416_cal.o ar5416_cal_iq.o ar5416_cal_adcgain.o ar5416_cal_adcdc.= o ar5416_eeprom.o ar5416_gpio.o ar5416_interrupts.o ar5416_keycache.o ar5= 416_misc.o ar5416_phy.o ar5416_power.o ar5416_radar.o ar5416_recv.o ar5416= _reset.o ar5416_spectral.o ar5416_xmit.o ar9160_attach.o ar9280_attach.o a= r9280_olc.o ar9285_attach.o ar9285_btcoex.o ar9285_reset.o ar9285_cal.o ar= 9285_phy.o ar9285_diversity.o ar9287_attach.o ar9287_reset.o ar9287_cal.o = ar9287_olc.o ar9300_ani.o ar9300_attach.o ar9300_beacon.o ar9300_eeprom.o= ar9300_freebsd.o ar9300_gpio.o ar9300_interrupts.o ar9300_keycache.o ar93= 00_mci.o ar9300_misc.o ar9300_paprd.o ar9300_phy.o ar9300_power.o ar9300_r= adar.o ar9300_radio.o ar9300_recv.o ar9300_recv_ds.o ar9300_reset.o ar930= 0_stub.o ar9300_stub_funcs.o ar9300_spectral.o ar9300_timer.o ar9300_xmit.= o ar9300_xmit_ds.o ar2413.o ar2425.o ar5111.o ar5112.o ar5413.o ar2133.o a= r9280.o ar9285.o ar9287.o sample.o dfs_null.o if_bce.o if_bfe.o if_bge.o b= t.o bt_isa.o bt_pci.o cardbus.o cardbus_cis.o cardbus_device.o if_cas.o i= chss.o if_dc.o dcphy.o pnphy.o if_de.o if_em.o em_txrx.o igb_txrx.o e1000_= 80003es2lan.o e1000_82540.o e1000_82541.o e1000_82542.o e1000_82543.o e100= 0_82571.o e1000_82575.o e1000_ich8lan.o e1000_i210.o e1000_api.o e1000_mac= =2Eo e1000_manage.o e1000_nvm.o e1000_phy.o e1000_vf.o e1000_mbx.o e1000_= osdep.o if_et.o esp_pci.o ncr53c9x.o exca.o fbd.o fb_if.o splash.o if_fxp.= o inphy.o if_gem.o if_gem_pci.o if_hme.o if_hme_pci.o hptiop.o ichsmb.o ic= hsmb_pci.o if_ic.o iic.o iic_recover_bus.o iicbb.o iicbb_if.o iicbus.o iic= bus_if.o iiconf.o iicsmb.o intpm.o if_ipw.o isp.o isp_freebsd.o isp_libra= ry.o isp_pci.o isp_target.o if_iwi.o if_iwn.o if_ix.o if_ixv.o ix_txrx.o i= xgbe_osdep.o ixgbe_phy.o ixgbe_api.o ixgbe_common.o ixgbe_mbx.o ixgbe_vf.o= ixgbe_82598.o ixgbe_82599.o ixgbe_x540.o ixgbe_x550.o ixgbe_dcb.o ixgbe_= dcb_82598.o ixgbe_dcb_82599.o if_jme.o kbd.o kbdmux.o am7990.o am79900.o i= f_le_pci.o lance.o led.o if_lge.o if_malo.o if_malohal.o if_malo_pci.o md.= o memdev.o memutil.o mfi.o mfi_debug.o mfi_pci.o mfi_disk.o mfi_syspd.o mf= i_tbolt.o acphy.o amphy.o atphy.o axphy.o bmtphy.o brgphy.o ciphy.o e1000p= hy.o gentbi.o icsphy.o ip1000phy.o jmphy.o lxtphy.o mii.o mii_bitbang.o m= ii_physubr.o miibus_if.o mlphy.o nsgphy.o nsphy.o nsphyter.o pnaphy.o qsph= y.o rdcphy.o rgephy.o rlphy.o smcphy.o smscphy.o tdkphy.o tlphy.o truephy.= o ukphy.o ukphy_subr.o vscphy.o xmphy.o mmc_subr.o mmc.o mmcbr_if.o mmcbus= _if.o mmcsd.o mpr.o mpr_config.o mpr_mapping.o mpr_pci.o mpr_sas.o mpr_sa= s_lsi.o mpr_table.o mpr_user.o mps.o mps_config.o mps_mapping.o mps_pci.o = mps_sas.o mps_sas_lsi.o mps_table.o mps_user.o mpt.o mpt_cam.o mpt_debug.o= mpt_pci.o mpt_raid.o mpt_user.o mrsas.o mrsas_cam.o mrsas_ioctl.o mrsas_f= p.o if_msk.o mvs.o mvs_if.o mvs_pci.o if_mwl.o if_mwl_pci.o mwlhal.o if_p= tnet.o netmap.o netmap_freebsd.o netmap_generic.o netmap_mbq.o netmap_mem2= =2Eo netmap_monitor.o netmap_offloadings.o netmap_pipe.o netmap_pt.o netma= p_vale.o if_nge.o null.o card_if.o pccard.o pccard_cis.o pccard_cis_quirks= =2Eo pccard_device.o power_if.o pccbb.o pccbb_isa.o pccbb_pci.o pcf.o fix= up_pci.o hostb_pci.o ignore_pci.o isa_pci.o pci.o pci_if.o pci_iov.o pci_i= ov_if.o pci_iov_schema.o pci_pci.o pci_subr.o pci_user.o pcib_if.o pcib_su= pport.o vga_pci.o if_pcn.o agtiapi.o sadisc.o mpi.o saframe.o sahw.o saini= t.o saint.o sampicmd.o sampirsp.o saphy.o saport.o sasata.o sasmp.o sassp.= o satimer.o sautil.o saioctlcmd.o mpidebug.o dminit.o dmsmp.o dmdisc.o dm= port.o dmtimer.o dmmisc.o sminit.o smmisc.o smsat.o smsatcb.o smsathw.o sm= timer.o tdinit.o tdmisc.o tdesgl.o tdport.o tdint.o tdioctl.o tdhw.o ossac= mnapi.o tddmcmnapi.o tdsmcmnapi.o tdtimers.o itdio.o itdcb.o itdinit.o itd= disc.o sat.o ossasat.o sathw.o lpt.o ppb_1284.o ppb_base.o ppb_msq.o ppbco= nf.o ppbus_if.o ppi.o ppc.o ppc_acpi.o ppc_isa.o ppc_pci.o ppc_puc.o puc.= o puc_cfg.o puc_pccard.o puc_pci.o pucdata.o rt2560.o rt2661.o rt2860.o if= _ral_pci.o random_infra.o random_harvestq.o randomdev.o fortuna.o hash.o i= f_re.o if_rl.o sdhci.o sdhci_if.o sdhci_acpi.o sdhci_pci.o if_sf.o if_sge.= o siis.o if_sis.o if_sk.o smb.o smbconf.o smbus.o smbus_if.o clone.o unit.= o sndbuf_dma.o cmi.o csa.o csapcm.o emu10kx.o emu10kx-pcm.o emu10kx-midi.= o es137x.o ich.o via8233.o hdaa.o hdaa_patches.o hdac.o hdac_if.o hdacc.o = ac97.o ac97_if.o ac97_patch.o buffer.o channel.o channel_if.o dsp.o feeder= =2Eo feeder_chain.o feeder_eq.o feeder_if.o feeder_format.o feeder_matrix.= o feeder_mixer.o feeder_rate.o feeder_volume.o mixer.o mixer_if.o sndstat.= o sound.o vchan.o midi.o mpu401.o mpu_if.o mpufoi_if.o sequencer.o synth_= if.o if_ste.o if_stge.o sym_hipd.o schistory.o scmouse.o scterm.o scvidctl= =2Eo syscons.o sysmouse.o if_ti.o if_tl.o trm.o tws.o tws_cam.o tws_hdm.o = tws_services.o tws_user.o if_tx.o if_txp.o uart_bus_acpi.o uart_bus_isa.o = uart_bus_pccard.o uart_bus_pci.o uart_bus_puc.o uart_core.o uart_dbg.o ua= rt_dev_ns8250.o uart_if.o uart_subr.o uart_tty.o ehci.o ehci_pci.o ohci.o = ohci_pci.o uhci.o uhci_pci.o xhci.o xhci_pci.o usb_controller.o umass.o us= b_busdma.o usb_core.o usb_debug.o usb_dev.o usb_device.o usb_dynamic.o usb= _error.o usb_generic.o usb_handle_request.o usb_hid.o usb_hub.o usb_if.o u= sb_lookup.o usb_mbuf.o usb_msctest.o usb_parse.o usb_pf.o usb_process.o u= sb_request.o usb_transfer.o usb_util.o ukbd.o usb_quirk.o if_vge.o virtio.= o virtqueue.o virtio_bus_if.o virtio_if.o virtio_pci.o if_vtnet.o virtio_b= lk.o virtio_balloon.o virtio_scsi.o if_vr.o vt_termcolors.o vt_font_defaul= t.o vt_mouse_cursor.o efifb.o vt_fb.o vt_vga.o logo_freebsd.o logo_beasti= e.o vt_buf.o vt_consolectl.o vt_core.o vt_cpulogos.o vt_font.o vt_sysmouse= =2Eo if_vx.o if_vx_pci.o watchdog.o if_wb.o if_wpi.o balloon.o blkfront.o = blkback.o xen_console.o control.o grant_table.o netback.o netfront.o xenpc= i.o timer.o pvcpu.o xenstore.o xenstore_dev.o xenstored_dev.o evtchn_dev.o= privcmd.o gntdev.o debug.o if_xl.o xlphy.o dead_vnops.o devfs_devs.o dev= fs_dir.o devfs_rule.o devfs_vfsops.o devfs_vnops.o fifo_vnops.o msdosfs_co= nv.o msdosfs_denode.o msdosfs_fat.o msdosfs_lookup.o msdosfs_vfsops.o msdo= sfs_vnops.o nfs_commonkrpc.o nfs_commonsubs.o nfs_commonport.o nfs_common= acl.o nfs_clcomsubs.o nfs_clsubs.o nfs_clstate.o nfs_clkrpc.o nfs_clrpcops= =2Eo nfs_clvnops.o nfs_clnode.o nfs_clvfsops.o nfs_clport.o nfs_clbio.o nf= s_clnfsiod.o nfs_fha_new.o nfs_nfsdsocket.o nfs_nfsdsubs.o nfs_nfsdstate.o= nfs_nfsdkrpc.o nfs_nfsdserv.o nfs_nfsdport.o nfs_nfsdcache.o procfs.o pr= ocfs_dbregs.o procfs_fpregs.o procfs_ioctl.o procfs_map.o procfs_mem.o pro= cfs_note.o procfs_osrel.o procfs_regs.o procfs_rlimit.o procfs_status.o pr= ocfs_type.o pseudofs.o pseudofs_fileno.o pseudofs_vncache.o pseudofs_vnops= =2Eo gdb_cons.o gdb_main.o gdb_packet.o geom_bsd_enc.o geom_ctl.o geom_de= v.o geom_disk.o geom_dump.o geom_event.o geom_flashmap.o geom_io.o geom_ke= rn.o geom_slice.o geom_subr.o geom_vfs.o g_label.o g_label_ext2fs.o g_labe= l_iso9660.o g_label_msdosfs.o g_label_ntfs.o g_label_reiserfs.o g_label_uf= s.o g_label_gpt.o g_label_disk_ident.o g_part.o g_part_if.o g_part_bsd.o = g_part_ebr.o g_part_gpt.o g_part_mbr.o g_raid.o g_raid_ctl.o g_raid_md_if.= o g_raid_tr_if.o md_ddf.o md_intel.o md_jmicron.o md_nvidia.o md_promise.o= md_sii.o tr_concat.o tr_raid0.o tr_raid1.o tr_raid1e.o tr_raid5.o isa_if.= o isa_common.o isahint.o cd9660_bmap.o cd9660_lookup.o cd9660_node.o cd96= 60_rrip.o cd9660_util.o cd9660_vfsops.o cd9660_vnops.o bus_if.o clock_if.o= cpufreq_if.o device_if.o imgact_elf.o imgact_elf32.o imgact_shell.o init_= main.o init_sysent.o ksched.o kern_acct.o kern_clock.o kern_condvar.o kern= _conf.o kern_cons.o kern_cpu.o kern_cpuset.o kern_context.o kern_descrip.o= kern_dtrace.o kern_dump.o kern_environment.o kern_et.o kern_event.o kern= _exec.o kern_exit.o kern_fail.o kern_ffclock.o kern_fork.o kern_hhook.o ke= rn_idle.o kern_intr.o kern_jail.o kern_khelp.o kern_kthread.o kern_ktrace.= o kern_linker.o kern_lock.o kern_lockf.o kern_lockstat.o kern_loginclass.o= kern_malloc.o kern_mbuf.o kern_mib.o kern_module.o kern_mtxpool.o kern_m= utex.o kern_ntptime.o kern_numa.o kern_osd.o kern_physio.o kern_pmc.o kern= _priv.o kern_proc.o kern_procctl.o kern_prot.o kern_racct.o kern_rangelock= =2Eo kern_rctl.o kern_resource.o kern_rmlock.o kern_rwlock.o kern_sdt.o k= ern_sema.o kern_sendfile.o kern_sharedpage.o kern_shutdown.o kern_sig.o ke= rn_switch.o kern_sx.o kern_synch.o kern_syscalls.o kern_sysctl.o kern_tc.o= kern_thr.o kern_thread.o kern_time.o kern_timeout.o kern_umtx.o kern_uuid= =2Eo kern_xxx.o link_elf.o linker_if.o md5c.o p1003_1b.o posix4_mib.o sch= ed_ule.o serdev_if.o stack_protector.o subr_acl_nfs4.o subr_acl_posix1e.o = subr_autoconf.o subr_blist.o subr_bus.o subr_bus_dma.o subr_bufring.o subr= _capability.o subr_clock.o subr_counter.o subr_devstat.o subr_disk.o subr_= eventhandler.o subr_fattime.o subr_firmware.o subr_gtaskqueue.o subr_hash.= o subr_hints.o subr_kdb.o subr_kobj.o subr_lock.o subr_log.o subr_module.= o subr_msgbuf.o subr_param.o subr_pcpu.o subr_pctrie.o subr_power.o subr_p= rf.o subr_prof.o subr_rman.o subr_rtc.o subr_sbuf.o subr_scanf.o subr_sgli= st.o subr_sleepqueue.o subr_smp.o subr_stack.o subr_taskqueue.o subr_term= inal.o subr_trap.o subr_turnstile.o subr_uio.o subr_unit.o subr_vmem.o sub= r_witness.o sys_capability.o sys_generic.o sys_pipe.o sys_procdesc.o sys_p= rocess.o sys_socket.o syscalls.o sysv_ipc.o sysv_msg.o sysv_sem.o sysv_sh= m.o tty.o tty_info.o tty_inq.o tty_outq.o tty_pts.o tty_tty.o tty_ttydisc.= o uipc_accf.o uipc_debug.o uipc_domain.o uipc_mbuf.o uipc_mbuf2.o uipc_mbu= fhash.o uipc_shm.o uipc_sockbuf.o uipc_socket.o uipc_syscalls.o uipc_usrre= q.o vfs_acl.o vfs_aio.o vfs_bio.o vfs_cache.o vfs_cluster.o vfs_default.o= vfs_export.o vfs_extattr.o vfs_hash.o vfs_init.o vfs_lookup.o vfs_mount.o= vfs_mountroot.o vfs_subr.o vfs_syscalls.o vfs_vnops.o arc4random.o chacha= =2Eo asprintf.o bcd.o bsearch.o crc32.o explicit_bzero.o fnmatch.o inet_at= on.o inet_ntoa.o inet_ntop.o inet_pton.o jenkins_hash.o murmur3_32.o memc= chr.o memchr.o memcmp.o memmem.o qsort.o qsort_r.o random.o scanc.o strcas= ecmp.o strcat.o strchr.o strcmp.o strcpy.o strcspn.o strdup.o strndup.o st= rlcat.o strlcpy.o strlen.o strncat.o strncmp.o strncpy.o strnlen.o strrchr= =2Eo strsep.o strspn.o strstr.o strtol.o strtoq.o strtoul.o strtouq.o str= valid.o timingsafe_bcmp.o zlib.o bpf.o bpf_buffer.o bpf_filter.o bpf_zeroc= opy.o if.o if_clone.o if_dead.o if_debug.o if_ethersubr.o if_gif.o if_ipse= c.o if_loop.o if_llatbl.o if_media.o if_mib.o if_tun.o if_vlan.o ifdi_if.o= iflib.o mp_ring.o netisr.o pfil.o radix.o radix_mpath.o raw_cb.o raw_usr= req.o route.o rtsock.o ieee80211.o ieee80211_action.o ieee80211_ageq.o iee= e80211_adhoc.o ieee80211_amrr.o ieee80211_crypto.o ieee80211_crypto_ccmp.o= ieee80211_crypto_none.o ieee80211_crypto_tkip.o ieee80211_crypto_wep.o i= eee80211_ddb.o ieee80211_dfs.o ieee80211_freebsd.o ieee80211_hostap.o ieee= 80211_ht.o ieee80211_hwmp.o ieee80211_input.o ieee80211_ioctl.o ieee80211= _mesh.o ieee80211_monitor.o ieee80211_node.o ieee80211_output.o ieee80211_= phy.o ieee80211_power.o ieee80211_proto.o ieee80211_radiotap.o ieee80211_r= atectl.o ieee80211_ratectl_none.o ieee80211_regdomain.o ieee80211_scan.o = ieee80211_scan_sta.o ieee80211_sta.o ieee80211_scan_sw.o ieee80211_vht.o i= eee80211_wds.o accf_data.o accf_http.o if_ether.o igmp.o in.o in_debug.o i= n_kdtrace.o in_fib.o in_gif.o ip_id.o in_jail.o in_mcast.o in_pcb.o in_pro= t.o in_proto.o in_rmx.o ip_divert.o ip_ecn.o ip_encap.o ip_fastfwd.o ip_ic= mp.o ip_input.o ip_options.o ip_output.o ip_reass.o raw_ip.o cc.o cc_newr= eno.o sctp_asconf.o sctp_auth.o sctp_bsd_addr.o sctp_cc_functions.o sctp_c= rc32.o sctp_indata.o sctp_input.o sctp_output.o sctp_pcb.o sctp_peeloff.o = sctp_ss_functions.o sctp_syscalls.o sctp_sysctl.o sctp_timer.o sctp_usrreq= =2Eo sctputil.o tcp_hostcache.o tcp_input.o tcp_lro.o tcp_output.o tcp_of= fload.o tcp_reass.o tcp_sack.o tcp_subr.o tcp_syncache.o tcp_timer.o tcp_t= imewait.o tcp_usrreq.o udp_usrreq.o alias.o alias_db.o alias_mod.o alias_p= roxy.o alias_util.o alias_sctp.o dest6.o frag6.o icmp6.o in6.o in6_cksum.o= in6_fib.o in6_gif.o in6_ifattach.o in6_jail.o in6_mcast.o in6_pcb.o in6_p= roto.o in6_rmx.o in6_src.o ip6_fastfwd.o ip6_forward.o ip6_id.o ip6_input= =2Eo ip6_output.o mld6.o nd6.o nd6_nbr.o nd6_rtr.o raw_ip6.o route6.o scop= e6.o sctp6_usrreq.o udp6_usrreq.o ipsec.o ipsec_input.o ipsec_mbuf.o ipsec= _mod.o ipsec_output.o ipsec_pcb.o key.o key_debug.o keysock.o subr_ipsec.o= udpencap.o xform_ah.o xform_esp.o xform_ipcomp.o dn_aqm_codel.o dn_aqm_p= ie.o dn_heap.o dn_sched_fifo.o dn_sched_fq_codel.o dn_sched_fq_pie.o dn_sc= hed_prio.o dn_sched_qfq.o dn_sched_rr.o dn_sched_wf2q.o ip_dummynet.o ip_d= n_io.o ip_dn_glue.o ip_fw2.o ip_fw_bpf.o ip_fw_dynamic.o ip_fw_eaction.o i= p_fw_log.o ip_fw_pfil.o ip_fw_sockopt.o ip_fw_table.o ip_fw_table_algo.o = ip_fw_table_value.o ip_fw_iface.o nfs_diskless.o nfs_fha.o nfs_lock.o nfs_= nfssvc.o nlm_advlock.o nlm_prot_clnt.o nlm_prot_impl.o nlm_prot_server.o n= lm_prot_svc.o nlm_prot_xdr.o sm_inter_xdr.o cast.o criov.o crypto.o crypto= dev_if.o cryptosoft.o cryptodeflate.o gmac.o gfmult.o rmd160.o skipjack.o = xform.o auth_none.o auth_unix.o authunix_prot.o clnt_bck.o clnt_dg.o clnt= _rc.o clnt_vc.o getnetconfig.o replay.o rpc_callmsg.o rpc_generic.o rpc_pr= ot.o rpcb_clnt.o rpcb_prot.o svc.o svc_auth.o svc_auth_unix.o svc_dg.o svc= _generic.o svc_vc.o audit.o audit_arg.o audit_bsm.o audit_bsm_db.o audit_b= sm_klib.o audit_pipe.o audit_syscalls.o audit_trigger.o audit_worker.o bs= m_domain.o bsm_errno.o bsm_fcntl.o bsm_socket_type.o bsm_token.o mac_audit= =2Eo mac_cred.o mac_framework.o mac_inet.o mac_inet6.o mac_label.o mac_net= =2Eo mac_pipe.o mac_posix_sem.o mac_posix_shm.o mac_priv.o mac_process.o m= ac_socket.o mac_syscalls.o mac_system.o mac_sysv_msg.o mac_sysv_sem.o mac= _sysv_shm.o mac_vfs.o teken.o ffs_alloc.o ffs_balloc.o ffs_inode.o ffs_sna= pshot.o ffs_softdep.o ffs_subr.o ffs_tables.o ffs_vfsops.o ffs_vnops.o ffs= _suspend.o ufs_acl.o ufs_bmap.o ufs_dirhash.o ufs_extattr.o ufs_gjournal.o= ufs_inode.o ufs_lookup.o ufs_quota.o ufs_vfsops.o ufs_vnops.o default_pa= ger.o device_pager.o phys_pager.o redzone.o sg_pager.o swap_pager.o uma_co= re.o uma_dbg.o memguard.o vm_fault.o vm_glue.o vm_init.o vm_kern.o vm_map.= o vm_meter.o vm_mmap.o vm_object.o vm_page.o vm_pageout.o vm_pager.o vm_ph= ys.o vm_radix.o vm_reserv.o vm_domain.o vm_unix.o vnode_pager.o features.= o xenbus_if.o xenbus.o xenbusb_if.o xenbusb.o xenbusb_front.o xenbusb_back= =2Eo xenmem_if.o xdr.o xdr_array.o xdr_mbuf.o xdr_mem.o xdr_reference.o xd= r_sizeof.o hptnr_lib.o hptrr_lib.o acpi_machdep.o atomic.o bios.o cpu_swit= ch.o db_disasm.o db_interface.o db_trace.o elf_machdep.o exception.o fpu.= o gdb_machdep.o in_cksum.o initcpu.o io.o xen-locore.o machdep.o mem.o min= idump_machdep.o mp_machdep.o mpboot.o pmap.o ptrace_machdep.o sigtramp.o s= upport.o sys_machdep.o trap.o uio_machdep.o uma_machdep.o vm_machdep.o pci= _cfgreg.o bf_enc.o des_enc.o acpi_if.o acpi_hpet.o acpi_pci.o acpi_pci_lin= k.o acpi_pcib.o acpi_pcib_acpi.o acpi_pcib_pci.o acpi_timer.o acpi_wmi_if= =2Eo agp_amd64.o agp_i810.o agp_via.o atkbd.o atkbd_atkbdc.o atkbdc.o atkb= dc_isa.o atkbdc_subr.o psm.o bxe.o bxe_stats.o bxe_debug.o ecore_sp.o bxe_= elink.o 57710_init_values.o 57711_init_values.o 57712_init_values.o fb.o = vesa.o vga.o iodev.o if_ixl.o ixl_pf_main.o ixl_pf_qmgr.o ixl_pf_iov.o ixl= _pf_i2c.o ixl_iw.o if_ixlv.o ixlvc.o ixl_txrx.o i40e_osdep.o i40e_lan_hmc.= o i40e_hmc.o i40e_common.o i40e_nvm.o i40e_adminq.o fdc.o fdc_acpi.o fdc_i= sa.o fdc_pccard.o hptnr_os_bsd.o hptnr_osm_bsd.o hptnr_config.o hptrr_os_b= sd.o hptrr_osm_bsd.o hptrr_config.o hv_kbd.o hv_kbdc.o vmbus_pcib.o hn_nv= s.o hn_rndis.o if_hn.o hv_storvsc_drv_freebsd.o hv_kvp.o hv_snapshot.o vmb= us_heartbeat.o vmbus_ic.o vmbus_shutdown.o vmbus_timesync.o hyperv.o hyper= v_busdma.o vmbus.o vmbus_br.o vmbus_chan.o vmbus_et.o vmbus_if.o vmbus_res= =2Eo vmbus_xact.o hyperv_machdep.o vmbus_vector.o if_nfe.o nvd.o nvme.o n= vme_ctrlr.o nvme_ctrlr_cmd.o nvme_ns.o nvme_ns_cmd.o nvme_qpair.o nvme_sys= ctl.o nvme_test.o nvme_util.o ivy.o nehemiah.o spkr.o scterm-teken.o scves= actl.o scvgarndr.o scvtb.o uart_cpu_x86.o if_vmx.o xen_acpi_pci.o xen_pci.= o isci.o isci_controller.o isci_domain.o isci_interrupt.o isci_io_request= =2Eo isci_logger.o isci_oem_parameters.o isci_remote_device.o isci_sysctl.= o isci_task_request.o isci_timer.o sati.o sati_abort_task_set.o sati_atapi= =2Eo sati_device.o sati_inquiry.o sati_log_sense.o sati_lun_reset.o sati_= mode_pages.o sati_mode_select.o sati_mode_sense.o sati_mode_sense_10.o sat= i_mode_sense_6.o sati_move.o sati_passthrough.o sati_read.o sati_read_buff= er.o sati_read_capacity.o sati_reassign_blocks.o sati_report_luns.o sati_= request_sense.o sati_start_stop_unit.o sati_synchronize_cache.o sati_test_= unit_ready.o sati_unmap.o sati_util.o sati_verify.o sati_write.o sati_writ= e_and_verify.o sati_write_buffer.o sati_write_long.o sci_abstract_list.o = sci_base_controller.o sci_base_domain.o sci_base_iterator.o sci_base_libra= ry.o sci_base_logger.o sci_base_memory_descriptor_list.o sci_base_memory_= descriptor_list_decorator.o sci_base_object.o sci_base_observer.o sci_base= _phy.o sci_base_port.o sci_base_remote_device.o sci_base_request.o sci_ba= se_state_machine.o sci_base_state_machine_logger.o sci_base_state_machine_= observer.o sci_base_subject.o sci_util.o scic_sds_controller.o scic_sds_li= brary.o scic_sds_pci.o scic_sds_phy.o scic_sds_port.o scic_sds_port_confi= guration_agent.o scic_sds_remote_device.o scic_sds_remote_node_context.o s= cic_sds_remote_node_table.o scic_sds_request.o scic_sds_sgpio.o scic_sds_s= mp_remote_device.o scic_sds_smp_request.o scic_sds_ssp_request.o scic_sds= _stp_packet_request.o scic_sds_stp_remote_device.o scic_sds_stp_request.o = scic_sds_unsolicited_frame_control.o scif_sas_controller.o scif_sas_contro= ller_state_handlers.o scif_sas_controller_states.o scif_sas_domain.o scif= _sas_domain_state_handlers.o scif_sas_domain_states.o scif_sas_high_priori= ty_request_queue.o scif_sas_internal_io_request.o scif_sas_io_request.o s= cif_sas_io_request_state_handlers.o scif_sas_io_request_states.o scif_sas_= library.o scif_sas_remote_device.o scif_sas_remote_device_ready_substate_= handlers.o scif_sas_remote_device_ready_substates.o scif_sas_remote_devic= e_starting_substate_handlers.o scif_sas_remote_device_starting_substates.o= scif_sas_remote_device_state_handlers.o scif_sas_remote_device_states.o = scif_sas_request.o scif_sas_smp_activity_clear_affiliation.o scif_sas_smp= _io_request.o scif_sas_smp_phy.o scif_sas_smp_remote_device.o scif_sas_stp= _io_request.o scif_sas_stp_remote_device.o scif_sas_stp_task_request.o sc= if_sas_task_request.o scif_sas_task_request_state_handlers.o scif_sas_task= _request_states.o scif_sas_timer.o syscons_isa.o vga_isa.o kern_clocksourc= e.o link_elf_obj.o crc32_sse42.o memmove.o memset.o ia32_reg.o ia32_signal= =2Eo ia32_sigtramp.o ia32_syscall.o ia32_misc.o ia32_sysvec.o x86bios.o x8= 6emu.o OsdEnvironment.o acpi_apm.o acpi_wakeup.o madt.o srat.o powernow.o= est.o hwpstate.o p4tcc.o busdma_dmar.o intel_ctx.o intel_drv.o intel_faul= t.o intel_gas.o intel_idpgtbl.o intel_intrmap.o intel_qi.o intel_quirks.o = intel_utils.o atrtc.o clock.o isa.o isa_dma.o nmi.o orm.o pci_bus.o qpi.o = autoconf.o bus_machdep.o busdma_bounce.o busdma_machdep.o cpu_machdep.o d= ump_machdep.o identcpu.o intr_machdep.o io_apic.o legacy.o local_apic.o mc= a.o x86_mem.o mp_x86.o msi.o nexus.o pvclock.o stack_machdep.o tsc.o delay= =2Eo hvm.o xen_intr.o pv.o pvcpu_enum.o xen_apic.o xenpv.o xen_nexus.o xen= _msi.o xen_pci_bus.o config.o env.o hints.o vnode_if.o hack.pico vers.o; @o= bjcopy --strip-symbol gcc2_compiled. kernel.full ; size kernel.full ; chmo= d 755 kernel.full;' =2ECURDIR=3D'/common/S4/obj/usr/src/sys/CANARY' =2EMAKE=3D'make' =2EOBJDIR=3D'/common/S4/obj/usr/src/sys/CANARY' =2ETARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/us= r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/ob= j/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/src' =2EMAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.e= nv.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/= bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/shar= e/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf Makefile /usr/= src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd= =2Eopts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /= usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/= conf/kern.post.mk /usr/src/sys/conf/kern.mk' =2EPATH=3D'. /common/S4/obj/usr/src/sys/CANARY' --- modules-all --- --- all_subdir_dtrace --- Building /common/S4/obj/usr/src/sys/CANARY/modules/usr/src/sys/modules/dtra= ce/systrace_linux32/systrace.o --- all_subdir_drm2 --- A failure has been detected in another branch of the parallel make =2E... Peace, david --=20 David H. Wolfskill david@catwhisker.org The President's tweets are beneath the diginty od his office. It needs to = stop. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --A++lktL53qannAg6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZV4bbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xse8H/jJrSZMz6OcYCdUbYcK3Oq7i Zf8GlJs3R3WhjcKtV7ocCn3htTNO1jmNDOS5hH194lrU97uU2TKJ4Ti4AXLqOKhD O34OxMaWotJGWZTf5ZQTLcmH8Ds2YEXG4vXsPvu8JeerXkapmLzO28Wxmmx43aAC DYuBc0nLDAfuOIl7kCJqHQLfij7LBngediccZP/ZKxLI4ntr897tbCjWxJDNG50m cpIWVnm9AMlr10YKih11lXQz/B85Vu0FeegbZ9yqqUhP2db374HHkzlsfdtw+OCO LF/yPhMev9Q3mvPX9FdHI9+yyXoyFmsGN6hbPzfxeNFzmjd0USG6Q+zaKjxgrf0= =HeSk -----END PGP SIGNATURE----- --A++lktL53qannAg6-- From owner-freebsd-current@freebsd.org Sat Jul 1 14:44:18 2017 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 38FF3D8BC15 for ; Sat, 1 Jul 2017 14:44:18 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8C786428B; Sat, 1 Jul 2017 14:44:17 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id v61Ep62k006135 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 1 Jul 2017 17:51:08 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id v61Ei0hT070069 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Jul 2017 17:44:00 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id v61EhvRP070056; Sat, 1 Jul 2017 17:43:57 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: Mark Millard Cc: FreeBSD Current , glebius@freebsd.org, imb@protected-networks.net, Hans Petter Selasky , iz-rpi03@hs-karlsruhe.de Subject: Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ] Date: Sat, 01 Jul 2017 17:43:57 +0300 Message-ID: <3277054.IUbe9d2na6@asus.theweb.org.ua> Organization: Private person User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.30; amd64; ; ) In-Reply-To: <285F63EB-9DC3-46DC-9849-3B47FDC719AE@dsl-only.net> References: <285F63EB-9DC3-46DC-9849-3B47FDC719AE@dsl-only.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 14:44:18 -0000 On Friday 30 June 2017 22:45:39 Mark Millard wrote: > [Just for the 3rd backtrace example. . .] > > Oleg V. Nauman oleg at theweb.org.ua wrote on > Fri Jun 23 16:58:07 UTC 2017 : > > .. . . > > > __curthread () at ./machine/pcpu.h:225 > > 225 __asm("movl %%fs:%1,%0" : "=r" (td) > > (kgdb) #0 __curthread () at ./machine/pcpu.h:225 > > #1 doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318 > > #2 0xc06e88c4 in kern_reboot (howto=) > > > > at ../../../kern/kern_shutdown.c:386 > > > > #3 0xc06e8c5b in vpanic (fmt=, > > > > ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001") > > at ../../../kern/kern_shutdown.c:779 > > > > #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s") > > > > at ../../../kern/kern_shutdown.c:710 > > > > #5 0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=) > > > > at ../../../i386/i386/trap.c:978 > > > > #6 0xc08eea38 in trap (frame=) > > > > at ../../../i386/i386/trap.c:704 > > > > #7 > > #8 0xc6bcda1b in ?? () > > #9 0xc0770281 in unp_connect2 (so=, so2=, > > > > req=) at ../../../kern/uipc_usrreq.c:1497 > > > > #10 0xc076ff17 in unp_connectat (fd=, so=, > > > > nam=, td=) > > at ../../../kern/uipc_usrreq.c:1446 > > > > #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500, > > > > td=) at ../../../kern/uipc_usrreq.c:1310 > > > > #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=) > > > > at ../../../kern/uipc_usrreq.c:587 > > > > #13 0xc076a042 in kern_connectat (td=, dirfd=-100, > > > > fd=, sa=0xc662d500) at > > ../../../kern/uipc_syscalls.c:505 > > > > #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988) > > > > at ../../../kern/uipc_syscalls.c:470 > > > > #15 0xc08ef679 in syscallenter (td=) > > > > at ../../../i386/i386/../../kern/subr_syscall.c:132 > > > > #16 syscall (frame=) at ../../../i386/i386/trap.c:1103 > > #17 > > #18 0x283a4747 in ?? () > > Backtrace stopped: Cannot access memory at address 0xbfbfe794 > > There are problems with a union having fields > that interfere with each other. The details of > the layout and interference likely vary from > TARGET_ARCH to TARGET_ARCH. This is from > new material added in head -r319722 and > involves /head/sys/sys/socketvar.h and > the new union in struct socket. > > See bugzilla 220404 and its analysis of a > repeatable crash on 32-bit powerpc for > head -r320482 (I'd made a large jump from > well before -r319722): > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404 > > It also involves unp_connect2, unp_connect, > kern_connectat, sys_connect and is likely > involved. But different aliasing in the > union across architectures likely lead to > varying details for the behavior that results > from the bad handling of union use. Subscribed, thank you. > > === > Mark Millard > markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jul 1 16:05:19 2017 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 52531D8D51C for ; Sat, 1 Jul 2017 16:05:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3A005665F4 for ; Sat, 1 Jul 2017 16:05:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 394B5D8D51B; Sat, 1 Jul 2017 16:05:19 +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 38E61D8D51A for ; Sat, 1 Jul 2017 16:05:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 0338E665F1 for ; Sat, 1 Jul 2017 16:05:15 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v61G5E2L086119; Sat, 1 Jul 2017 16:05:14 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v61G5EpM086118; Sat, 1 Jul 2017 09:05:14 -0700 (PDT) (envelope-from david) Date: Sat, 1 Jul 2017 09:05:14 -0700 From: David Wolfskill To: Jason Harmening Cc: current@freebsd.org Subject: Re: r320528? "undefined reference to `_bus_dma*" linking kernel Message-ID: <20170701160514.GZ1241@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Jason Harmening , current@freebsd.org References: <20170701112619.GV1241@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G1S25gKGjhquYsA6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 16:05:19 -0000 --G1S25gKGjhquYsA6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 01, 2017 at 08:59:58AM -0700, Jason Harmening wrote: > ... > These are all functions that were removed entirely or inlined for x86 in > r320528. > Looks like you have stale object files hanging around, seems like make > clean should fix it. OK; I'll pass that along to bdrewery@, as meta mode should handle that, I think. > Also thanks for reminding me to bump __FreeBSD_version :) :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Congratulations on the sesquicentennial, Canada! :-) See http://www.catwhisker.org/~david/publickey.gpg for my public key. --G1S25gKGjhquYsA6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZV8g6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X5OAIAIt2Fa2VJ801Phy0GnwG+tsh bfcsiltnMUzTV5ozNeOI9F2XkPlLWornLwqPZ0gFr+WUYy+W7qTCYYXyZi43xgN0 CXWH0a6vAZQnWN1JB+gio78gIAgdqJ4oOaToMM+RgE0ShtJ5Aeo3I6wNAXjdNLqk +toE7P+/FpjwBO3CRnYrRSbfJ6KJUSRIlqUV19g5KCSXWN/OU9chG4rQv55H6HJO On8YB5DuKXPH3WCmWiuQXTv2hlOjpaexRGE3+W918mjaiRG+82iqdmT7JO2CAJAv 2ibSKs5VPG3Pl5d/BJAzSu/0KLazZVv0FLgWka8Tl09tE0zpoUhbMEWwhC4Dras= =2DnG -----END PGP SIGNATURE----- --G1S25gKGjhquYsA6-- From owner-freebsd-current@freebsd.org Sat Jul 1 16:00:02 2017 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 5CCE6D8D1D4 for ; Sat, 1 Jul 2017 16:00:02 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 398AB661F1 for ; Sat, 1 Jul 2017 16:00:02 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 35D11D8D1D3; Sat, 1 Jul 2017 16:00:02 +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 35768D8D1D2 for ; Sat, 1 Jul 2017 16:00:02 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 B4D3C661EF; Sat, 1 Jul 2017 16:00:01 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id h22so83935025lfk.3; Sat, 01 Jul 2017 09:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gOl6ZIdeB1nbVEDZEQQtzhXyof/d7t0n5us7elLqVRI=; b=SdReytZkxB6Bvl6eqXIahmgjnFKzvzwZU2Kh8LM7yS45DLRU9Z5U5Sc9X3hApJaWny UNIXMhUosIyM76sWlvD/gmHPz/0t4pmm41nC/iD4M6rCkq7a9isIMW/+p/SlB3KW/eAG Fqeh+LEQI902ioXCcuBiyjGgunrFTyTWg/8G3qyWERvTpRtlGyAtLEHpbpWgGjrIY4IP X5atEONVRrUr0XaU/JzwEeaY3Y+jJJILvDuqPDl1e4sojOXLueThG1bn2GGvTHQCVlfQ tsj7qcfI+zRECPvbMac1+OMK9q94GuIvc2seswHnExw7yocmxSSjMKyGPSZ3x6+0lCef Z37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gOl6ZIdeB1nbVEDZEQQtzhXyof/d7t0n5us7elLqVRI=; b=MjSLXvawYfPg2LsbHDKX63gJWg5Rw8tdHVmytx9IcC8jNwMRdWvW2auNWnrkxpw0SF 765BVlKHd6bYwr4wLraMukwhBclaB5/Gc134U46fTnLD1/EFbgIZWqbbd1pxvTu+liJt c8x+/xV0dWa7E4IcD5fw0QnXMIup8JVykvXlkAclg90ZiP96knxWyYkD+XAlFtpONlhJ Cf5KvE3TPeTJwwHGbrvmRXjcWhdh7EUs/E3x6Lq4T5Q1a07niybKDSIrWlhg/ZdOf+dN VZY3xQMlgeYagA6bKMnwhhQL/E/rqvNT2Ze1ozAdrwG95GyS21POi47L7trr2aw2/8ra RsQg== X-Gm-Message-State: AKS2vOyCPqt3VluCWxXWzmM/bjAuO/yfFXl2Qqn5vfB8UkAdXhK4cDlS 7pkNO7+PHQkPSy+LUd3CqDk1o58Ajw== X-Received: by 10.46.22.72 with SMTP id 8mr8413540ljw.126.1498924798778; Sat, 01 Jul 2017 08:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.68 with HTTP; Sat, 1 Jul 2017 08:59:58 -0700 (PDT) In-Reply-To: <20170701112619.GV1241@albert.catwhisker.org> References: <20170701112619.GV1241@albert.catwhisker.org> From: Jason Harmening Date: Sat, 1 Jul 2017 08:59:58 -0700 Message-ID: Subject: Re: r320528? "undefined reference to `_bus_dma*" linking kernel To: David Wolfskill , current@freebsd.org, "Jason A. Harmening" X-Mailman-Approved-At: Sat, 01 Jul 2017 16:08:01 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 16:00:02 -0000 Hi David, On Sat, Jul 1, 2017 at 4:26 AM, David Wolfskill wrote: > > > --- kernel.full --- > /usr/src/sys/dev/advansys/adwcam.c:302: undefined reference to > `_bus_dmamap_sync' > /usr/src/sys/dev/advansys/adwcam.c:316: undefined reference to > `_bus_dmamap_unload' > if_ae.o: In function `ae_alloc_rings': > /usr/src/sys/dev/ae/if_ae.c:1162: undefined reference to > `bus_dmamem_alloc' > /usr/src/sys/dev/ae/if_ae.c:1182: undefined reference to > `bus_dmamem_alloc' > /usr/src/sys/dev/ae/if_ae.c:1202: undefined reference to > `bus_dmamem_alloc' > if_ae.o: In function `ae_dma_free': > /usr/src/sys/dev/ae/if_ae.c:1230: undefined reference to > `_bus_dmamap_unload' > /usr/src/sys/dev/ae/if_ae.c:1232: undefined reference to `bus_dmamem_free' > /usr/src/sys/dev/ae/if_ae.c:1241: undefined reference to > `_bus_dmamap_unload' > /usr/src/sys/dev/ae/if_ae.c:1243: undefined reference to `bus_dmamem_free' > /usr/src/sys/dev/ae/if_ae.c:1252: undefined reference to > `_bus_dmamap_unload' > /usr/src/sys/dev/ae/if_ae.c:1254: undefined reference to `bus_dmamem_free' > if_ae.o: In function `ae_tx_intr': > /usr/src/sys/dev/ae/if_ae.c:1823: undefined reference to > `_bus_dmamap_sync' > /usr/src/sys/dev/ae/if_ae.c:1825: undefined reference to > `_bus_dmamap_sync' > /usr/src/sys/dev/ae/if_ae.c:1875: undefined reference to > `_bus_dmamap_sync' > These are all functions that were removed entirely or inlined for x86 in r320528. Looks like you have stale object files hanging around, seems like make clean should fix it. Also thanks for reminding me to bump __FreeBSD_version :) From owner-freebsd-current@freebsd.org Sat Jul 1 17:20:41 2017 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 D9ABCD8EA74 for ; Sat, 1 Jul 2017 17:20:41 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 A404E68160 for ; Sat, 1 Jul 2017 17:20:41 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id p188so57334709oia.0 for ; Sat, 01 Jul 2017 10:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJGLsAiugFY2qXIMbUXAU7aeXiKKmktYJJpv5swPIpo=; b=uNxkBbWfJSCzty/jeLh/K6zbJWDNNHUCgKgKNv/kMuXiX1sKzYhnneIEw0poqqU1zO z6Z5AehKzfSVnvlP7np+z7BEbKq2OMGwH8Wib3c1FFLT7+CUPCJ8bX2Cyv4PJ8t0huMJ lGtMmFhAZJlqhsKVEcA+SLZrhiQ3GbC11VekgA58ZjpvzwNMAvQIBYBhj7oucgSq3MTv irtlQmVpz45Bs18fpU11Axv/7JQ9MuKel4Sj8AaFxtVmDpukEs5f6jf06tPMJ+GsJWbj Fejy7THLdwPCs7al8NS+TfjkcCk6UYacN6WJ7Q7c6cR5khQuCa57DiZ8yODgl445UhfU S2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJGLsAiugFY2qXIMbUXAU7aeXiKKmktYJJpv5swPIpo=; b=dVWeJCImloJl123foJKRYnL4vwy7mcZjeiki+GNeMUC5nl6s0wD6xnSOtuTDorM3F0 n+Y2jegcYzw2Z6kkI8PTXtMmnmQ1D3/rUNcDveNjTHtY/27V0QY8tmqgkHMoKjdnuKtx 6QGyOvj4PFdhowtsKv/kK9UuHvlFcPEbjFijfNXz3Pw3wryEw4djh1AxxddG6ff5R9+Q 2xWi/RNNyyJwFGFUe0GESSE0NijOZNPQG48cwXjvFM21td6kYay2hQDs8bt4XSyEFBif qwCgtRdfHku+E/l2h6z502X+Not6+lmbXuqRTJggCUYyxtcRrN0s0Xg0fu1NBj2+IgoY vghg== X-Gm-Message-State: AKS2vOz3dqWyXhjZiEKcuppdvxBL9Qa5SqhNxqvIWqOs00aze0TeJiFy pZZWgNxRKXRSke474R4jZlgf25p/8Q== X-Received: by 10.202.98.134 with SMTP id w128mr13877380oib.37.1498929640720; Sat, 01 Jul 2017 10:20:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.20.163 with HTTP; Sat, 1 Jul 2017 10:20:40 -0700 (PDT) In-Reply-To: References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170625190544.GH3437@kib.kiev.ua> From: Benjamin Kaduk Date: Sat, 1 Jul 2017 12:20:40 -0500 Message-ID: Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 To: Konstantin Belousov Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 17:20:41 -0000 On Tue, Jun 27, 2017 at 1:56 PM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Tue, 27 Jun 2017 20:28+0200, Trond Endrest=C3=B8l wrote: > > > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > > > > This patch made ruby23 happy on my end. Can't say the same for > > > > emacs-nox11 or temacs while building the former. > > > > > > What exactly do you mean ? Explain the behaviour and show the ktrace > log. > > > > It builds now. > > > > I'm running unpatched r320406, and I'll attempt building and running > > r320420 with your patch from yesterday. > > > > I too suffer from /sbin/zfs' inability to run in singleuser mode, yet > > somehow it does its job while in multiuser mode. > > That patch enables /sbin/zfs to run in singleuser mode. > > Next, there seems to be a race condition while running installworld in > parallel, but that's a story for another time. > > Sorry for the slow reply; I didn't get a usable update window right away. At r320458 I am not seeing any issues. -Ben From owner-freebsd-current@freebsd.org Sat Jul 1 17:28:53 2017 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 3FAC6D8ED66 for ; Sat, 1 Jul 2017 17:28:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 C1F416851E for ; Sat, 1 Jul 2017 17:28:52 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr0-x22f.google.com with SMTP id 77so216938802wrb.1 for ; Sat, 01 Jul 2017 10:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=FkR2n4FswP87Q25uIfx3NkjtiCkhC8WnvreWmUxlqVs=; b=NU1CdJaGtNy1y8cs3s3r1QfGIG/MH6Ec/2REFoPK0anzXm1Z2VZ5Qv5VMVJg9bLxd8 y81er1lQjCJqAuzf8gS4oWDOiXcpuqAbGHiNx/KPSJndvwJOaAa4pJFTWgk0P0RRIeS0 +R9Mv0A2UCEpsr0IvuiB49CnO7FemAKYSJp6qPfN1coj6e5Iil1EUuGBEJB+UhvqDq2u oABSGcEkXbEY/tEUWB2Yq7V7tpoU8yQsHJ8aZwcvRmjR+iq00zj2W+vQW+kCLKsjRPSd SoKwzwuQwNLawRC2r/IHVqSQYvt/Gq9sZxb2merUG41WYdGdNarxyCXn9GILuhl5XwrA ixew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=FkR2n4FswP87Q25uIfx3NkjtiCkhC8WnvreWmUxlqVs=; b=qjMZhXFJe0PKfRhz+6K4rh3BkmRSnfG8PFru88kCJ7+RhAGRoKZh86Zf1Jyf6fz5zn o0eraP61Qkjl7+Yp+ee7OKYb3YmPvxqOjrs26nIVhv4yEzz90ivf9gM0BYd+gXHajvHO 45ruYTOF2HXgPnpJmTnzfGqQSBW+XYU16PjSJmomEpY2Pj0Tb1KOAyG65ue8MGhyTLqV 2rL2NFHC6d1srn8WzCxXc1uIYBCYX7h0nZGaJfqN41VLrTHCjRNUAvU4vdT1T9zoUQi4 99L6ZJU8Opn0vsr19vDEuV92FfEgRkPc90C3Ch4AOy9v9s+q2ZRYfQGzED2pneLBXf69 e+zg== X-Gm-Message-State: AKS2vOzgyqPFnLGa5KvxL3sJAH44Kb7pazr8YBO7Sm8RnpVX0oSshIRY HpXHVC5EXPJkX3NWPiBk43WT2KbQN/6RBBAOdoyd6srVxa9XrmtqtPHgNciMoXtRIHfDD2nFOhT 64zDLHrxPd7IzR8I1L+QovMqKVvsNA+qUp9RRNUaLumMRFU5rco77jJy+oO+6HPgoBcXqJTffvQ == X-Received: by 10.223.135.68 with SMTP id 4mr20610283wrz.141.1498930130915; Sat, 01 Jul 2017 10:28:50 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id l12sm13464600wrc.46.2017.07.01.10.28.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 01 Jul 2017 10:28:49 -0700 (PDT) Date: Sat, 1 Jul 2017 13:28:47 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Cc: kib@freebsd.org Subject: Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1 Message-ID: <20170701172847.v5hwzn6vhbrbiz2i@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="spfppu4bdjrbsx3k" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 17:28:53 -0000 --spfppu4bdjrbsx3k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM and security.bsd.stack_guard_page is > 1: https://goo.gl/photos/vZQY4B9jKJRLrNwP7 The PoC doesn't need to be run as root on vanilla FreeBSD with a default configuration. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --spfppu4bdjrbsx3k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAllX280ACgkQaoRlj1JF bu6zdBAAv9fOXMaGZWCl2nv9cC1UhloKBmAkih0LrNI3ESFqFkU25YG1sp4sEH2n Xg53eyZ04F4iSFIduRVD9+X8SlHcCMyX7eFuGWM/7vXXzcYxebknbqN6hF4XvhYL /Vg78mT720H3WgeYdG6ivQDDijyHkxs5C8dw/mEEPOW8nS5EjSaYSmRIRC9mhin2 dkaNG7uekcZTzjVK0VsogVw6GeHi2BtVAao3Zn4HzjI+/Qaza0rtJ7JtPjLreEj0 CLRJw+5osEElPPcZeQbGTc9J0iPYm8WJQXArDx1iKQwxUS0VBSz/qLkib0sr8yxD tXB1KCYKEO1aFwzlqze2hA5FXTPnmWF57xLZK6dATmbSjY1zyFPGx8t+CpQmWTeO pqkn3RWB+WGf0uFG3g/wCalivZsPu7kKtZdiKgCp2rXlTbfDJ9lEo/WncoTK4Zd1 3AyQZr6YXkIP6lbcqxuLTRtgmv4zPOYgGDo9cXV6o5Ncl824b3sMuG8RYnSyQO/K DO9IhyQZ5keQFmP+Mo1q1uqLRnux2xuIOpCEtChgg76kDxADwfOxKd943RU/V8Nb Lst0PULynPKMOytP4NkWXMwpwk4RZ6BAW71b/xkBe4cJy+jb3yZKda/zWKggPnUs BDbpKj93LFl2LCv3HTJ1+lbcDXE+BcJKp50kg7g1lgVSNV7Ioi0= =oqbe -----END PGP SIGNATURE----- --spfppu4bdjrbsx3k-- From owner-freebsd-current@freebsd.org Sat Jul 1 19:47:02 2017 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 8F79BD90FD5 for ; Sat, 1 Jul 2017 19:47:02 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 248376F8AA; Sat, 1 Jul 2017 19:47:02 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id k67so217038456wrc.2; Sat, 01 Jul 2017 12:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=q1ID2sfM7rb5h3KEaeoGhzEDtk7DW91j7ilGjKQRsWA=; b=Ok6uQjfGIBauYaGwqyckYF/gpOhOEZ3GyefAvYeXyGOHQ2m7ulBuCJ+iHb75sGZ93V SYUP0FIyICQMkbuEXFschOcy40+tnS30YJlWyrg702pqem7GawFaR7cVIq2YC6I4gSKo F0Vq7zLsJpvVSpsLW66Cp2YARtLNMI46ztEmboFj/wW4kwBfV8YxUCXN70/QniKmR3TU WNUHyb4ItxsanE6ZGMdKOgmxioglU30D+U2zf/2Tas+kRNVEVYnno/LQ9DrHqoMpFq/K 0e4E/Z45g6sSqf6QTgZozNu2bX+OH14H8rEvKdgPZ5jPOFfYOFsCr3Qtvh347PkX1eOz M2Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=q1ID2sfM7rb5h3KEaeoGhzEDtk7DW91j7ilGjKQRsWA=; b=TyaV2eV0WerTaguEeCwe1C/P1FpNkmHHbQN0fxhPUwt5yXmGisfzwZ89lFZPMNlL9D 4Pq5DhP8KwlYOaIjBAWv/TvBQUkqyrjVPhU9r8x+EtjR68/34rRSZqOczk1ogne3Jy/4 /hQE0XJ3CEXTreJcUUn3Dlyj19c3WIkPawK+0ckSORXQgtMPKdDffntAm10pr/rX+smg F7iY+KvV94NAEDbuYP26UefCCBgKW+WO8E4ebVpa/MvUXjE8L9mJNWuzoRRhnqf8vluF nCIoNYzNPqrffxhmoQN1hfmXT5NgyCIBcizBbduq1wUT1VDXbkkCKwxA/XGliN1o5rCc 7rcQ== X-Gm-Message-State: AKS2vOzKJQSUJ33jiNpbXaHFDp5MIh+wDfxO292r1w0MOL10NNHVqDx/ 2VqC4K+rnGNGhV4TbJbDzNqNiFndpNS8 X-Received: by 10.223.173.83 with SMTP id p77mr26889909wrc.25.1498938419544; Sat, 01 Jul 2017 12:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.164.129 with HTTP; Sat, 1 Jul 2017 12:46:58 -0700 (PDT) From: Guy Yur Date: Sat, 1 Jul 2017 22:46:58 +0300 Message-ID: Subject: running binary in chroot using qemu-arm-static fails to mmap after r320318 To: freebsd-current , kib@freebsd.org, sbruno@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 19:47:02 -0000 Hi, I tried to run armv6 /bin/sh in a chroot on an amd64 host using qemu-arm-static. It failed on invalid argument to mmap. # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh /lib/libedit.so.7: mmap of entire address space failed: Invalid argument rtld-elf only passes MAP_GUARD but ktrace shows mmap is called with MAP_FIXED and MAP_ANON too. I think qemu-user-static adds the flags in bsd-user/mmap.c target_mmap(). Does the qemu-user-static port need patching to support MAP_GUARD? ktrace snipet: 1072 qemu-arm-static CALL openat(AT_FDCWD,0xf4ff9020,0x300000) 1072 qemu-arm-static NAMI "/lib/libc.so.7" 1072 qemu-arm-static RET openat 3 1072 qemu-arm-static CALL fstat(0x3,0x7ffffffe9680) 1072 qemu-arm-static STRU struct stat {dev=687931144, ino=192007, mode=0100444, nlink=1, uid=0, gid=0, rdev=1548632, atime=1498921861.605975000, mtime=1498921861.608547000, ctime=1498921861.609724000, birthtime=1498921861.605973000, size=1720888, blksize=32768, blocks=3456, flags=0x20000 } 1072 qemu-arm-static RET fstat 0 1072 qemu-arm-static CALL mmap(0xf4ff7000,0x1000,0x1,0x41012,0xffffffff,0) 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 1072 qemu-arm-static CALL mmap(0xf4ff7000,0x1000,0x1,0x40012,0x3,0) 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 1072 qemu-arm-static CALL mmap(0xf4e37000,0x1c0000,0,0x3010,0xffffffff,0) 1072 qemu-arm-static RET mmap -1 errno 22 Invalid argument Thanks, Guy From owner-freebsd-current@freebsd.org Sat Jul 1 20:07:20 2017 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 1A9B1D9154A for ; Sat, 1 Jul 2017 20:07:20 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 D5F30700B8; Sat, 1 Jul 2017 20:07:19 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id m68so74516875ith.1; Sat, 01 Jul 2017 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YZYP3QJeHE9p44pq0QO7WvI4cNq7YVkqJg9SQMlUsG0=; b=k3YuwrsdB5mGegfUsngarOs6qP0cgglrW/z77jBza8mbW8bRo6Uh9yK4wD82K+cyaD KBKsC6twTwa152NLCt8YPE4YPhYNYyl46Fc5VgMJA3S8yAa5V5n/x4Olml4iHEZqVPHa Nlv5jzg1GIxY/j4Jl6Uq2xH8HQvPKVGPbdXzXOVEVUDSTeNZa7useHrbpUM4eRxpH8gp mWGNepvQv7Y47vi1DKi+gEhy6e5LOEJ4RDt529K5VJ3aVU4uNqzK+K1MjHwpS7atz1Hc 57rYHyBIhijX3eyM+B9FKe2cz6KNuGcyaAC8DaR3bpPlhpE8+tVpNWDanaF/12uxzPvH o8eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=YZYP3QJeHE9p44pq0QO7WvI4cNq7YVkqJg9SQMlUsG0=; b=gZW1RUmk6Ii49IJ/5Tj3bEHlDwWlY7wV5NiAhwq328ih/QIwNcEjEDoG1rzMWhoCcA m67RFjJL4hG8EGHqVlUOk0yUrTSu3asM+6qi3FoGmUhVja717lWdv0vsN8DjJwKNfIs1 Db9IOlLfE5iA9UyRRRhDOAJAFWZ9dSS2v82A6DKt0Yh57yEWLtqck0o04BXSVOQbx2SE Kz0CRDhHuq90OJoum072SJXdWQ5YHjn8Vdggj/r5TcT/QRlz9DQCTDT0HGeMmwqss0ga vIPVGRso/Jao9zgf0mVtkiVle0Su/y2NWjN2a2ob0KLU078T3Uzd13bNULNnLB8sZWpo uuDA== X-Gm-Message-State: AIVw111C1S5t8tZikKpp1nwh+C0pC0XfCpVwMRWuHzvMU+w8kkI21U1R vFpqU128UCEyHRJIZG8eTaJfpXQcYw== X-Received: by 10.36.141.134 with SMTP id w128mr2149563itd.84.1498939639037; Sat, 01 Jul 2017 13:07:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.126.27 with HTTP; Sat, 1 Jul 2017 13:07:18 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: From: Alan Cox Date: Sat, 1 Jul 2017 15:07:18 -0500 Message-ID: Subject: Re: running binary in chroot using qemu-arm-static fails to mmap after r320318 To: Guy Yur Cc: freebsd-current , kib@freebsd.org, sbruno@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:07:20 -0000 On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur wrote: > Hi, > > I tried to run armv6 /bin/sh in a chroot on an > amd64 host using qemu-arm-static. > It failed on invalid argument to mmap. > > # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ > # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh > /lib/libedit.so.7: mmap of entire address space failed: Invalid argument > > rtld-elf only passes MAP_GUARD but ktrace shows mmap > is called with MAP_FIXED and MAP_ANON too. > I think qemu-user-static adds the flags in bsd-user/mmap.c target_mmap(). > Does the qemu-user-static port need patching to support MAP_GUARD? > > MAP_ANON should not be passed to mmap(2) at the same time as MAP_GUARD. Passing MAP_FIXED at the same time is okay. > ktrace snipet: > 1072 qemu-arm-static CALL > openat(AT_FDCWD,0xf4ff9020,0x300000) > 1072 qemu-arm-static NAMI "/lib/libc.so.7" > 1072 qemu-arm-static RET openat 3 > 1072 qemu-arm-static CALL fstat(0x3,0x7ffffffe9680) > 1072 qemu-arm-static STRU struct stat {dev=687931144, ino=192007, > mode=0100444, nlink=1, uid=0, gid=0, rdev=1548632, > atime=1498921861.605975000, mtime=1498921861.608547000, > ctime=1498921861.609724000, birthtime=1498921861.605973000, > size=1720888, blksize=32768, blocks=3456, flags=0x20000 } > 1072 qemu-arm-static RET fstat 0 > 1072 qemu-arm-static CALL > mmap(0xf4ff7000,0x1000,0x1,0x41012 PRIVATE|MAP_FIXED|MAP_ANON|MAP_PREFAULT_READ>,0xffffffff,0) > 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 > 1072 qemu-arm-static CALL > mmap(0xf4ff7000,0x1000,0x1,0x40012 PREFAULT_READ>,0x3,0) > 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 > 1072 qemu-arm-static CALL > mmap(0xf4e37000,0x1c0000,0,0x3010 MAP_ANON|MAP_GUARD>,0xffffffff,0) > 1072 qemu-arm-static RET mmap -1 errno 22 Invalid argument > > Thanks, > Guy > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sat Jul 1 22:48:36 2017 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 61201D94695 for ; Sat, 1 Jul 2017 22:48:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 EB2CC7560B for ; Sat, 1 Jul 2017 22:48:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v61MmTVC075754 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jul 2017 01:48:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v61MmTVC075754 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v61MmTjM075753; Sun, 2 Jul 2017 01:48:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Jul 2017 01:48:29 +0300 From: Konstantin Belousov To: Shawn Webb Cc: freebsd-current@freebsd.org Subject: Re: Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1 Message-ID: <20170701224829.GB1935@kib.kiev.ua> References: <20170701172847.v5hwzn6vhbrbiz2i@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170701172847.v5hwzn6vhbrbiz2i@mutt-hbsd> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 22:48:36 -0000 On Sat, Jul 01, 2017 at 01:28:47PM -0400, Shawn Webb wrote: > When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM > and security.bsd.stack_guard_page is > 1: > > https://goo.gl/photos/vZQY4B9jKJRLrNwP7 > > The PoC doesn't need to be run as root on vanilla FreeBSD with a default > configuration. I cannot make much sense from the last sentence, esp. after mention of the setting of stack_guard_page to greater than one value in the first sentence. Anyway, there could be some situation where max_grow calculation overflows. Indeed only possible when guard > 1. Try this. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 114e4b34a90..9c9b781db2d 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -3684,7 +3684,7 @@ vm_map_growstack(vm_map_t map, vm_offset_t addr, vm_map_entry_t gap_entry) struct proc *p; struct vmspace *vm; struct ucred *cred; - vm_offset_t gap_end, gap_start, grow_start; + vm_offset_t gap_end, gap_start, grow_start, sgp; size_t grow_amount, max_grow; rlim_t lmemlim, stacklim, vmemlim; int rv, rv1; @@ -3727,8 +3727,11 @@ retry: } else { return (KERN_FAILURE); } - max_grow = gap_entry->end - gap_entry->start - stack_guard_page * - PAGE_SIZE; + sgp = stack_guard_page * PAGE_SIZE; + max_grow = gap_entry->end - gap_entry->start; + if (max_grow < sgp) + return (KERN_NO_SPACE); + max_grow -= sgp; if (grow_amount > max_grow) return (KERN_NO_SPACE);