From owner-freebsd-current@freebsd.org Sat Dec 10 19:52:59 2016 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 03367C7074C; Sat, 10 Dec 2016 19:52:59 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D326F1D75; Sat, 10 Dec 2016 19:52:58 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id uBAJqvh0024797 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Dec 2016 11:52:57 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id uBAJquL7024796; Sat, 10 Dec 2016 11:52:56 -0800 (PST) (envelope-from kargl) Date: Sat, 10 Dec 2016 11:52:56 -0800 From: "Steven G. Kargl" To: Hans Petter Selasky Cc: kargl@uw.edu, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: System hangs at boot in xhci0 Message-ID: <20161210195256.GA24787@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20161209210940.GA1144@troutmask.apl.washington.edu> <5a509678-2a67-b538-ea42-d9e80a6bd3eb@selasky.org> <20161209234530.GA21666@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161209234530.GA21666@troutmask.apl.washington.edu> User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Sun, 11 Dec 2016 05:21:22 +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: Sat, 10 Dec 2016 19:52:59 -0000 On Fri, Dec 09, 2016 at 03:45:30PM -0800, Steven G. Kargl wrote: > On Fri, Dec 09, 2016 at 11:58:21PM +0100, Hans Petter Selasky wrote: > > On 12/09/16 22:09, Steve Kargl wrote: > > > I updated my system to > > > > > > % svn info /usr/src > > > Revision: 309748 > > > > > > Built a shiny new kernel, which hangs during boot. > > > There is no panic. Using the dmesg from kernel.old/kernel, > > > the last few reported are > > > > > > > > > pci2: on pcib2 > > > xhci0: mem 0xfe900000-0xfe900fff > > > irq 48 at device 0.0 on pci2 > > > xhci0: 32 bytes context size, 64-bit DMA > > > > > > At this point, the system is completely unresponse and > > > needs to be power cycled. > > > > > > > Hi, > > > > What is the next message in the old kernel which is printed? There has > > been zero changes in the XHCI driver recently. > > > > Can you copy /boot/kernel.old to /boot/kernel.works > > > > Then add this option to the GENERIC kernel config: > > > > options VERBOSE_SYSINIT > > > > What are the last few messages in dmesg when you boot with the above flag? > > > > With a boot_verbose of the new kernel I get the following output: > > xhci0: 32 bytes context size, 64-bit DMA > xhci0: attempting to allocate 1 MSI vectors (4 supported) > msi: routing MSI IRQ 260 to local APIC 16 vector 55 > xhci0: using IRQ 260 for MSI > xhci0: MSI enabled > usbus0 on xhci0 > xhci0: usbpf: Attached > random: harvesting attach, 8 bytes (4 bits) from usbus0 > random: harvesting attach, 8 bytes (4 bits) from xhci0 > random: harvesting attach, 8 bytes (4 bits) from pci2 > random: harvesting attach, 8 bytes (4 bits) from pcib2 > > and then the system locks up. With the old kernel (circa > Oct 10th sources), next few lines from dmesg are > > pcib3: irq 54 at device 10.0 on pci0 > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib3 > pcib0: allocated type 3 (0xfe800000-0xfe8fffff) for rid 20 of pcib3 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xd000-0xdfff > pcib3: memory decode 0xfe800000-0xfe8fffff > pci3: on pcib3 > > I think that hang isn't caused by xhci, but rather is a > victim on being the last successfully probed device. In the last > weeks there have been a few commits (309588, 309400, and 308953) > that touched ACPI. I'm currently reverting these changes to test > if one is causing the problem. > > I did see that one of these revisions specific mentions the > ALASKA AMI bios, which I happen to have. However, that commit > also mentions a skylake processor while I have an AMD FX-8350. > Well, I reverted each of the above indicated revisions. No luck. New kernel still locks up. I guess it's time to do a bisection. Unfortunately, this cross a llvm 3.8 to 3.9 boundary. :( -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ From owner-freebsd-current@freebsd.org Sun Dec 11 18:21:15 2016 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 439C7C72359 for ; Sun, 11 Dec 2016 18:21:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 31136AFD for ; Sun, 11 Dec 2016 18:21:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 2F806C72357; Sun, 11 Dec 2016 18:21:15 +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 2F1CAC72356 for ; Sun, 11 Dec 2016 18:21:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 E6DF7AFC for ; Sun, 11 Dec 2016 18:21:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cG8kJ-000FVn-9J; Sun, 11 Dec 2016 21:21:11 +0300 Date: Sun, 11 Dec 2016 21:21:11 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211182111.GH31311@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161126155747.GF54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 18:21:15 -0000 On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console > to 1 and see if any NMI reaction appear. > > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > Hang in next two lines: msgbufinit(msgbufp, msgbufsize); fpuinit(); From owner-freebsd-current@freebsd.org Sun Dec 11 19:16:29 2016 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 4DDC8C723C5 for ; Sun, 11 Dec 2016 19:16:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 3B6C43F4 for ; Sun, 11 Dec 2016 19:16:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 37CD1C723C4; Sun, 11 Dec 2016 19:16:29 +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 376B2C723C3 for ; Sun, 11 Dec 2016 19:16:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 EE7503F3 for ; Sun, 11 Dec 2016 19:16:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cG9bm-000IXv-Qs; Sun, 11 Dec 2016 22:16:26 +0300 Date: Sun, 11 Dec 2016 22:16:26 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211191626.GI31311@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211182111.GH31311@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 19:16:29 -0000 On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > Boot stoped after next messages: > > > > > > === > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > So at least the hammer_time() has a chance to initialize the console. > > Do you have serial console ? Set the loader tunable debug.late_console > > to 1 and see if any NMI reaction appear. > > > > > === > > > > > > This is verbose boot. > > > No reaction to ~^B, NMI. > > > > > > Same for head and 10.3-RELEASE. > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > What if you try to frob it ? > > > > > > > > On slight different hardware > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > so you can start bisect the code from there. > > > > Hang in next two lines: > > msgbufinit(msgbufp, msgbufsize); > fpuinit(); [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c10 = msgbuf_reinit: pushq %rbp db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c11 = msgbuf_reinit+0x1: movq %rsp,%rbp db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c14 = msgbuf_reinit+0x4: pushq %r14 db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c16 = msgbuf_reinit+0x6: pushq %rbx db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c17 = msgbuf_reinit+0x7: movl %edx,%r8d db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c1a = msgbuf_reinit+0xa: movq %rdi,%r14 db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c1d = msgbuf_reinit+0xd: movq 0x8(%r14),%rax db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c21 = msgbuf_reinit+0x11: cmpl $0x63062,%eax db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538c26 = msgbuf_reinit+0x16: jnz 0xffffffff80538d37 = msgbuf_reinit+0x127 db> [ thread pid 0 tid 0 ] Stopped at 0xffffffff80538d37 = msgbuf_reinit+0x127: movq %rsi,(%r14) db> [ thread pid 0 tid 0 ] Stopped atKDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8032de4b = db_trace_self_wrapper+0x2b/frame 0xffffffff80bb9370 kdb_reenter() at 0xffffffff8053670e = kdb_reenter+0x8e/frame 0xffffffff80bb9420 trap() at 0xffffffff807c0a31 = trap+0x51/frame 0xffffffff80bb9630 calltrap() at 0xffffffff807a5011 = calltrap+0x8/frame 0xffffffff80bb9630 --- trap 0x1c, rip = 0xffffffff8032db33, rsp = 0xffffffff80bb9700, rbp = 0xffffffff80bb9730 --- X_db_search_symbol() at 0xffffffff8032db33 = X_db_search_symbol+0x53/frame 0xffffffff80bb9730 db_printsym() at 0xffffffff80330f30 = db_printsym+0x70/frame 0xffffffff80bb97a0 db_print_loc_and_inst() at 0xffffffff8032c0a3 = db_print_loc_and_inst+0x13/frame 0xffffffff80bb97c0 db_trap() at 0xffffffff8032df7f = db_trap+0xcf/frame 0xffffffff80bb9850 kdb_trap() at 0xffffffff80536b43 = kdb_trap+0x193/frame 0xffffffff80bb98e0 trap() at 0xffffffff807c0c3c = trap+0x25c/frame 0xffffffff80bb9af0 calltrap() at 0xffffffff807a5011 = calltrap+0x8/frame 0xffffffff80bb9af0 --- trap 0xa, rip = 0xffffffff80538d3a, rsp = 0xffffffff80bb9bc0, rbp = 0xffffffff80bb9bd0 --- msgbuf_reinit() at 0xffffffff80538d3a = msgbuf_reinit+0x12a/frame 0xffffffff80bb9bd0 msgbufinit() at 0xffffffff8053dd31 = msgbufinit+0x21/frame 0xffffffff80bb9be0 hammer_time() at 0xffffffff807aa5fa = hammer_time+0xf8a/frame 0xffffffff80bba070 btext() at 0xffffffff8028fc34 = btext+0x24 db> show registers cs 0x20 ds 0x28 es 0x28 fs 0x28 gs 0x28 ss 0x28 rax 0xffffffffffffffff rcx 0 rdx 0x17fb8 rbx 0x7 rsp 0xffffffff80bb9bc0 __stop_set_pcpu+0xb48 rbp 0xffffffff80bb9bd0 __stop_set_pcpu+0xb58 rsi 0xfffff8207ffe8000 rdi 0xfffff8207fffffb8 r8 0x17fb8 r9 0xffffffff80bb9818 __stop_set_pcpu+0x7a0 r10 0 r11 0 r12 0 r13 0x2080000000 r14 0xfffff8207fffffb8 r15 0xffffffff81800000 rip 0xffffffff80538d3a msgbuf_reinit+0x12a rflags 0x82 0xffffffff80538d3a = msgbuf_reinit+0x12a: movl %r8d,0xc(%r14) From owner-freebsd-current@freebsd.org Sun Dec 11 19:27:02 2016 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 D46C1C72195 for ; Sun, 11 Dec 2016 19:27:02 +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 BCDDA1202 for ; Sun, 11 Dec 2016 19:27:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B94ADC72194; Sun, 11 Dec 2016 19:27: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 B8EBEC72193 for ; Sun, 11 Dec 2016 19:27:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 314021201 for ; Sun, 11 Dec 2016 19:27:01 +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 uBBJQvSx062281 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 11 Dec 2016 21:26:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBBJQvSx062281 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBBJQuDa062280; Sun, 11 Dec 2016 21:26:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Dec 2016 21:26:56 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211192656.GZ54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211191626.GI31311@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 11 Dec 2016 19:27:02 -0000 On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > Boot stoped after next messages: > > > > > > > > === > > > > Booting... > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > So at least the hammer_time() has a chance to initialize the console. > > > Do you have serial console ? Set the loader tunable debug.late_console > > > to 1 and see if any NMI reaction appear. > > > > > > > === > > > > > > > > This is verbose boot. > > > > No reaction to ~^B, NMI. > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > What if you try to frob it ? > > > > > > > > > > > On slight different hardware > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > so you can start bisect the code from there. > > > > > > > Hang in next two lines: > > > > msgbufinit(msgbufp, msgbufsize); > > fpuinit(); Can you show the verbose dmesg up to the failure point ? In particular, the SMAP lines should be relevant. From owner-freebsd-current@freebsd.org Sun Dec 11 19:46:03 2016 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 B3097C7270C for ; Sun, 11 Dec 2016 19:46:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A03161D1B for ; Sun, 11 Dec 2016 19:46:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9C753C7270B; Sun, 11 Dec 2016 19:46:03 +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 9C135C7270A for ; Sun, 11 Dec 2016 19:46:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 5FABA1D1A for ; Sun, 11 Dec 2016 19:46:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGA4N-000K7q-V6; Sun, 11 Dec 2016 22:45:59 +0300 Date: Sun, 11 Dec 2016 22:45:59 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211194559.GJ31311@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211192656.GZ54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 19:46:03 -0000 On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > Boot stoped after next messages: > > > > > > > > > > === > > > > > Booting... > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > So at least the hammer_time() has a chance to initialize the console. > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > === > > > > > > > > > > This is verbose boot. > > > > > No reaction to ~^B, NMI. > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > What if you try to frob it ? > > > > > > > > > > > > > > On slight different hardware > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > so you can start bisect the code from there. > > > > > > > > > > Hang in next two lines: > > > > > > msgbufinit(msgbufp, msgbufsize); > > > fpuinit(); > > Can you show the verbose dmesg up to the failure point ? > In particular, the SMAP lines should be relevant. KDB: debugger backends: ddb KDB: current backend: ddb exit from kdb_init KDB: enter: Boot flags requested debugger [ thread pid 0 tid 0 ] Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq $0,0xffffffff80dcef20 = kdb_why No SMAP print, boot_verbose enabled. From owner-freebsd-current@freebsd.org Sun Dec 11 20:06:59 2016 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 CAE3EC72F04 for ; Sun, 11 Dec 2016 20:06:59 +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 B2BA71E07 for ; Sun, 11 Dec 2016 20:06:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id AF160C72F02; Sun, 11 Dec 2016 20:06:59 +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 AD0C1C72F01 for ; Sun, 11 Dec 2016 20:06:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E16B1E06 for ; Sun, 11 Dec 2016 20:06: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 uBBK6sGp071952 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 11 Dec 2016 22:06:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBBK6sGp071952 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBBK6sYG071951; Sun, 11 Dec 2016 22:06:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Dec 2016 22:06:54 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211200654.GA54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211194559.GJ31311@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 11 Dec 2016 20:06:59 -0000 On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > Boot stoped after next messages: > > > > > > > > > > > > === > > > > > > Booting... > > > > > > KDB: debugger backends: ddb > > > > > > KDB: current backend: ddb > > > > > So at least the hammer_time() has a chance to initialize the console. > > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > === > > > > > > > > > > > > This is verbose boot. > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > fpuinit(); > > > > Can you show the verbose dmesg up to the failure point ? > > In particular, the SMAP lines should be relevant. > > KDB: debugger backends: ddb > KDB: current backend: ddb > exit from kdb_init > KDB: enter: Boot flags requested debugger > [ thread pid 0 tid 0 ] > Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq > $0,0xffffffff80dcef20 = kdb_why > > No SMAP print, boot_verbose enabled. The log above shows that you used boot -d. What are the pristine boot messages, with debug.late_console set to 0, of course ? Hm, might be also show the output of the 'smap' and 'memmap' output from the loader. If any of them worked, could be useful to see the same output with the NUMA option disabled as well. From owner-freebsd-current@freebsd.org Sun Dec 11 20:47:14 2016 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 B2EEEC72166 for ; Sun, 11 Dec 2016 20:47:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 9ECC21828 for ; Sun, 11 Dec 2016 20:47:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9B3EAC72165; Sun, 11 Dec 2016 20:47:14 +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 9AEDDC72164 for ; Sun, 11 Dec 2016 20:47:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 5DD761827 for ; Sun, 11 Dec 2016 20:47:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGB1Z-000MOX-Ak; Sun, 11 Dec 2016 23:47:09 +0300 Date: Sun, 11 Dec 2016 23:47:09 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211204709.GK31311@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211200654.GA54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 20:47:14 -0000 On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > === > > > > > > > Booting... > > > > > > > KDB: debugger backends: ddb > > > > > > > KDB: current backend: ddb > > > > > > So at least the hammer_time() has a chance to initialize the console. > > > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > === > > > > > > > > > > > > > > This is verbose boot. > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > fpuinit(); > > > > > > Can you show the verbose dmesg up to the failure point ? > > > In particular, the SMAP lines should be relevant. > > > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > exit from kdb_init > > KDB: enter: Boot flags requested debugger > > [ thread pid 0 tid 0 ] > > Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq > > $0,0xffffffff80dcef20 = kdb_why > > > > No SMAP print, boot_verbose enabled. > The log above shows that you used boot -d. What are the pristine boot > messages, with debug.late_console set to 0, of course ? This is stable/11, no debug.late_console. With ANSI ESC, captured from SOL: ESC[01;00HType '?' for a /boot/kernel.VSTREAM/opensolaris.ko size 0xcb10 at 0x13d3000 ESC[01;00HOK smap /boot/kernel.VSTREAM/if_igb.ko size 0x69f10 at 0x13e0000 ESC[02;00HSMAP type=02 base=000000000009ESC[01;00HSMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 ESC[02;00HSMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 ESC[03;00Hcan't find 'if_ixgbe' ESC[01;00H/boot/kernel.VSTREAM/if_lagg.ko size 0x150c0 at 0x144a000 ESC[01;00HSMAP type=02 base=00000000000e/boot/kernel.VSTREAM/ukbd.ko size 0xe280 at 0x1460000 loading required moduleESC[01;00H 'usb'^MSMAP type=01 base=000000007916b000 len=0000000000936000 attr =01 ESC[02;00H/boot/kernel.VSTREAM/usb.ko size 0x45d40 at 0x146f000 ESC[01;00HSMAP type=04 base=0000000079aa1000 len=000000/boot/kernel.VSTREAM/umass.ko size 0xaa10 at 0x14b5000 ESC[01;00HSMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 ESC[02;00HSMAP type=01 ba/boot/kernel.VSTREAM/accf_http.ko size 0x2710 at 0x14c0000 ESC[01;00HSMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 /boot/kernel.VSTREAM/sfxge.ko ESC[02;00HSMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 size 0x1a8ee0 at 0x14c3000 ESC[03;00HSMAP type=02 base=00000000ff000000 len=0000000001000000 attr/boot/kernel.VSTREAM/uhci.ko size 0xd448 at 0x166c000 ESC[01;00HSMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 /boot/kernel.VSTREAM/ohci.ko size 0xc900 at 0x167a000 ESC[02;00HOK memmap ESC[03;00Hmemmap not foun/boot/kernel.VSTREAM/ehci.ko size 0xfb60 at 0x1687000 ESC[01;00HOK memmap /boot/kernel.VSTREAM/xhci.ko size 0x11010 at 0x1697000 ESC[01;00Hmemmap not found /boot/kernel.VSTREAM/if_ix.ko size 0x51358 at 0x16a9000^MESC[01;00HOK boot ESC[01;00HOK boot /boot/kernel.VSTREAM/cc_htcp.ko size 0x3a70 at 0x16fb000 Booting... ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb KDB: current backend: ddb exit from kdb_init KDB: enter: Boot flags requested debugger [ thread pid 0 tid 0 ] > Hm, might be also show the output of the 'smap' and 'memmap' output from > the loader. If any of them worked, could be useful to see the same output > with the NUMA option disabled as well. NUMA disabled: OK smap SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=000000000093a000 attr=01 SMAP type=04 base=0000000079aa5000 len=0000000000505000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 OK memmap memmap not found NUMA enabled: OK smap SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 OK memmap memmap not found From owner-freebsd-current@freebsd.org Sun Dec 11 21:15:55 2016 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 57760C73083 for ; Sun, 11 Dec 2016 21:15:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 42BF2E47 for ; Sun, 11 Dec 2016 21:15:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 42106C73082; Sun, 11 Dec 2016 21:15:55 +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 41B14C73081 for ; Sun, 11 Dec 2016 21:15:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 03A66E46 for ; Sun, 11 Dec 2016 21:15:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGBTN-000NPe-25; Mon, 12 Dec 2016 00:15:53 +0300 Date: Mon, 12 Dec 2016 00:15:53 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211211552.GL31311@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211204709.GK31311@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 21:15:55 -0000 On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > > > === > > > > > > > > Booting... > > > > > > > > KDB: debugger backends: ddb > > > > > > > > KDB: current backend: ddb > > > > > > > So at least the hammer_time() has a chance to initialize the console. > > > > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > This is verbose boot. > > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > > fpuinit(); > > > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > In particular, the SMAP lines should be relevant. > > > > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > exit from kdb_init > > > KDB: enter: Boot flags requested debugger > > > [ thread pid 0 tid 0 ] > > > Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq > > > $0,0xffffffff80dcef20 = kdb_why > > > > > > No SMAP print, boot_verbose enabled. > > The log above shows that you used boot -d. What are the pristine boot > > messages, with debug.late_console set to 0, of course ? > > This is stable/11, no debug.late_console. Booting HEAD: panic: pmap_mapdev_attr: too many preinit mappings cpuid = 0 KDB: stack backtrace: #0 0xffffffff80535197 at ??+0 #1 0xffffffff804eb0f2 at ??+0 #2 0xffffffff804eaf63 at ??+0 #3 0xffffffff807b5995 at ??+0 #4 0xffffffff808479ca at ??+0 #5 0xffffffff804079ea at ??+0 #6 0xffffffff8040bb44 at ??+0 #7 0xffffffff8047e178 at ??+0 #8 0xffffffff807a47c3 at ??+0 #9 0xffffffff8028f0a4 at ??+0 Uptime: 1s > With ANSI ESC, captured from SOL: > > ESC[01;00HType '?' for a /boot/kernel.VSTREAM/opensolaris.ko size 0xcb10 at 0x13d3000 > ESC[01;00HOK smap /boot/kernel.VSTREAM/if_igb.ko size 0x69f10 at 0x13e0000 > ESC[02;00HSMAP type=02 base=000000000009ESC[01;00HSMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 ESC[02;00HSMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 ESC[03;00Hcan't find 'if_ixgbe' > ESC[01;00H/boot/kernel.VSTREAM/if_lagg.ko size 0x150c0 at 0x144a000 > ESC[01;00HSMAP type=02 base=00000000000e/boot/kernel.VSTREAM/ukbd.ko size 0xe280 at 0x1460000 > loading required moduleESC[01;00H 'usb'^MSMAP type=01 base=000000007916b000 len=0000000000936000 attr > =01 ESC[02;00H/boot/kernel.VSTREAM/usb.ko size 0x45d40 at 0x146f000 > ESC[01;00HSMAP type=04 base=0000000079aa1000 len=000000/boot/kernel.VSTREAM/umass.ko size 0xaa10 at 0x14b5000 > ESC[01;00HSMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 ESC[02;00HSMAP type=01 ba/boot/kernel.VSTREAM/accf_http.ko size 0x2710 at 0x14c0000 > ESC[01;00HSMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 /boot/kernel.VSTREAM/sfxge.ko ESC[02;00HSMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 size 0x1a8ee0 at 0x14c3000 > ESC[03;00HSMAP type=02 base=00000000ff000000 len=0000000001000000 attr/boot/kernel.VSTREAM/uhci.ko size 0xd448 at 0x166c000 > ESC[01;00HSMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 /boot/kernel.VSTREAM/ohci.ko size 0xc900 at 0x167a000 > ESC[02;00HOK memmap ESC[03;00Hmemmap not foun/boot/kernel.VSTREAM/ehci.ko size 0xfb60 at 0x1687000 > ESC[01;00HOK memmap /boot/kernel.VSTREAM/xhci.ko size 0x11010 at 0x1697000 > ESC[01;00Hmemmap not found /boot/kernel.VSTREAM/if_ix.ko size 0x51358 at 0x16a9000^MESC[01;00HOK boot > ESC[01;00HOK boot /boot/kernel.VSTREAM/cc_htcp.ko size 0x3a70 at 0x16fb000 > Booting... > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > KDB: current backend: ddb > exit from kdb_init > KDB: enter: Boot flags requested debugger > [ thread pid 0 tid 0 ] > > > Hm, might be also show the output of the 'smap' and 'memmap' output from > > the loader. If any of them worked, could be useful to see the same output > > with the NUMA option disabled as well. > > NUMA disabled: > OK smap > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > SMAP type=02 base=000000007916b000 len=000000000093a000 attr=01 > SMAP type=04 base=0000000079aa5000 len=0000000000505000 attr=01 > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > OK memmap > memmap not found > > NUMA enabled: > OK smap > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > OK memmap > memmap not found From owner-freebsd-current@freebsd.org Sun Dec 11 21:46:44 2016 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 A25E2C73834 for ; Sun, 11 Dec 2016 21:46:44 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 923E71BE7; Sun, 11 Dec 2016 21:46:44 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [64.201.244.132] (port=50336 helo=[10.0.0.102]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1cGBbT-000EV6-6q; Sun, 11 Dec 2016 21:24:15 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: revisiting tunables under Safe Mode menu option From: Devin Teske In-Reply-To: <4F4FACB0.8090605@FreeBSD.org> Date: Sun, 11 Dec 2016 13:46:40 -0800 Cc: John Baldwin , freebsd-current@FreeBSD.org, Scott Long , Devin Teske Content-Transfer-Encoding: quoted-printable Message-Id: <5ED1C7D5-8B70-4D36-9682-07B7583B6605@freebsd.org> References: <4F26CC5A.2070501@FreeBSD.org> <4F4C0600.2000903@FreeBSD.org> <3BA1B476-ED05-4E8E-8DFA-0B06EFB48867@samsco.org> <201202280846.08966.jhb@freebsd.org> <4F4F35B9.5090308@FreeBSD.org> <06bb01ccf7cb$b255a200$1700e600$@fisglobal.com> <4F4FACB0.8090605@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx 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, 11 Dec 2016 21:46:44 -0000 Found this old mail between avg@ and myself and just had to laugh The boot loader is so much more levels of awesome now, but I had = forgotten how much thought I had put into it. Awesome sauce! ;D --=20 Cheers, Devin > On Mar 1, 2012, at 9:06 AM, Andriy Gapon wrote: >=20 > on 01/03/2012 18:52 Devin Teske said the following: >>=20 >>=20 >>> -----Original Message----- >>> From: Andriy Gapon [mailto:avg@FreeBSD.org] >>> Sent: Thursday, March 01, 2012 12:39 AM >>> To: Devin Teske >>> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin = Teske >>> Subject: Re: revisiting tunables under Safe Mode menu option >>>=20 >>> on 01/03/2012 03:34 Devin Teske said the following: >>>>=20 >>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, = but Safe >>>> Mode knows about ACPI but only acts on it when being enabled). >>>=20 >>> Can you explain why? >>> +1 for having both menu items and each doing its own thing without = any >>> entanglement :-) >>>=20 >>=20 >> First, I realize that this may sound entirely *dumb*, but here-goes: >>=20 >> In transitioning from an old release (sans-menu; 4.11 for example) to = a newer >> release (with menu; 6.x for example), one of the first thing that is = noticed is >> "Safe Mode". >>=20 >> I know that when I first saw this, I scratched my head and wondered = what it did >> and what it might be useful for. To this day, I still have never used = it. >>=20 >> When I created the new menu for 9.x/higher, I had to rewrite that = portion of the >> code and eventually learned what Safe Mode does when used. Still = can't say that >> I've ever used it, however, at the point that I saw that it disabled = ACPI among >> other things, that it is more of a blanket option for anything and = everything >> that might be useful if/when you're having problems (*cough* still = can't say >> that I've ever used it, as when I have problems I'm usually slogging = through the >> kernel code, not relying on safe mode to fix some problem). >>=20 >> That being said, I felt that it was a huge improvement to the UI to = have the >> Safe Mode option divulge a little bit of its secret by visibly = diddling the ACPI >> menu item (giving a clue to people that *haven't* read the code that = this option >> is indeed not independent but instead conglomerate in-nature). >>=20 >> Indeed, I've watched field engineers when exploring the menu options = and their >> eyes light-up when they see that "Safe Mode" toggles ACPI off when = enabled. >> Extrapolating on their surprise, they appear to have an "Aha!"-moment = as >> previously... this field engineer had no idea what on God's green = Earth what >> "Safe Mode" did (or didn't) as he didn't know about "kenv" and = certainly >> couldn't read "Forth". At that point, he may not have had a full = understanding >> of all the options that Safe Mode diddled, but at that point he at = least knew >> that Safe Mode is a multi-option that does many things -- which is = more than >> 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe = Mode >> option is selected and does nothing to explain what it is that Safe = Mode is >> doing (which would in-turn properly calibrate the user's = expectations). >>=20 >> Making the menu items completely independent would be take away the = (however >> slight) above value-add that was brought in by entwining these two = menu-items. >> I'm not saying that this would be a grave travesty, but would in-fact = be a >> value-loss. >=20 > Devin, >=20 > you did a great job with boot menu enhancement in general and in this = area in > particular. You greatly improved usability while preserving the = historic behavior > and put a lot of work and creativity into that. Thank you! >=20 > But the argument is that the historic behavior is no longer useful. I = see that > removing the historic behavior also kills a little bit of your code = (and a little > bit of magic). That's true, that's a loss in the code. >=20 > But I still believe that it would be an improvement from the point of = view of > usability end-users. >=20 > Having a whole sub-menu where multiple parameters could be tweaked = individually > would be even greater improvement. But that's not as easy to do. >=20 > --=20 > Andriy Gapon From owner-freebsd-current@freebsd.org Sun Dec 11 22:46:25 2016 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 396D2C726CE for ; Sun, 11 Dec 2016 22:46:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 255031B18 for ; Sun, 11 Dec 2016 22:46:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 21A3BC726CD; Sun, 11 Dec 2016 22:46:25 +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 21375C726CC for ; Sun, 11 Dec 2016 22:46:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 D8D901B17 for ; Sun, 11 Dec 2016 22:46:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGCsv-0000Se-6N; Mon, 12 Dec 2016 01:46:21 +0300 Date: Mon, 12 Dec 2016 01:46:21 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211224621.GA90287@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161211211552.GL31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211211552.GL31311@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 22:46:25 -0000 On Mon, Dec 12, 2016 at 12:15:53AM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > > > > > === > > > > > > > > > Booting... > > > > > > > > > KDB: debugger backends: ddb > > > > > > > > > KDB: current backend: ddb > > > > > > > > So at least the hammer_time() has a chance to initialize the console. > > > > > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > > > This is verbose boot. > > > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > > > > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > > > fpuinit(); > > > > > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > > In particular, the SMAP lines should be relevant. > > > > > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > exit from kdb_init > > > > KDB: enter: Boot flags requested debugger > > > > [ thread pid 0 tid 0 ] > > > > Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq > > > > $0,0xffffffff80dcef20 = kdb_why > > > > > > > > No SMAP print, boot_verbose enabled. > > > The log above shows that you used boot -d. What are the pristine boot > > > messages, with debug.late_console set to 0, of course ? > > > > This is stable/11, no debug.late_console. > > Booting HEAD: > > panic: pmap_mapdev_attr: too many preinit mappings > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80535197 at ??+0 > #1 0xffffffff804eb0f2 at ??+0 > #2 0xffffffff804eaf63 at ??+0 > #3 0xffffffff807b5995 at ??+0 > #4 0xffffffff808479ca at ??+0 > #5 0xffffffff804079ea at ??+0 > #6 0xffffffff8040bb44 at ??+0 > #7 0xffffffff8047e178 at ??+0 > #8 0xffffffff807a47c3 at ??+0 > #9 0xffffffff8028f0a4 at ??+0 > Uptime: 1s Like this is debug.late_console=0 issuse. Same panic with NUMA disabled. Only set debug.late_console=1 allow to boot From owner-freebsd-current@freebsd.org Sun Dec 11 23:09:55 2016 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 0EDC1C73050 for ; Sun, 11 Dec 2016 23:09:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 EE576944 for ; Sun, 11 Dec 2016 23:09:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id EDB7CC73049; Sun, 11 Dec 2016 23:09:54 +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 ED5F2C73048 for ; Sun, 11 Dec 2016 23:09:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 B0792942 for ; Sun, 11 Dec 2016 23:09:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGDFf-0001Ay-PA; Mon, 12 Dec 2016 02:09:51 +0300 Date: Mon, 12 Dec 2016 02:09:51 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161211230951.GB90287@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161211211552.GL31311@zxy.spb.ru> <20161211224621.GA90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211224621.GA90287@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 11 Dec 2016 23:09:55 -0000 On Mon, Dec 12, 2016 at 01:46:21AM +0300, Slawa Olhovchenkov wrote: > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > > > In particular, the SMAP lines should be relevant. > > > > > > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > > exit from kdb_init > > > > > KDB: enter: Boot flags requested debugger > > > > > [ thread pid 0 tid 0 ] > > > > > Stopped at 0xffffffff805361eb = kdb_enter+0x3b: movq > > > > > $0,0xffffffff80dcef20 = kdb_why Hang at boot is result of combination next two BIOS setting: NUMA enabled Socket Interleave below 4G enabled (memory options) Disabling any allow boot. From owner-freebsd-current@freebsd.org Mon Dec 12 04:21:19 2016 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 5DC60C73EEE; Mon, 12 Dec 2016 04:21:19 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 ED1F9B1A; Mon, 12 Dec 2016 04:21:18 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-2ebff70000004ea7-c1-584e25b465f1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 9B.DE.20135.4B52E485; Sun, 11 Dec 2016 23:21:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id uBC4L8sk023164; Sun, 11 Dec 2016 23:21:08 -0500 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 uBC4L4oM029556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Dec 2016 23:21:07 -0500 Date: Sun, 11 Dec 2016 22:21:04 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2016Q4 quarterly status reports Message-ID: <20161212042104.GQ8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrbtV1S/C4PZybYs5bz4wWWzf/I/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZd1ZMZS6Yw13xa8E/1gbGNZxdjJwcEgImEm9mLWUE sYUE2pgkuhf5dzFyAdkbGSW+7bjJCOFcZZK43LOVHaSKRUBV4vfJc2A2m4CaxPoV15hBbBEB eYl9Te/B4sxA9q+tTWC2sIChxPeOLWAbeAWMJZYuXsoOYQtKnJz5hAWiXkvixr+XTF2MHEC2 tMTyfxwgYVEBZYmGGQ+YJzDyzULSMQtJxyyEjgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 DfVyM0v0UlNKNzGCQ02SZwfjmTdehxgFOBiVeHhnpPtGCLEmlhVX5h5ilORgUhLlZVwHFOJL yk+pzEgszogvKs1JLT7EKMHBrCTCy6viFyHEm5JYWZValA+TkuZgURLnvZTpHiEkkJ5Ykpqd mlqQWgSTleHgUJLgjQVpFCxKTU+tSMvMKUFIM3FwggznARq+XBlkeHFBYm5xZjpE/hSjopQ4 73yQhABIIqM0D64XlAoksvfXvGIUB3pFmLccZAUPMI3Adb8CGswENPj5Pm+QwSWJCCmpBsZz RpPiTlsuyJtWn3Ph5r9137kLrRUFJY+sVLw+9e3bWZ9uX3OL9NZZYNSV/dK0oewRy3fhKXuX Fd7M3jXnye9bVY1fxQPjXy87cj9p18LXvfvkLUzVzonwR5run5SuvYBn5xGXuqWuUoqbQ6Rm RIjEyYrNz40wajiz0Eo8bqXal37P4EKRj4xKLMUZiYZazEXFiQAJICN94AIAAA== 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, 12 Dec 2016 04:21:19 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is January 7, 2016, for work done in October through December. 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 2016Q4 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-2016-04-2016-06.html [5] https://www.FreeBSD.org/news/status/report-2016-07-2016-09.html From owner-freebsd-current@freebsd.org Mon Dec 12 13:19:16 2016 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 92716C73519 for ; Mon, 12 Dec 2016 13:19:16 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 58F5CA62 for ; Mon, 12 Dec 2016 13:19:16 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mail-io0-x22f.google.com with SMTP id a81so161546359ioe.3 for ; Mon, 12 Dec 2016 05:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ara-ler-com.20150623.gappssmtp.com; s=20150623; h=resent-from:resent-date:resent-message-id:resent-to:date:from:to :subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=Jckivju1Zq5TAyNO69Dkn7nPSqpBw4vJJ0gfhUHG6PQ=; b=NHme1X8JNBX8DBbrtA3X6lToEjDlUmTPpNqXY/G8sLM7/sgWuPmnbte3YCEexxku+Y 4z3ltnIn93vcBwzIYeDfRxo/Tm/rkhXFYMHOajVA6t9QEBOrOVviHrxr1M16GQ5/tfIB 87m96hZ/VZHjhQyUo/M7takm2F/5QFJNrtbcUWo6bMxV59ZgCjF9E5JOIV1+ekUojyEl ymMqXLsNbqPxapF5OmFNteWF/7y9Vv3f13nFWORVKw7fyt/VEI5kfZ6anoqDeDm1j0dP Wqh+fUcQQgxceXFc+BapckI3Hqhvd2KoibPkZjqR0lPZ4EV0l7kSjrTshm/7MX+RSC31 IpJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:resent-from:resent-date:resent-message-id :resent-to:date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Jckivju1Zq5TAyNO69Dkn7nPSqpBw4vJJ0gfhUHG6PQ=; b=UL0u+7tO8KoP5YJ+LldOSyN0J21AdGTDT93xGH0KvkVoy6GvbDtvuKxu0CepE2xEMJ XWM24ZR2ZhNTbHt7aplDI9ghKncpG6vJBbvRWi6S2qc54MYzUz5X18u09qbePFCrWvu2 6Lkm4E7Mpvw6Y8GYAvsAifUCZFACYcjsUSoIcLDGAhLdE8mRK8DuxhbOF8moEU2S8CYY HqTBTH7MKFKS8GWK1T37JfcGlaJ74iqWfhtGSbm6svvPDadAdeeWifnF97GriiGAbJG/ u6U+1yniBRS/9xqwMw59evJJZ72rgXnV44zLZj7vOXcgTdOyU6sKCbAbJrydBZ7rWt2Y 0xKA== X-Gm-Message-State: AKaTC025fy38qY3gJVSiapIMBJOUyOgdoQElfzVy/7tbgFS4INvZJAogTlX+fzCQh49tBQ== X-Received: by 10.107.59.9 with SMTP id i9mr82133122ioa.176.1481548754593; Mon, 12 Dec 2016 05:19:14 -0800 (PST) Received: from dendrobates.araler.com (71-212-252-17.hlrn.qwest.net. [71.212.252.17]) by smtp.gmail.com with ESMTPSA id h127sm19449799ioa.41.2016.12.12.05.19.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 05:19:14 -0800 (PST) Resent-From: Sergey Manucharian Resent-Date: Mon, 12 Dec 2016 06:19:12 -0700 Resent-Message-ID: <20161212131912.GE8743@dendrobates.araler.com> Resent-To: FreeBSD Current Date: Sun, 11 Dec 2016 08:33:47 -0700 From: Sergey Manucharian To: Matthias Gamsjager Subject: Re: Mac OS X on bhyve Message-ID: <20161211153347.GD8743@dendrobates.araler.com> References: <20161205174757.M9255@i805.com.br> <20161205193106.GA72310@neutralgood.org> <20161207223429.M39@i805.com.br> <584A2201.1000701@Wilcox-Tech.com> <584A715A.8020402@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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, 12 Dec 2016 13:19:16 -0000 Excerpts from Matthias Gamsjager's message from Fri 09-Dec-16 10:08: > On 9 December 2016 at 09:54, A. Wilcox wrote: > > > > And VirtualBox can boot Mac OS X without any bootloader or hacking, so > > it is much more stable, and resilient to automatic updates (which you > > need much experience to disable on newer releases, including macOS Sierra). > > > Assumed you run Virtualbox on OSX. This is not correct. I used to run it in vbox on Linux in ThinkPad T430. Haven't tried on FreeBSD though. Sergey From owner-freebsd-current@freebsd.org Mon Dec 12 14:54:24 2016 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 00B46C735BC for ; Mon, 12 Dec 2016 14:54:24 +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 DBC7C1E04 for ; Mon, 12 Dec 2016 14:54:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D7F61C735BB; Mon, 12 Dec 2016 14:54: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 D5F04C735BA for ; Mon, 12 Dec 2016 14:54:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75FF11E03 for ; Mon, 12 Dec 2016 14:54:23 +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 uBCEsIj0050302 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Dec 2016 16:54:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBCEsIj0050302 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBCEsIkU050301; Mon, 12 Dec 2016 16:54:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Dec 2016 16:54:18 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212145418.GF54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161211204709.GK31311@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 12 Dec 2016 14:54:24 -0000 On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > Booting... > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > KDB: current backend: ddb > exit from kdb_init > KDB: enter: Boot flags requested debugger > [ thread pid 0 tid 0 ] - remove any video consoles from the HEAD kernel config, i.e. sc/vt and vga/efi, - do not use boot -d, - use serial console (IPMI SOL qualifies), - set late console to 0, and show me the verbose dmesg of such boot with the BIOS options which cause troubles. > > > Hm, might be also show the output of the 'smap' and 'memmap' output from > > the loader. If any of them worked, could be useful to see the same output > > with the NUMA option disabled as well. > > NUMA disabled: > OK smap > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > SMAP type=02 base=000000007916b000 len=000000000093a000 attr=01 > SMAP type=04 base=0000000079aa5000 len=0000000000505000 attr=01 > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > NUMA enabled: > OK smap > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > OK memmap > memmap not found I.e. you use CMS in BIOS/legacy BIOS boot, right ? Can you double-check that the smap output is indeed same for all three cases (no-NUMA, NUMA without <4G interleave, NUMA with 4G interleave) ? msgbuf setup is very early activity and for most practical purposes it only depends on the physical segments layout of the machine. So I do expect that smap layout changes when the options are frobbed. From owner-freebsd-current@freebsd.org Mon Dec 12 16:22:02 2016 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 9DF4DC735B8 for ; Mon, 12 Dec 2016 16:22:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 899AC1B79 for ; Mon, 12 Dec 2016 16:22:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 88C5DC735B7; Mon, 12 Dec 2016 16:22: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 886BDC735B6 for ; Mon, 12 Dec 2016 16:22:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 4AC701B76 for ; Mon, 12 Dec 2016 16:22:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGTMP-0007HH-5l; Mon, 12 Dec 2016 19:21:53 +0300 Date: Mon, 12 Dec 2016 19:21:53 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212162152.GC90287@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212145418.GF54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 12 Dec 2016 16:22:02 -0000 On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > Booting... > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > KDB: current backend: ddb > > exit from kdb_init > > KDB: enter: Boot flags requested debugger > > [ thread pid 0 tid 0 ] > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > vga/efi, > - do not use boot -d, > - use serial console (IPMI SOL qualifies), > - set late console to 0, > and show me the verbose dmesg of such boot with the BIOS options > which cause troubles. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000099c00 SMAP type=02 base=0000000000099c00 len=0000000000006400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007906b000 SMAP type=02 base=000000007916b000 len=0000000000936000 SMAP type=04 base=0000000079aa1000 len=0000000000509000 SMAP type=02 base=0000000079faa000 len=0000000002056000 SMAP type=01 base=0000000100000000 len=0000001f80000000 SMAP type=02 base=000000007c000000 len=0000000014000000 SMAP type=02 base=00000000fed1c000 len=0000000000029000 SMAP type=02 base=00000000ff000000 len=0000000001000000 This is all. No more. > > > Hm, might be also show the output of the 'smap' and 'memmap' output from > > > the loader. If any of them worked, could be useful to see the same output > > > with the NUMA option disabled as well. > > > > NUMA disabled: > > OK smap > > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > > SMAP type=02 base=000000007916b000 len=000000000093a000 attr=01 > > SMAP type=04 base=0000000079aa5000 len=0000000000505000 attr=01 > > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > > NUMA enabled: > > OK smap > > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 > > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > > OK memmap > > memmap not found > > I.e. you use CMS in BIOS/legacy BIOS boot, right ? legacy BIOS boot, yes > Can you double-check that the smap output is indeed same for all three > cases (no-NUMA, NUMA without <4G interleave, NUMA with 4G interleave) ? NUMA=ON 4G interleave=ON SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 NUMA=ON 4G interleave=OFF SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 NUMA=OFF 4G interleave=ON SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=000000000093a000 attr=01 SMAP type=04 base=0000000079aa5000 len=0000000000505000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > msgbuf setup is very early activity and for most practical purposes it > only depends on the physical segments layout of the machine. So I do > expect that smap layout changes when the options are frobbed. From owner-freebsd-current@freebsd.org Mon Dec 12 16:55:09 2016 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 B9A19C73530 for ; Mon, 12 Dec 2016 16:55:09 +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 A0084154A for ; Mon, 12 Dec 2016 16:55:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9C8B3C7352F; Mon, 12 Dec 2016 16:55: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 9C36BC7352E for ; Mon, 12 Dec 2016 16:55:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 192741546 for ; Mon, 12 Dec 2016 16:55:08 +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 uBCGsvto079257 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Dec 2016 18:54:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBCGsvto079257 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBCGsv4k079256; Mon, 12 Dec 2016 18:54:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Dec 2016 18:54:57 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212165457.GI54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212162152.GC90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 12 Dec 2016 16:55:09 -0000 On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > Booting... > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > exit from kdb_init > > > KDB: enter: Boot flags requested debugger > > > [ thread pid 0 tid 0 ] > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > vga/efi, > > - do not use boot -d, > > - use serial console (IPMI SOL qualifies), > > - set late console to 0, > > and show me the verbose dmesg of such boot with the BIOS options > > which cause troubles. > > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=0000000000099c00 > SMAP type=02 base=0000000000099c00 len=0000000000006400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000007906b000 > SMAP type=02 base=000000007916b000 len=0000000000936000 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > SMAP type=02 base=0000000079faa000 len=0000000002056000 > SMAP type=01 base=0000000100000000 len=0000001f80000000 > SMAP type=02 base=000000007c000000 len=0000000014000000 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > This is all. No more. When you switch between variations of the NUMA enablement options, do you just reboot the machine or do you sometimes physically turn it off ? Try to enable memtest, with the hw.memtest.tests=1 loader variable. Does it change things ? From owner-freebsd-current@freebsd.org Mon Dec 12 17:16:36 2016 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 AF165C73070 for ; Mon, 12 Dec 2016 17:16:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6C38D2 for ; Mon, 12 Dec 2016 17:16:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 90A9CC7306F; Mon, 12 Dec 2016 17:16:36 +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 903B4C7306E for ; Mon, 12 Dec 2016 17:16:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 51C298D1 for ; Mon, 12 Dec 2016 17:16:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGUDK-0008o5-C9; Mon, 12 Dec 2016 20:16:34 +0300 Date: Mon, 12 Dec 2016 20:16:34 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212171634.GD90287@zxy.spb.ru> References: <20161126155747.GF54029@kib.kiev.ua> <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212165457.GI54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 12 Dec 2016 17:16:36 -0000 On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > Booting... > > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > exit from kdb_init > > > > KDB: enter: Boot flags requested debugger > > > > [ thread pid 0 tid 0 ] > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > vga/efi, > > > - do not use boot -d, > > > - use serial console (IPMI SOL qualifies), > > > - set late console to 0, > > > and show me the verbose dmesg of such boot with the BIOS options > > > which cause troubles. > > > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > > This is all. No more. > When you switch between variations of the NUMA enablement options, do > you just reboot the machine or do you sometimes physically turn it off ? just reboot an 'power reset' via kvm client (memory preserved, i mean) > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > Does it change things ? System booted, dmesg is http://zxy.spb.ru/dmesg.numa # sysctl vm.ndomains vm.default_policy vm.phys_locality vm.phys_segs vm.ndomains: 1 vm.default_policy: rr sysctl: unknown oid 'vm.phys_locality' vm.phys_segs: SEGMENT 0: start: 0x10000 end: 0x96000 domain: 0 free list: 0xffffffff80caabc0 SEGMENT 1: start: 0x100000 end: 0x200000 domain: 0 free list: 0xffffffff80caabc0 SEGMENT 2: start: 0x15c1000 end: 0x15ed000 domain: 0 free list: 0xffffffff80caa950 SEGMENT 3: start: 0x15ee000 end: 0x7916b000 domain: 0 free list: 0xffffffff80caa950 SEGMENT 4: start: 0x100000000 end: 0x1f6d8ae000 domain: 0 free list: 0xffffffff80caa6e0 From owner-freebsd-current@freebsd.org Mon Dec 12 17:24:27 2016 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 DDE8AC73455 for ; Mon, 12 Dec 2016 17:24:27 +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 C4312F49 for ; Mon, 12 Dec 2016 17:24:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C38E3C73454; Mon, 12 Dec 2016 17:24:27 +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 C33CFC73452 for ; Mon, 12 Dec 2016 17:24:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50EF8F48 for ; Mon, 12 Dec 2016 17:24:27 +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 uBCHOIuM086509 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Dec 2016 19:24:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBCHOIuM086509 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBCHOI20086508; Mon, 12 Dec 2016 19:24:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Dec 2016 19:24:18 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212172418.GK54029@kib.kiev.ua> References: <20161211182111.GH31311@zxy.spb.ru> <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212171634.GD90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 12 Dec 2016 17:24:28 -0000 On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > > Booting... > > > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > > exit from kdb_init > > > > > KDB: enter: Boot flags requested debugger > > > > > [ thread pid 0 tid 0 ] > > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > > vga/efi, > > > > - do not use boot -d, > > > > - use serial console (IPMI SOL qualifies), > > > > - set late console to 0, > > > > and show me the verbose dmesg of such boot with the BIOS options > > > > which cause troubles. > > > > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > > > > This is all. No more. > > When you switch between variations of the NUMA enablement options, do > > you just reboot the machine or do you sometimes physically turn it off ? > > just reboot an 'power reset' via kvm client (memory preserved, i mean) > > > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > > Does it change things ? > > System booted, dmesg is http://zxy.spb.ru/dmesg.numa I suspect now the reversed situation could take place, the non-interleaved option would cause hang. My current guess is that memory content is preserved but swizzled by the cache line sized chunks. So that the msgbuf header, left after the previous boot, looks correct while the real buffer content is shuffled. Try the debugging patch below, which unconditionally disables import of previous buffer. To test, you would need to boot, then frob options in BIOS, reboot, again frob etc. diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..d45ef502204 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { msgbuf_init(mbp, ptr, size); return; } From owner-freebsd-current@freebsd.org Mon Dec 12 17:43:15 2016 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 17FCEC73C34 for ; Mon, 12 Dec 2016 17:43:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 032FD1F7F for ; Mon, 12 Dec 2016 17:43:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 027BEC73C33; Mon, 12 Dec 2016 17:43:15 +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 02216C73C32 for ; Mon, 12 Dec 2016 17:43:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 B7E901F7D for ; Mon, 12 Dec 2016 17:43:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGUd5-0009dm-JB; Mon, 12 Dec 2016 20:43:11 +0300 Date: Mon, 12 Dec 2016 20:43:11 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212174311.GE90287@zxy.spb.ru> References: <20161211191626.GI31311@zxy.spb.ru> <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212172418.GK54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 12 Dec 2016 17:43:15 -0000 On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote: > On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > > > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > > > Booting... > > > > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > > > > KDB: current backend: ddb > > > > > > exit from kdb_init > > > > > > KDB: enter: Boot flags requested debugger > > > > > > [ thread pid 0 tid 0 ] > > > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > > > vga/efi, > > > > > - do not use boot -d, > > > > > - use serial console (IPMI SOL qualifies), > > > > > - set late console to 0, > > > > > and show me the verbose dmesg of such boot with the BIOS options > > > > > which cause troubles. > > > > > > > > Booting... > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > > > > > > This is all. No more. > > > When you switch between variations of the NUMA enablement options, do > > > you just reboot the machine or do you sometimes physically turn it off ? > > > > just reboot an 'power reset' via kvm client (memory preserved, i mean) > > > > > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > > > Does it change things ? > > > > System booted, dmesg is http://zxy.spb.ru/dmesg.numa > I suspect now the reversed situation could take place, the non-interleaved > option would cause hang. No, also booted, dmesg http://zxy.spb.ru/dmesg.numa-ninter > My current guess is that memory content is preserved but swizzled by > the cache line sized chunks. So that the msgbuf header, left after the > previous boot, looks correct while the real buffer content is shuffled. > > Try the debugging patch below, which unconditionally disables import of > previous buffer. To test, you would need to boot, then frob options in > BIOS, reboot, again frob etc. still need test patch? if yes, with BIOS options? > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c > index f275aef3b4f..d45ef502204 100644 > --- a/sys/kern/subr_msgbuf.c > +++ b/sys/kern/subr_msgbuf.c > @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) > { > u_int cksum; > > - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > msgbuf_init(mbp, ptr, size); > return; > } From owner-freebsd-current@freebsd.org Mon Dec 12 18:36:53 2016 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 D039FC74F16 for ; Mon, 12 Dec 2016 18:36:53 +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 B5DA514CB for ; Mon, 12 Dec 2016 18:36:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B248EC74F15; Mon, 12 Dec 2016 18:36:53 +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 B1F0EC74F14 for ; Mon, 12 Dec 2016 18:36:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE3B14CA for ; Mon, 12 Dec 2016 18:36:53 +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 uBCIalNg004940 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Dec 2016 20:36:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBCIalNg004940 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBCIalJA004939; Mon, 12 Dec 2016 20:36:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Dec 2016 20:36:47 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212183647.GL54029@kib.kiev.ua> References: <20161211192656.GZ54029@kib.kiev.ua> <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212174311.GE90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 12 Dec 2016 18:36:54 -0000 On Mon, Dec 12, 2016 at 08:43:11PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote: > > > On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > > > > > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > > > > Booting... > > > > > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > > > > > KDB: current backend: ddb > > > > > > > exit from kdb_init > > > > > > > KDB: enter: Boot flags requested debugger > > > > > > > [ thread pid 0 tid 0 ] > > > > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > > > > vga/efi, > > > > > > - do not use boot -d, > > > > > > - use serial console (IPMI SOL qualifies), > > > > > > - set late console to 0, > > > > > > and show me the verbose dmesg of such boot with the BIOS options > > > > > > which cause troubles. > > > > > > > > > > Booting... > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > > > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > > > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > > > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > > > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > > > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > > > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > > > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > > > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > > > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > > > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > > > > > > > > This is all. No more. > > > > When you switch between variations of the NUMA enablement options, do > > > > you just reboot the machine or do you sometimes physically turn it off ? > > > > > > just reboot an 'power reset' via kvm client (memory preserved, i mean) > > > > > > > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > > > > Does it change things ? > > > > > > System booted, dmesg is http://zxy.spb.ru/dmesg.numa > > I suspect now the reversed situation could take place, the non-interleaved > > option would cause hang. > > No, also booted, dmesg http://zxy.spb.ru/dmesg.numa-ninter I mean, it could hang if memory testing is not enabled. > > > My current guess is that memory content is preserved but swizzled by > > the cache line sized chunks. So that the msgbuf header, left after the > > previous boot, looks correct while the real buffer content is shuffled. > > > > Try the debugging patch below, which unconditionally disables import of > > previous buffer. To test, you would need to boot, then frob options in > > BIOS, reboot, again frob etc. > > still need test patch? if yes, with BIOS options? Yes, please test the patch. I explained the procedure above. > > > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c > > index f275aef3b4f..d45ef502204 100644 > > --- a/sys/kern/subr_msgbuf.c > > +++ b/sys/kern/subr_msgbuf.c > > @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) > > { > > u_int cksum; > > > > - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > > + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > > msgbuf_init(mbp, ptr, size); > > return; > > } From owner-freebsd-current@freebsd.org Mon Dec 12 19:26:22 2016 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 7CAB5C73DB4 for ; Mon, 12 Dec 2016 19:26:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 67FA81823 for ; Mon, 12 Dec 2016 19:26:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 6450AC73DB3; Mon, 12 Dec 2016 19:26:22 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63F1BC73DB2 for ; Mon, 12 Dec 2016 19:26:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 24CCE1822 for ; Mon, 12 Dec 2016 19:26:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGWEt-000CmX-6U; Mon, 12 Dec 2016 22:26:19 +0300 Date: Mon, 12 Dec 2016 22:26:19 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212192619.GF90287@zxy.spb.ru> References: <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212183647.GL54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 12 Dec 2016 19:26:22 -0000 On Mon, Dec 12, 2016 at 08:36:47PM +0200, Konstantin Belousov wrote: > On Mon, Dec 12, 2016 at 08:43:11PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote: > > > > > On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > > > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > Booting... > > > > > > > > ESC[01;00H8+0x8+0xe9bdc] KDB: debugger backends: ddb > > > > > > > > KDB: current backend: ddb > > > > > > > > exit from kdb_init > > > > > > > > KDB: enter: Boot flags requested debugger > > > > > > > > [ thread pid 0 tid 0 ] > > > > > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > > > > > vga/efi, > > > > > > > - do not use boot -d, > > > > > > > - use serial console (IPMI SOL qualifies), > > > > > > > - set late console to 0, > > > > > > > and show me the verbose dmesg of such boot with the BIOS options > > > > > > > which cause troubles. > > > > > > > > > > > > Booting... > > > > > > KDB: debugger backends: ddb > > > > > > KDB: current backend: ddb > > > > > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > > > > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > > > > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > > > > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > > > > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > > > > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > > > > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > > > > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > > > > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > > > > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > > > > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > > > > > > > > > > This is all. No more. > > > > > When you switch between variations of the NUMA enablement options, do > > > > > you just reboot the machine or do you sometimes physically turn it off ? > > > > > > > > just reboot an 'power reset' via kvm client (memory preserved, i mean) > > > > > > > > > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > > > > > Does it change things ? > > > > > > > > System booted, dmesg is http://zxy.spb.ru/dmesg.numa > > > I suspect now the reversed situation could take place, the non-interleaved > > > option would cause hang. > > > > No, also booted, dmesg http://zxy.spb.ru/dmesg.numa-ninter > I mean, it could hang if memory testing is not enabled. realy? system boot w/o memory testing when NUMA ON and interleave OFF: I am already report about boot after off interleave. > > > > > My current guess is that memory content is preserved but swizzled by > > > the cache line sized chunks. So that the msgbuf header, left after the > > > previous boot, looks correct while the real buffer content is shuffled. > > > > > > Try the debugging patch below, which unconditionally disables import of > > > previous buffer. To test, you would need to boot, then frob options in > > > BIOS, reboot, again frob etc. > > > > still need test patch? if yes, with BIOS options? > Yes, please test the patch. I explained the procedure above. sorry, i don't know 'frob'. what exactly options combination I need test and what about memory test? > > > > > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c > > > index f275aef3b4f..d45ef502204 100644 > > > --- a/sys/kern/subr_msgbuf.c > > > +++ b/sys/kern/subr_msgbuf.c > > > @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) > > > { > > > u_int cksum; > > > > > > - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > > > + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > > > msgbuf_init(mbp, ptr, size); > > > return; > > > } From owner-freebsd-current@freebsd.org Mon Dec 12 22:20:57 2016 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 43174C74E46 for ; Mon, 12 Dec 2016 22:20:57 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.foxkit.us [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 297651215 for ; Mon, 12 Dec 2016 22:20:56 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 28789 invoked from network); 12 Dec 2016 22:20:48 -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.foxkit.us with ESMTPA; 12 Dec 2016 22:20:48 -0000 Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: freebsd-current@freebsd.org References: <20161211194559.GJ31311@zxy.spb.ru> <20161211200654.GA54029@kib.kiev.ua> <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> From: "A. Wilcox" Message-ID: <584F22B1.9000903@Wilcox-Tech.com> Date: Mon, 12 Dec 2016 16:20:33 -0600 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: <20161212192619.GF90287@zxy.spb.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jXMwRRPw5XorIXo0UI92I4Qxj23oAUCau" 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, 12 Dec 2016 22:20:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jXMwRRPw5XorIXo0UI92I4Qxj23oAUCau Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>> Try the debugging patch below, which unconditionally disables import= of >>>> previous buffer. To test, you would need to boot, then frob options= in >>>> BIOS, reboot, again frob etc. >>> >>> still need test patch? if yes, with BIOS options? >> Yes, please test the patch. I explained the procedure above. >=20 > sorry, i don't know 'frob'. > what exactly options combination I need test and what about memory test= ? >=20 The idea is that when rebooting, stale memory contents remain, but are corrupted due to interleave. "Frob" basically means "mess with". So apply patch, test kernel, reboot, change NUMA option, reboot again, see if it works, and so on. Basically repeat your test with the NUMA=3Don interleave=3Don, NUMA=3Doff= interleave=3Don, etc etc. hth, --arw --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --jXMwRRPw5XorIXo0UI92I4Qxj23oAUCau 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 iQIcBAEBCAAGBQJYTyKyAAoJEMspy1GSK50Uy1sP/1YU7gk3dGVBU3Uo62HbLaxo +Z4t+d/3p38IC2p6WZAAxojMOIwV768TrF3KEySAWcRCDGC3KP4LiaBccL7qzWk1 VrfHy+zTWqUcuNdj9/DAT0Y3rZlDKkFwtJLS4VtXr3GWQz7lwl/0atgDbexg95+T 0AmtP/BIiSX2l5J21UpGPadyiabK9SL1AQNafJEROaTDh3Dro+m+EEytvu9275IA EecNXXjSmOuULSX3xhtt4ocOpKC7rRmy5lZewSn2YDE/eMOLsppWTZ6S5WO+VT7D pnTyqdjs5aLOuWa/96ZkjDmM9rMXCgXrdd5MQogmSe3r2KErI7anruZ68ykNoHBr OZLckyeA5nA9NFWmPxLcW+X3iPPKDik9BZX6iumwvGsl+lhDUOb8Db0Ssvr1B/lh ssIjw6pacBOPF0pmKwseA4fDWwH7bF9mXJfsI/Nga3Q2hkpMF2ncetsLvULrQP48 keFSN7Tyutoim/qsO3rgqRbWRTW9gjUtO7r+1BRmYBMrYpUwAjElUhIc0kwTvk3n UppA4jAJlibhME52lbcuCcUgIiL5zjiZp0Hv3ywRZfNfg88pUGl5hElBK5PkeduG m/x+FWlCZxmMUuG0RlMOCboFBnUjKXH+2tJyyv7Fcg4uhwIiXFUJFuf/yoQd6nfb ppv4SQiNWv3Zy4YaOv9X =vLtk -----END PGP SIGNATURE----- --jXMwRRPw5XorIXo0UI92I4Qxj23oAUCau-- From owner-freebsd-current@freebsd.org Mon Dec 12 22:33:22 2016 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 1F55CC7418A; Mon, 12 Dec 2016 22:33:22 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1207318BA; Mon, 12 Dec 2016 22:33:22 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2C282284; Mon, 12 Dec 2016 22:33:22 +0000 (UTC) Date: Mon, 12 Dec 2016 22:33:19 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: pfg@FreeBSD.org, mjg@FreeBSD.org, manu@FreeBSD.org, dteske@FreeBSD.org, hrs@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1254499632.82.1481582002190.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <470543023.80.1481573991379.JavaMail.jenkins@jenkins-9.freebsd.org> References: <470543023.80.1481573991379.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #4365 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 22:33:22 -0000 FreeBSD_HEAD_i386 - Build #4365 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4365/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4365/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4365/console Change summaries: 309945 by dteske: 1 is the default descriptor for redirects without an fd prefix 309944 by dteske: Fix invalid parameter expansion (change $@ to "$@") Without quotes, $@ loses its special meanining (see below) % sh -c 'echo $@' /bin/sh " 1 " " 2 " 1 2 % sh -c 'echo "$@"' /bin/sh " 1 " " 2 " 1 2 The quotes are required to get ARGV to be unperterped 309942 by dteske: Allow the script path to contain whitespace and special characters 309941 by dteske: Use provided API to centralize dialog title strings 309940 by dteske: Reorder dialog parameters based on commonality for readability 309939 by dteske: Fix incorrect use of provided API The result of which was incorrectly sized menu dialogs 309938 by dteske: Use provided API (change "dialog" to "$DIALOG") 309937 by dteske: Whitespace (dialog options separated to minimize diffs) 309936 by pfg: ed(1): Simplify some checks. The return type for both fread(3) and fwrite(3) cannot be negative, this renders some checks invalid and variable 'ct' unnecessary. Also bump 'len' to size_t to avoid signed/unsigned comparison warnings. 309935 by manu: Use the spibus accessor when applicable. MFC after: 3 days 309934 by dteske: Consolidate redirects into here documents, with proper code indentation 309933 by hrs: - Refactor listening socket list. All of the listening sockets are now maintained in a single linked-list in a transport-independent manner. - Use queue.h for linked-list structure. - Use linked-list for AllowedPeers. - Use getaddrinfo(8) even for Unix Domain sockets. - Use macros to type-casting from/to struct sockaddr{,_in,_in6}. - Define fu_* macro for union f_un to shorten the member names. - Remove an extra #include . - Add "static" to non-exported symbols. - !INET support is still incomplete but will be fixed later. There is no functional change except for some minor debug messages. 309932 by dteske: Remove an unnecessary "return $?" at end of function 309931 by hrs: Temporarily backout the previous commit because it was totally broken due to unresolved merge conflicts. Pointy hat to: hrs 309930 by dteske: Use ternary operator 309929 by mjg: vfs: use vrefact in getcwd and fchdir From owner-freebsd-current@freebsd.org Mon Dec 12 23:37:19 2016 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 A8A10C743E1 for ; Mon, 12 Dec 2016 23:37:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 61A811DF3 for ; Mon, 12 Dec 2016 23:37:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGa9j-000LCQ-11; Tue, 13 Dec 2016 02:37:15 +0300 Date: Tue, 13 Dec 2016 02:37:14 +0300 From: Slawa Olhovchenkov To: "A. Wilcox" Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161212233714.GA90401@zxy.spb.ru> References: <20161211204709.GK31311@zxy.spb.ru> <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <584F22B1.9000903@Wilcox-Tech.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 12 Dec 2016 23:37:19 -0000 On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > >>>> Try the debugging patch below, which unconditionally disables import of > >>>> previous buffer. To test, you would need to boot, then frob options in > >>>> BIOS, reboot, again frob etc. > >>> > >>> still need test patch? if yes, with BIOS options? > >> Yes, please test the patch. I explained the procedure above. > > > > sorry, i don't know 'frob'. > > what exactly options combination I need test and what about memory test? > > > > > The idea is that when rebooting, stale memory contents remain, but are > corrupted due to interleave. > > "Frob" basically means "mess with". So apply patch, test kernel, > reboot, change NUMA option, reboot again, see if it works, and so on. > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > interleave=on, etc etc. NUMA=on interleave=off booted NUMA=on interleave=on hang I think different combination whatever? From owner-freebsd-current@freebsd.org Tue Dec 13 11:05:41 2016 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 5F6D6C75030 for ; Tue, 13 Dec 2016 11:05:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D08641687 for ; Tue, 13 Dec 2016 11:05: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 uBDB5ZLw028451 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 13:05:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDB5ZLw028451 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDB5Z00028447; Tue, 13 Dec 2016 13:05:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 13:05:35 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213110535.GS54029@kib.kiev.ua> References: <20161212145418.GF54029@kib.kiev.ua> <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161212233714.GA90401@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 11:05:41 -0000 On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > >>>> Try the debugging patch below, which unconditionally disables import of > > >>>> previous buffer. To test, you would need to boot, then frob options in > > >>>> BIOS, reboot, again frob etc. > > >>> > > >>> still need test patch? if yes, with BIOS options? > > >> Yes, please test the patch. I explained the procedure above. > > > > > > sorry, i don't know 'frob'. > > > what exactly options combination I need test and what about memory test? > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > corrupted due to interleave. > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > reboot, change NUMA option, reboot again, see if it works, and so on. > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > interleave=on, etc etc. > > NUMA=on interleave=off booted > NUMA=on interleave=on hang > > I think different combination whatever? Do you mean, that both patched kernel, and unpatched kernel with the memory test enabled, hang when NUMA and interleave options enabled ? Could you enable the options, power down the machine for 10-20 minutes, and try to boot ? From owner-freebsd-current@freebsd.org Tue Dec 13 11:14:41 2016 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 56930C7543D for ; Tue, 13 Dec 2016 11:14:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 194A81C2E for ; Tue, 13 Dec 2016 11:14:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGl2b-000IJG-9Z; Tue, 13 Dec 2016 14:14:37 +0300 Date: Tue, 13 Dec 2016 14:14:37 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213111437.GH90287@zxy.spb.ru> References: <20161212162152.GC90287@zxy.spb.ru> <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213110535.GS54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 11:14:41 -0000 On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > >>>> Try the debugging patch below, which unconditionally disables import of > > > >>>> previous buffer. To test, you would need to boot, then frob options in > > > >>>> BIOS, reboot, again frob etc. > > > >>> > > > >>> still need test patch? if yes, with BIOS options? > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > sorry, i don't know 'frob'. > > > > what exactly options combination I need test and what about memory test? > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > corrupted due to interleave. > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > interleave=on, etc etc. > > > > NUMA=on interleave=off booted > > NUMA=on interleave=on hang > > > > I think different combination whatever? > > Do you mean, that both patched kernel, and unpatched kernel with the > memory test enabled, hang when NUMA and interleave options enabled ? Unpatched kernel boot with the memory test enabled when NUMA and interleave options enabled -- I am already reported this. patched kernel with the memory test enabled boot too. i.e. memory test enabled allow boot in any situation. > Could you enable the options, power down the machine for 10-20 minutes, > and try to boot ? For with kernel and bios options and boot options? I am have two day befor server put in production for any expirements, but please, be more clear in what combination need to test. From owner-freebsd-current@freebsd.org Tue Dec 13 11:23:47 2016 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 907DBC75753 for ; Tue, 13 Dec 2016 11:23:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 379AE1F7 for ; Tue, 13 Dec 2016 11:23: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 uBDBNgFh032895 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 13:23:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDBNgFh032895 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDBNeBY032894; Tue, 13 Dec 2016 13:23:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 13:23:40 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213112340.GT54029@kib.kiev.ua> References: <20161212165457.GI54029@kib.kiev.ua> <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213111437.GH90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 11:23:47 -0000 On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > > > >>>> Try the debugging patch below, which unconditionally disables import of > > > > >>>> previous buffer. To test, you would need to boot, then frob options in > > > > >>>> BIOS, reboot, again frob etc. > > > > >>> > > > > >>> still need test patch? if yes, with BIOS options? > > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > > > sorry, i don't know 'frob'. > > > > > what exactly options combination I need test and what about memory test? > > > > > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > > corrupted due to interleave. > > > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > > interleave=on, etc etc. > > > > > > NUMA=on interleave=off booted > > > NUMA=on interleave=on hang > > > > > > I think different combination whatever? > > > > Do you mean, that both patched kernel, and unpatched kernel with the > > memory test enabled, hang when NUMA and interleave options enabled ? > > Unpatched kernel boot with the memory test enabled when NUMA and > interleave options enabled -- I am already reported this. > > patched kernel with the memory test enabled boot too. > > i.e. memory test enabled allow boot in any situation. Then what about was the statement above ? You said that NUMA and interleave on caused hang. Was that on the patched kernel ? > > > Could you enable the options, power down the machine for 10-20 minutes, > > and try to boot ? > > For with kernel and bios options and boot options? > I am have two day befor server put in production for any expirements, > but please, be more clear in what combination need to test. Boot with NUMA enabled and interleave off. Patch kernel with the 'if (1 || ...)' patch. Reboot, enter BIOS setup and enable interleave there. Try to boot - does it boot ? If it did not booted, power machine off for 10 minutes. Power it on, try to boot (with the same patched kernel). Does the machine boot now ? From owner-freebsd-current@freebsd.org Tue Dec 13 04:08:56 2016 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 3134DC74CFB for ; Tue, 13 Dec 2016 04:08:56 +0000 (UTC) (envelope-from louise9841@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 12A74CDB for ; Tue, 13 Dec 2016 04:08:56 +0000 (UTC) (envelope-from louise9841@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 120A7C74CFA; Tue, 13 Dec 2016 04:08:56 +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 11AF1C74CF9 for ; Tue, 13 Dec 2016 04:08:56 +0000 (UTC) (envelope-from louise9841@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D54D1CDA for ; Tue, 13 Dec 2016 04:08:55 +0000 (UTC) (envelope-from louise9841@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id v84so110736812oie.3 for ; Mon, 12 Dec 2016 20:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=1UI6gNE0mHPbJWjEkDwKV9EUe42c9gRDj+nzDQuIfYE=; b=MwmJoF5cqrYk3CgjBvJtbJdIQmWJnVJ4elwQ113Q9ort1A6heHiIHHuVnGQnTWzdtg UxN2+z4Sh1ak420rKfV9zi1aPXLwYZ6QFPSxjr1qM2KHgtAXqUp/V5n0rSLQU3up2LD/ RwmeAPcmsgPFPOalt8qF5fB4KmIjJ1NPtibLz708bpKTx/nsRbs3/UfJH8GAUEwin2Ws krvAQIEONUrnod/yD4/fFVgHrBmb8a+Fox/BkcT8UVfKlhE7HmtIQgIui/50wVd5+5ha qsOmdoXcKkdiSJmi1ANy9H1gBlQhOzcgIrj3PAfnuRgp3A91bJ2MtYCcQGaDhkME+/gJ xuxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1UI6gNE0mHPbJWjEkDwKV9EUe42c9gRDj+nzDQuIfYE=; b=YxOLeN7AJ6vrBIsEkgvBy0T+wn1hJA3iYukBbQ0mceKGpu+mPBrJ4T4GblN3K8+P7s xIOSYw466gLVVNNavtalxo6ve7DVhwhG+mCYBE/KkJvIXxxQfsAfOVUrnJq2Itq37Y0X Yg8LKYKECHX8s+dc88QnDk0SdsfobXOSqCpsluoE0ZZ3ZQB4B8Gzh5owIiYZLYm6o25F xSvi/aic2YAWe4wGtZguZeTH+CfasqFp4kglUYEySiqrKu8RkGrV7n6+4xqS2NtVBHqL 2FbanVRa3hfwZmtiRTwJRE1NL/3DbFBjFaqw0zVpO6MyzgooboQUDjWWIgnTy4O3fhlN G7xg== X-Gm-Message-State: AKaTC015W6s9irAPp7muORMnolMX9X0fB6LP5/kZQKv1O5ZXQ1XVvFOImX4R2v8apF8u6WXycb6ppiWGu8o6sQ== X-Received: by 10.202.239.84 with SMTP id n81mr49750736oih.94.1481602135115; Mon, 12 Dec 2016 20:08:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.97.103 with HTTP; Mon, 12 Dec 2016 20:08:54 -0800 (PST) Received: by 10.182.97.103 with HTTP; Mon, 12 Dec 2016 20:08:54 -0800 (PST) From: Lewis ingraham Date: Mon, 12 Dec 2016 20:08:54 -0800 Message-ID: Subject: Help To: current@freebsd.org X-Mailman-Approved-At: Tue, 13 Dec 2016 11:59:48 +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: Tue, 13 Dec 2016 04:08:56 -0000 Hi FreeBSD Current Team, I need help with a few things: 1. I tried getting help from all kinds of irc chats but still no dice. 2. I cannot get my soundcard to work on FreeBSD. It is the Soundblaster Z(SB1500, SB1502) with the CA0132 codec. 3.Also i tried to get pipelight to work but doesnt work well on 64 bit and for some reason firefox wont detect pipelight plugins version 50.0.2 newest version available from ports. 4. Another potential problem with usb drive detection as well. Usb ports work just fine in something like windows and linux but not FreeBSD. I really LOVE FreeBSD i use it for workstation applications and professional use as well. Is there any way i could be referred to someone to can code the drivers needed to work with my hardware?? And possibly someone who could help me with my software problems. Thank you, FreeBSD Supporter From owner-freebsd-current@freebsd.org Tue Dec 13 11:02:56 2016 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 2D1F2C72F69 for ; Tue, 13 Dec 2016 11:02:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1C02F15D2; Tue, 13 Dec 2016 11:02:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1917A298; Tue, 13 Dec 2016 11:02:56 +0000 (UTC) Date: Tue, 13 Dec 2016 11:02:54 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: cem@FreeBSD.org, cperciva@FreeBSD.org, manu@FreeBSD.org, dteske@FreeBSD.org, mizhka@FreeBSD.org, kib@FreeBSD.org, hrs@FreeBSD.org, ae@FreeBSD.org, pfg@FreeBSD.org, mjg@FreeBSD.org, andrew@FreeBSD.org, loos@FreeBSD.org, jilles@FreeBSD.org, br@FreeBSD.org, ed@FreeBSD.org, alc@FreeBSD.org, jchandra@FreeBSD.org, trasz@FreeBSD.org, gonzo@FreeBSD.org, robak@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1792565640.84.1481626976123.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <190791288.78.1481540570632.JavaMail.jenkins@jenkins-9.freebsd.org> References: <190791288.78.1481540570632.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1731 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Tue, 13 Dec 2016 12:10:49 +0000 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 11:02:56 -0000 FreeBSD_HEAD_amd64_gcc - Build #1731 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1= 731/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/173= 1/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1731= /console Change summaries: 310018 by mizhka: [gpiospi] add clock delay to avoid smashing of bits Submitted by:=09Hiroki Mori Reviewed by:=09loos, ray, mizhka MFC after:=092 weeks Differential Revision:=09https://reviews.freebsd.org/D8749 310017 by mizhka: [spi] reformat message and ar5315_spi minor fix This commit corrects print of nomatch (newline was too early) and fix unit number for new child in ar5315_spi (was 0, now is -1 to calculate it according to actual system state) Submitted by:=09Hiroki Mori Reviewed by:=09ray, loos, mizhka MFC after:=092 weeks Differential Revision:=09https://reviews.freebsd.org/D8749 310014 by ed: Remove the only user of sysctl_add_oid(). My plan is to change this function's prototype at some point in the future to add a new label argument, which can be used to export all of sysctl as metrics that can be scraped by Prometheus. Switch over this caller to use the macro wrapper counterpart. 310013 by cperciva: Check that blkfront devices have a non-zero number of sectors and a non-zero sector size. Such a device would be a virtual disk of zero bytes; clearly not useful, and not something we should try to attach. As a fortuitous side effect, checking that these values are non-zero here results in them not *becoming* zero later on the function. This odd behaviour began with r309124 (clang 3.9.0) but is challenging to debug; making any changes to this function whatsoever seems to affect the llvm optimizer behaviour enough to make the unexpected zeroing of the sector_size variable cease. PR:=09=09215209 Security:=09The potential for variables to unexpectedly become zero =09=09has worrying consequences for security in general, but =09=09not so much in this particular context. 310012 by gonzo: [iMX6] Add compatibility string for GPT timer on i.MX6 Dual Up until r295436 GPT timer in i.MX6 Dual dts used the same compatiblity string as i.MX6 Quad. After the sync up with Linux in r295436, GPT timer stopped getting attached on the i.MX6 Dual MFC after:=093 days 310000 by loos: Remove a too strict test and instead, just filter the passed flags with the supported capabilities. Spotted by:=09yamori813@yahoo.co.jp (Hiroki Mori) MFC after:=092 weeks 309999 by gonzo: [iMX6] Fix platform compatibility string for i.MX6 Dual i.MX6 Dual boot was broken since r308533 because ofw_bus_node_is_compatible is more strict than fdt_is_compatible and does not accept partial matches 309998 by dteske: It's completely pointless to replace newlines with space (this is done automatically for you upon shell expansion) 309997 by dteske: The flags of a WLAN need to be quoted (they contain things like brackets) 309996 by dteske: Simplify single-line if statements 309995 by dteske: Simplify loop by moving predicate to clause 309994 by dteske: Wordsmithing 309993 by dteske: Why test $? when you can test the command 309992 by dteske: Restore previous comment 309991 by dteske: Both simplify bringup of interface after changes and catch errors in debug 309990 by dteske: Calculate proper size of menu list dialog 309989 by dteske: There's an API function for catching errors and displaying them or logging them to debug output 309988 by dteske: There's an API function for displaying pauses 309987 by dteske: There's an API function for displaying yes/no dialogs 309986 by dteske: There's an API function for displaying errors 309985 by dteske: Comment 309984 by dteske: Whitespace alignment 309983 by dteske: Relying on dialog auto-sizing (width/height/rows =3D 0) is a mistake Use the provided API for calculating the appropriate size of menus 309982 by dteske: Remove unnecessary quotes 309981 by dteske: Add missing quotes 309980 by dteske: In awk, if you're going to append a newline to your printf AND you're going to print only the argument, just use print 309979 by dteske: This statement has too many backslashes 309978 by dteske: Neither printf (and as is commonly known) nor print need parens in awk 309977 by dteske: Whitespace and alignment 309976 by dteske: You don't need parentheses for awk's printf 309975 by dteske: Continued resolution of conveluted statement We shouldn't be coding things like "x || (x && x) || x || x || x ..." 309974 by dteske: These two error messages have always been backwards since inception 309973 by dteske: Why use $? when you can use the command itself 309972 by dteske: If the first ping succeeded, why on Earth should we ping it again? 309971 by dteske: Start deconstructing a conveluted hunk of code 309970 by dteske: Remove completely unnecesary parentheses 309969 by dteske: Why repeat yourself when you can send stderr to the same place as stdout? 309968 by dteske: Properly quote variable 309967 by dteske: Use more generic f_yesno() from provided API 309966 by dteske: The output of dialog needs to be sanitized for portability/compatibility requirements 309965 by dteske: Whitespace alignment 309964 by dteske: Sort the domains 309963 by dteske: The --no-items and --stdout options are non-standard and should be avoided >From the dialog(1) manual: using [--stdout] in portable scripts is not recommended 309962 by dteske: More efficiently make use of the exit status 309961 by dteske: Stop repeating strings (centralize prompt string) NB: Changes to strings now only affect a single line 309960 by dteske: Add missing backslash (no real effect; it's pedantic and correct for the interpolation level) 309959 by dteske: Use the oft-neglected awk syntax "startcondition, stopcondition { ... }" to process the range of country labels which appear as columnar list from the "ifconfig DEV list countries" command. Not only improving maintainability, but also properly encapsulating arguments in single-quotes instead of trying to escape whitespace. It is also completely unnecessary to collapse newlines into whitespace (shell will do this for you automatically upon expansion of the contents where necessary). NB: This also changes the sorting algorithm to sort on the country code, not the country name. The type-ahead feature of dialog is destroyed if the tags are not sorted properly. 309958 by dteske: Quote WLAN_IFACE (pedantic) 309957 by jilles: Add tests for reaper receiving SIGCHLD (r309886). PR:=09=09213928 MFC after:=092 weeks 309952 by dteske: In awk, casting a variable as a boolean condition is the same as testing if the length of the variable contents is greater than zero This allows us to also move the secondary condition into the action clause 309951 by dteske: Remove an unnecessary call to f_dialog_title_restore() 309950 by dteske: Whitespace 309949 by dteske: Utilize provided i18n strings 309948 by dteske: Remove incomplete and unnecessary creation of fd3 The provided API already provides a passthru descriptor and even gives you a varaible for referring to it. 309947 by dteske: Remove unnecessary semi-colons 309946 by dteske: Use awk the following (more succinct) awk syntax: =09condition1 { action1 } =09condition2 { action2 } instead of the following syntax: =09{ =09=09if (condition1) { action1 } =09=09else if (condition2) { action2 } =09} 309945 by dteske: 1 is the default descriptor for redirects without an fd prefix 309944 by dteske: Fix invalid parameter expansion (change $@ to "$@") Without quotes, $@ loses its special meanining (see below) % sh -c 'echo $@' /bin/sh " 1 " " 2 " 1 2 % sh -c 'echo "$@"' /bin/sh " 1 " " 2 " 1 2 The quotes are required to get ARGV to be unperterped 309942 by dteske: Allow the script path to contain whitespace and special characters 309941 by dteske: Use provided API to centralize dialog title strings 309940 by dteske: Reorder dialog parameters based on commonality for readability 309939 by dteske: Fix incorrect use of provided API The result of which was incorrectly sized menu dialogs 309938 by dteske: Use provided API (change "dialog" to "$DIALOG") 309937 by dteske: Whitespace (dialog options separated to minimize diffs) 309936 by pfg: ed(1): Simplify some checks. The return type for both fread(3) and fwrite(3) cannot be negative, this renders some checks invalid and variable 'ct' unnecessary. Also bump 'len' to size_t to avoid signed/unsigned comparison warnings. 309935 by manu: Use the spibus accessor when applicable. MFC after:=093 days 309934 by dteske: Consolidate redirects into here documents, with proper code indentation 309933 by hrs: - Refactor listening socket list. All of the listening sockets are now maintained in a single linked-list in a transport-independent manner. - Use queue.h for linked-list structure. - Use linked-list for AllowedPeers. - Use getaddrinfo(8) even for Unix Domain sockets. - Use macros to type-casting from/to struct sockaddr{,_in,_in6}. - Define fu_* macro for union f_un to shorten the member names. - Remove an extra #include . - Add "static" to non-exported symbols. - !INET support is still incomplete but will be fixed later. There is no functional change except for some minor debug messages. 309932 by dteske: Remove an unnecessary "return $?" at end of function 309931 by hrs: Temporarily backout the previous commit because it was totally broken due t= o unresolved merge conflicts. Pointy hat to:=09hrs 309930 by dteske: Use ternary operator 309929 by mjg: vfs: use vrefact in getcwd and fchdir 309928 by dteske: If you're not going to make use of the products of a match() in awk (e.g., RSTART and RLENGTH variables) then use ~ instead of match() 309927 by trasz: Undo r309891. Konstantin is right in that this condition normally cannot happen - the um_dev field is assigned at mount and never written to afterwards. 309926 by dteske: Now that these variables do not contain the --default-item flag itself, change the name of the variable from $def_item_... to $default_... 309925 by hrs: - Refactor listening socket list. All of the listening sockets are now maintained in a single linked-list in a transport-independent manner. - Use queue.h for linked-list structure. - Use linked-list for AllowedPeers. - Use getaddrinfo(8) even for Unix Domain sockets. - Use macros to type-casting from/to struct sockaddr{,_in,_in6}. - Define fu_* macro for union f_un to shorten the member names. - Remove an extra #include . - Add "static" to non-exported symbols. - !INET support is still incomplete but will be fixed later. There is no functional change except for some minor debug messages. 309924 by dteske: Always pass --default-item parameter to dialog 309923 by dteske: There is zero harm in always passing --default-item to dialog 309922 by dteske: Centralize backtitle string 309921 by robak: Fix regression when stdin/out/err fds are are overridden by shell. Submitted by:=09Pawel Biernacki Reported by:=09ngie Approved by:=09ngie Sponsored by:=09Mysterious Code Ltd. Differential Revision:=09https://reviews.freebsd.org/D8543 309920 by dteske: Use provided API instead of hard-coded status integers 309919 by dteske: Whitespace 309918 by dteske: Remove unnecessary `-n' parameter to head/tail 309917 by dteske: awk(1) match() takes a regex, use /.../ to remind ourselves of this NB: The difference between "..." and /.../ for a regex in awk is that quoted strings go through escape expansion first (e.g., \\ becomes \) 309916 by dteske: Be internally consistent (": > ..." is used elsewhere in this file) 309915 by dteske: "echo | sed | sed | awk" is silly (changed to "echo | awk") 309914 by dteske: Add missing `-e' parameter to sed invocations 309913 by dteske: Allow $BSDINSTALL_TMPETC to contain whitespace or special chars 309912 by manu: CS ivar is uint32_t, not int. MFC after:=093 days 309911 by dteske: Group fallbacks together 309910 by dteske: Remove unnecessary quotes around number in test 309909 by dteske: Change "[ ! ... ] && ..." to "[ ... ] || ..." 309908 by dteske: Collapse tiny if statements 309907 by dteske: Replace funny block with something easy to digest 309906 by dteske: Consolidate locals 309905 by dteske: Remove unnecessary local initializers 309904 by dteske: Change "[ ! -z ... ]" =3D> "[ ... ]" and "[ -z ... ]" =3D> "[ ! ... ]" 309903 by andrew: Enable ACPI on arm64. It's not yet functional, but it will help keeping the code building until it is ready. Obtained from:=09ABT Systems Ltd Sponsored by:=09The FreeBSD Foundation 309902 by dteske: Use $( ... ) instead of `...` 309901 by dteske: Comments 309898 by alc: Eliminate every mention of PG_CACHED pages from the comments in the machine= - independent layer of the virtual memory system. Update some of the nearby comments to eliminate redundancy and improve clarity. In vm/vm_reserv.c, do not use hyphens after adverbs ending in -ly per The Chicago Manual of Style. Update the comment in vm/vm_page.h defining the four types of page queues t= o reflect the elimination of PG_CACHED pages and the introduction of the laundry queue. Reviewed by:=09kib, markj Sponsored by:=09Dell EMC Isilon Differential Revision:=09https://reviews.freebsd.org/D8752 309897 by cem: Add basic ATF tests for Capability mode .. lookups A follow-up to r309887. Several tests copied verbatim from https://github.com/emaste/snippets/blob/master/test_openat.c . Reviewed by:=09kib@, ngie@ (earlier version) X-MFC-With:=09r309887 Sponsored by:=09Dell EMC Isilon Differential Revision:=09https://reviews.freebsd.org/D8748 309896 by br: Apply clear_mask correctly. Reviewed by:=09jmcneill, kan Sponsored by:=09DARPA, AFRL 309895 by andrew: On non-Intel platforms don't ignore the PCI root bridge mapping in acpi_set_resource, the mappings are needed on arm64. Obtained from:=09ABT Systenms Ltd Sponsored by:=09The FreeBSD Foundation 309894 by manu: clk_div: Add a div lookup table Some clocks on SoC have a diff between the value written in the register and the real divider. Add a table that where we can lookup the real value of the divider. Reviewed by:=09mmel (earlier revision) Differential Revision:=09https://reviews.freebsd.org/D8728 309893 by mjg: vfs: add vrefact, to be used when the vnode has to be already active This allows blind increment of relevant counters which under contention is cheaper than inc-not-zero loops at least on amd64. Use it in some of the places which are guaranteed to see already active vnodes. Reviewed by:=09kib (previous version) 309892 by jchandra: Fix gic_cpu_mask() calculation in ARM GIC r309616 changed the definition of GICD_ITARGETSR(n) to take the irq id as argument, but the usage of the macro in gic_cpu_mask() was not updated to reflect this. This causes the cpu mask to be computed incorrectly. Update the GICD_ITARGETSR() call to fix this, this fixes a hang seen while booting freebsd on qemu-system-aarch64 with SMP enabled. 309891 by trasz: Avoid dereferencing NULL pointers in devtoname(). I've seen it panic, called from ufs_print() in DDB. MFC after:=091 month 309890 by jchandra: Increase interrupt cells in generic_pcie_fdt_route_interrupt ARM GIC specification in device trees use 3 cells, so the current limit of 2 causes the last cell to be dropped. This in turn can cause the interrupt polarity and trigger settings to be incorrect. Increase the limit to 4 which should handle all reasonable cases. This fixes issues seen in QEMU when registering PCI interrupts. 309888 by ae: Modify IPv6 statistic accounting in ip6_input(). Add rcvif local variable to keep inbound interface pointer. Count ifs6_in_discard errors in all "goto bad" cases. Now it will count errors even if mbuf was freed. Modify all places where m->m_pkthdr.rcvif is used to use local rcvif variable. Obtained from:=09Yandex LLC MFC after:=091 month 309887 by kib: Enable lookup_cap_dotdot and lookup_cap_dotdot_nonlocal. Requested and reviewed by:=09cem Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks Differential revision:=09https://reviews.freebsd.org/D8746 309886 by kib: When a zombie gets reparented due to the parent exit, send SIGCHLD to the reaper. The traditional reaper init(8) is aware of zombies silently reparented to it after the parents exit, it loops around waitpid(2) to collect them. For other reapers, the silent reparenting is surprising and collecting zombies requires a thread blocking in waitpid(2) just for that purpose. It seems that sending second SIGCHLD is a better workaround than forcing all reapers to obey the setup. Reported by:=09 Michael Zuo , jilles PR:=09213928 Reviewed by:=09jilles (previous version) Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks 309883 by ae: Add ip6_tryforward() - a run to completion forwarding implementation for IPv6. It gets performance benefits from reduced number of checks. It doesn't copy mbuf to be able send ICMPv6 error message, because it keeps mbuf unchanged until the moment, when the route decision has been made. It doesn't do IPsec checks, and when some IPsec security policies present, ip6_input() uses normal slow path. Reviewed by:=09bz, gnn Obtained from:=09Yandex LLC MFC after:=091 month Sponsored by:=09Yandex LLC Differential Revision:=09https://reviews.freebsd.org/D8527 The end of the build log: [...truncated 93526 lines...] --- dialogrc.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/libdpv -MD -MF.depend.dialogrc.o -MTdialogrc.o -std=3Dgnu99 -fstac= k-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-pa= rameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-t= ype -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast= -align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-= style-definition -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-= bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-= align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -= Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict= -aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -= Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-o= verflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/dialogrc.c -o dial= ogrc.o --- dprompt.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/libdpv -MD -MF.depend.dprompt.o -MTdprompt.o -std=3Dgnu99 -fstack-= protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-a= lign -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-st= yle-definition -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bo= unds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-al= ign -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wn= o-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-a= liasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wn= o-error=3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-ove= rflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/dprompt.c -o dprompt= .o --- all_subdir_lib/libdevdctl --- --- exception.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeB= SD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/buil= ds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/= builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_= amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd= /bin/ -fpic -DPIC -g -O2 -pipe -MD -MF.depend.exception.pico -MTexception.p= ico -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno= -unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-error=3Daddress -= Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare = -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -W= no-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -= Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-= but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wn= o-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdc= tl/exception.cc -o exception.pico In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/memory:601:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/algorithm:634, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/string:442, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:15, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo: In member function 'size_t std::type_info::hash_code= () const': /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo:116:62: warning: dereferencing type-punned pointer wi= ll break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast(&__type_name);} ^ --- all_subdir_lib/libdpv --- --- dpv.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/libdpv -MD -MF.depend.dpv.o -MTdpv.o -std=3Dgnu99 -fstack-protecto= r-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast= -qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wc= har-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-defi= nition -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wn= o-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno= -error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error= =3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing= -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-error= =3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow = -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/dpv.c -o dpv.o --- status.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/libdpv -MD -MF.depend.status.o -MTstatus.o -std=3Dgnu99 -fstack-pr= otector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parame= ter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-ali= gn -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-styl= e-definition -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-boun= ds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-alig= n -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-= error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-ali= asing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-= error=3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overf= low -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/status.c -o status.o --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__mutex_base:16:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error: At global scope: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error:345:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/__mutex_base:289:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ --- all_subdir_lib/clang --- --- AArch64GenSubtargetInfo.inc --- llvm-tblgen -gen-subtarget -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/= include -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64 = -d AArch64GenSubtargetInfo.inc.d -o AArch64GenSubtargetInfo.inc /builds/Fr= eeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64/AArch64.td --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/ios:392:1: warning: type attributes ignored after type is alre= ady defined [-Wattributes] }; ^ --- all_subdir_lib/libdpv --- --- util.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/libdpv -MD -MF.depend.util.o -MTutil.o -std=3Dgnu99 -fstack-protec= tor-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wca= st-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -= Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-de= finition -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -= Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -W= no-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-erro= r=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasin= g -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-erro= r=3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow = -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/util.c -o util.o --- dialog_util.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.dialog_util.pico -MTdialog_uti= l.pico -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow= -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-extern= s -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Da= ddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-= compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-co= mpare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-paren= theses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error= =3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused= -value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/l= ib/libdpv/dialog_util.c -o dialog_util.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/cstdio:99:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:40: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2635:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2636:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2637:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2638:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ --- all_subdir_lib/libmagic --- =3D=3D=3D> lib/libmagic (all) --- .depend --- echo libmagic.so.4.full: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_= HEAD_amd64_gcc/tmp/usr/lib/libz.a >> .depend --- apprentice.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.apprentice.o -MTapprentice.o -std=3Dgnu99 -fstack-protector-strong= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-poin= ter-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattrib= utes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobber= ed -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-er= ror=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duni= nitialized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-functio= n -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/Fre= eBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/apprentice.c -o app= rentice.o --- all_subdir_lib/libdpv --- --- dialogrc.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.dialogrc.pico -MTdialogrc.pico= -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y= 2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoin= ter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunu= sed-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wre= dundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress= -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compar= e -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare = -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses= -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunuse= d-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -= Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdp= v/dialogrc.c -o dialogrc.pico --- dprompt.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.dprompt.pico -MTdprompt.pico -= std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k= -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunuse= d-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredu= ndant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress -= Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare = -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -W= no-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -= Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-= but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wn= o-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/= dprompt.c -o dprompt.pico --- all_subdir_lib/libdevdctl --- --- guid.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeB= SD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/buil= ds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/= builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_= amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd= /bin/ -fpic -DPIC -g -O2 -pipe -MD -MF.depend.guid.pico -MTguid.pico -fstac= k-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-pa= rameter -Wpointer-arith -Wno-uninitialized -Wno-error=3Daddress -Wno-error= =3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-erro= r=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error= =3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-= variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-error= =3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid= .cc -o guid.pico In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/memory:601:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/algorithm:634, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/string:442, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:15, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo: In member function 'size_t std::type_info::hash_code= () const': /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo:116:62: warning: dereferencing type-punned pointer wi= ll break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast(&__type_name);} ^ --- all_subdir_lib/libdpv --- --- dpv.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.dpv.pico -MTdpv.pico -std=3Dgn= u99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno= -unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parame= ter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-de= cls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress -Wno-erro= r=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-err= or=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error= =3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-= variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-error= =3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/dpv.c -= o dpv.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__mutex_base:16:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error: At global scope: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error:345:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/__mutex_base:289:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ --- all_subdir_lib/libdpv --- --- status.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.status.pico -MTstatus.pico -st= d=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -= W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-= arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-= parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredund= ant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress -Wn= o-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -W= no-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno= -error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wn= o-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-bu= t-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-= error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/st= atus.c -o status.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/ios:392:1: warning: type attributes ignored after type is alre= ady defined [-Wattributes] }; ^ --- all_subdir_lib/libdpv --- --- util.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -I/builds/FreeBSD= _HEAD_amd64_gcc/lib/libdpv -MD -MF.depend.util.pico -MTutil.pico -std=3D= gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress -Wno-er= ror=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-e= rror=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-err= or=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-se= t-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdpv/util.c= -o util.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/stdlib.h:88:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2635:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2636:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2637:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2638:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ --- all_subdir_lib/libdpv --- --- libdpv.a --- building static dpv library /usr/local/x86_64-freebsd/bin/ar -crD libdpv.a `NM=3D'/usr/local/x86_64-fre= ebsd/bin/nm' NMFLAGS=3D'' lorder dialog_util.o dialogrc.o dprompt.o dpv.o = status.o util.o | tsort -q`=20 /usr/local/x86_64-freebsd/bin/ranlib -D libdpv.a --- libdpv.so.1.full --- building shared library libdpv.so.1 /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fstack-protector-strong -shared -Wl,-x -= Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libdpv.so.1.full -Wl,-son= ame,libdpv.so.1 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lord= er dialog_util.pico dialogrc.pico dprompt.pico dpv.pico status.pico util.pi= co | tsort -q` -ldialog -lfigpar -lutil -lncursesw --- all_subdir_lib/libmagic --- --- apptype.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.apptype.o -MTapptype.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -= Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wn= o-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3D= logical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitial= ized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno= -error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_H= EAD_amd64_gcc/lib/libmagic/../../contrib/file/src/apptype.c -o apptype.o --- all_subdir_lib/libdpv --- --- libdpv.so.1.debug --- /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug libdpv.so.1.full li= bdpv.so.1.debug --- all_subdir_lib/libmagic --- --- ascmagic.o --- --- all_subdir_lib/libdpv --- --- libdpv.so.1 --- --- all_subdir_lib/libmagic --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.ascmagic.o -MTascmagic.o -std=3Dgnu99 -fstack-protector-strong -Ws= ystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-proto= types -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-= sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes= -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -= Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error= =3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninit= ialized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -= Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBS= D_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/ascmagic.c -o ascmagic= .o --- all_subdir_lib/libdpv --- /usr/local/x86_64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3Dl= ibdpv.so.1.debug libdpv.so.1.full libdpv.so.1 --- all_subdir_lib/libmagic --- --- cdf.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.cdf.o -MTcdf.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmi= ssing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-= error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-erro= r=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error= =3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical= -not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -W= no-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-error= =3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_am= d64_gcc/lib/libmagic/../../contrib/file/src/cdf.c -o cdf.o --- all_subdir_lib/libdevdctl --- --- libprivatedevdctl.a --- building static devdctl library /usr/local/x86_64-freebsd/bin/ar -crD libprivatedevdctl.a `NM=3D'/usr/local= /x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder consumer.o event.o event_facto= ry.o exception.o guid.o | tsort -q`=20 /usr/local/x86_64-freebsd/bin/ranlib -D libprivatedevdctl.a --- libprivatedevdctl.so.0.full --- building shared library libprivatedevdctl.so.0 /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBS= D_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/build= s/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/b= uilds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_a= md64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd/= bin/ -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--wa= rn-shared-textrel -o libprivatedevdctl.so.0.full -Wl,-soname,libprivatedev= dctl.so.0 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder con= sumer.pico event.pico event_factory.pico exception.pico guid.pico | tsort = -q`=20 --- all_subdir_lib/clang --- --- AArch64GenSystemOperands.inc --- llvm-tblgen -gen-searchable-tables -I /builds/FreeBSD_HEAD_amd64_gcc/contr= ib/llvm/include -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/A= Arch64 -d AArch64GenSystemOperands.inc.d -o AArch64GenSystemOperands.inc = /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64/AArch64.td --- all_subdir_lib/libdevdctl --- /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status *** [libprivatedevdctl.so.0.full] Error code 1 bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl 1 error bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl *** [all_subdir_lib/libdevdctl] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib --- all_subdir_lib/libmagic --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic *** [all_subdir_lib/libmagic] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib --- all_subdir_lib/clang --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang/libllvm *** [all_subdir_lib/clang/libllvm] Error code 2 bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang 1 error bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang *** [all_subdir_lib/clang] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib 3 errors bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib *** [lib__L] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [libraries] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [_libraries] Error code 2 bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [buildworld] Error code 2 make: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error make: stopped in /builds/FreeBSD_HEAD_amd64_gcc Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Dec 13 12:49:37 2016 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 0B576C746DB for ; Tue, 13 Dec 2016 12:49:37 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 C115B314 for ; Tue, 13 Dec 2016 12:49:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGmWS-000L9L-1Z; Tue, 13 Dec 2016 15:49:32 +0300 Date: Tue, 13 Dec 2016 15:49:32 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213124931.GI90287@zxy.spb.ru> References: <20161212171634.GD90287@zxy.spb.ru> <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213112340.GT54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 12:49:37 -0000 On Tue, Dec 13, 2016 at 01:23:40PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > > > > > >>>> Try the debugging patch below, which unconditionally disables import of > > > > > >>>> previous buffer. To test, you would need to boot, then frob options in > > > > > >>>> BIOS, reboot, again frob etc. > > > > > >>> > > > > > >>> still need test patch? if yes, with BIOS options? > > > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > > > > > sorry, i don't know 'frob'. > > > > > > what exactly options combination I need test and what about memory test? > > > > > > > > > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > > > corrupted due to interleave. > > > > > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > > > interleave=on, etc etc. > > > > > > > > NUMA=on interleave=off booted > > > > NUMA=on interleave=on hang > > > > > > > > I think different combination whatever? > > > > > > Do you mean, that both patched kernel, and unpatched kernel with the > > > memory test enabled, hang when NUMA and interleave options enabled ? > > > > Unpatched kernel boot with the memory test enabled when NUMA and > > interleave options enabled -- I am already reported this. > > > > patched kernel with the memory test enabled boot too. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > i.e. memory test enabled allow boot in any situation. > Then what about was the statement above ? About unpatched kernel https://lists.freebsd.org/pipermail/freebsd-current/2016-December/064069.html patched and test I am test now, and wrote in previos mail ^^^ > You said that NUMA and interleave > on caused hang. Was that on the patched kernel ? patched w/o memory test > > > > > Could you enable the options, power down the machine for 10-20 minutes, > > > and try to boot ? > > > > For with kernel and bios options and boot options? > > I am have two day befor server put in production for any expirements, > > but please, be more clear in what combination need to test. > > Boot with NUMA enabled and interleave off. Already with patched kernel > Patch kernel with the 'if (1 || ...)' patch. > Reboot, enter BIOS setup and enable interleave there. > Try to boot - does it boot ? No. > If it did not booted, power machine off for 10 minutes. OK > Power it on, try to boot (with the same patched kernel). > Does the machine boot now ? Don't boot. From owner-freebsd-current@freebsd.org Tue Dec 13 13:45:51 2016 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 77F45C742B2; Tue, 13 Dec 2016 13:45:51 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 207E48E3; Tue, 13 Dec 2016 13:45:51 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id g23so110512796wme.1; Tue, 13 Dec 2016 05:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eUCrU9y5ivlLpQNNxzv2J1kaNYPooHkG+3QgjP5xIL8=; b=s5zyGPI0sMuUKFdtSEoX8Htt2On3084p2QrCyFxUjoUo8JfjbmrbHdo/Xj8V7jhQPJ d8oQCDXdyj+asO8tWORRU9VIRNFrykhED15F3B0mB651z4NV5sX1RW3zEb01PFucuXhE pKFuNTNzkyyBieOA1YU5YAPH1csQnVaicZ2FfPM1Ca8ZxOPezjCl1/TLWfaU6mGRWoAm 5eSqCAmR/pUQYec9wDo7OeSo6C2yni/r95QSlDCluCCkJ59JuGXPeLjDCvmo5eYQyGqw b2kpGWVRfLTFcsijpQNWT6Rv0FLcm2QsG9P7z4x2UqCbtl+UjndV4FmsPgqG88YZzmqa WTtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eUCrU9y5ivlLpQNNxzv2J1kaNYPooHkG+3QgjP5xIL8=; b=ZhhMxsRqGDfKfsTKCarGDQD7tucIjU9qC12F7vkgp4omaX0Go1piHaEVgTubjoxd8S HQouRrctALV7lDdRYpFYjioFMZtnpDgiwcEarvdrbaY7hRwgD9zf/f1LrWP/XozCr6eU fJBDt6Iln+XkdblnE6sg2yYn898wJ36dkQaNfTXOYyTlTFZSVReimmLDcU78PC5DWHlH FnUSrlXKQ38MOnz7zcb1CN9npXZeQvLXDoj0X+AYtyQL/Y8qh7r83ClqGZYL/tQzgoAF f4Kdk+pJVxSoZGtaEcBv/9jqpwPt+TNIEM2HPzEB8MdYKcMtMJZhI0Y31wroIC4z3wes XKyw== X-Gm-Message-State: AKaTC023wrjX3UG88mMqCc9xODMe2pYgLKdPzvyTYAAXmPlR+aLHpvJzPu95G/lYUswRCUED/Gkyz3AAjQwwvQ== X-Received: by 10.28.230.197 with SMTP id e66mr2888318wmi.12.1481636749447; Tue, 13 Dec 2016 05:45:49 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.14.197 with HTTP; Tue, 13 Dec 2016 05:45:28 -0800 (PST) In-Reply-To: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 13 Dec 2016 14:45:28 +0100 X-Google-Sender-Auth: 2i472WSMo25LPwPk4IWHNWCw86M Message-ID: Subject: Re: [RFC/RFT] projects/ipsec To: "Andrey V. Elsukov" Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" 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: Tue, 13 Dec 2016 13:45:51 -0000 On Sun, Dec 11, 2016 at 12:07 AM, Andrey V. Elsukov wrote: > Hi All, > > I am pleased to announce that projects/ipsec, that I started several > months ago is ready for testing and review. > The main goals were: > * rework locking to make IPsec code more friendly for concurrent > processing; > * make lookup in SADB/SPDB faster; > * revise PFKEY implementation, remove stale code, make it closer > to RFC; > * implement IPsec VTI (virtual tunneling interface); > * make IPsec code loadable as kernel module. > > =E2=80=8BI've got a very simple configuration (static key),but I like the performance improvement brings by projects/ipsec :-) A simple packet-per-second using null encryption should be enough for benching the improvement, but my IPSec lab (using Equilibrium methodology) did a little more. https://github.com/ocochard/netbenches/blob/master/AMD_GX- 412TC_4Cores_Intel_i210AT/ipsec/results/fbsd12.projects- ipsec.equilibrium/graph.png Thanks for your work! Olivier From owner-freebsd-current@freebsd.org Tue Dec 13 13:58:05 2016 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 18B24C74878 for ; Tue, 13 Dec 2016 13:58:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4BD010C3 for ; Tue, 13 Dec 2016 13:58: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 uBDDw0Bi070233 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 15:58:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDDw0Bi070233 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDDvxoh070232; Tue, 13 Dec 2016 15:57:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 15:57:59 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213135759.GY54029@kib.kiev.ua> References: <20161212172418.GK54029@kib.kiev.ua> <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213124931.GI90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 13:58:05 -0000 On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > Boot with NUMA enabled and interleave off. > > Already with patched kernel > > > Patch kernel with the 'if (1 || ...)' patch. > > Reboot, enter BIOS setup and enable interleave there. > > Try to boot - does it boot ? > > No. > > > If it did not booted, power machine off for 10 minutes. > > OK > > > Power it on, try to boot (with the same patched kernel). > > Does the machine boot now ? > > Don't boot. I am really puzzled. In other words, touching all memory causes the msgbuf to not hang. Can you try one more experiment ? Take the patch below, apply it. >From the config where interleave is disabled, install new kernel. Reboot, enter BIOS setup and enable interleave. Set late_console to zero in loader. Do not enable memory test. Boot the patched kernel. Kernel must hang, according to your previous reports. I want to see the console log. diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..1be7a629f65 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) mbp->msg_ptr = ptr; mbp->msg_size = size; mbp->msg_seqmod = SEQMOD(size); +printf("YYY1\n"); msgbuf_clear(mbp); +printf("YYY2\n"); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_flags = 0; +printf("YYY3\n"); bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); +printf("YYY4\n"); } + /* * Reinitialize a message buffer, retaining its previous contents if * the size and checksum are correct. If the old contents cannot be @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { +printf("XXX1\n"); msgbuf_init(mbp, ptr, size); +printf("XXX2\n"); return; } mbp->msg_seqmod = SEQMOD(size); @@ -117,10 +124,12 @@ void msgbuf_clear(struct msgbuf *mbp) { +printf("ZZZ1\n"); bzero(mbp->msg_ptr, mbp->msg_size); mbp->msg_wseq = 0; mbp->msg_rseq = 0; mbp->msg_cksum = 0; +printf("ZZZ2\n"); } /* From owner-freebsd-current@freebsd.org Tue Dec 13 14:11:18 2016 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 768EFC74F72 for ; Tue, 13 Dec 2016 14:11:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 3800119F6 for ; Tue, 13 Dec 2016 14:11:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGnnW-000NPP-Gs; Tue, 13 Dec 2016 17:11:14 +0300 Date: Tue, 13 Dec 2016 17:11:14 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213141114.GJ90287@zxy.spb.ru> References: <20161212174311.GE90287@zxy.spb.ru> <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213135759.GY54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 14:11:18 -0000 On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > > Boot with NUMA enabled and interleave off. > > > > Already with patched kernel > > > > > Patch kernel with the 'if (1 || ...)' patch. > > > Reboot, enter BIOS setup and enable interleave there. > > > Try to boot - does it boot ? > > > > No. > > > > > If it did not booted, power machine off for 10 minutes. > > > > OK > > > > > Power it on, try to boot (with the same patched kernel). > > > Does the machine boot now ? > > > > Don't boot. > > I am really puzzled. In other words, touching all memory causes the > msgbuf to not hang. yes > Can you try one more experiment ? > Take the patch below, apply it. > >From the config where interleave is disabled, install new kernel. > Reboot, enter BIOS setup and enable interleave. > Set late_console to zero in loader. > Do not enable memory test. > Boot the patched kernel. > Kernel must hang, according to your previous reports. > I want to see the console log. Hmm. I am [already] show output from ddb, and guess kernel will be hang at first wirte to *mbp, i.e. you don't see any in console log. OK, anyway I am try this pacth. > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c > index f275aef3b4f..1be7a629f65 100644 > --- a/sys/kern/subr_msgbuf.c > +++ b/sys/kern/subr_msgbuf.c > @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) > mbp->msg_ptr = ptr; > mbp->msg_size = size; > mbp->msg_seqmod = SEQMOD(size); > +printf("YYY1\n"); > msgbuf_clear(mbp); > +printf("YYY2\n"); > mbp->msg_magic = MSG_MAGIC; > mbp->msg_lastpri = -1; > mbp->msg_flags = 0; > +printf("YYY3\n"); > bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); > mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); > +printf("YYY4\n"); > } > > + > /* > * Reinitialize a message buffer, retaining its previous contents if > * the size and checksum are correct. If the old contents cannot be > @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) > { > u_int cksum; > > - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { > +printf("XXX1\n"); > msgbuf_init(mbp, ptr, size); > +printf("XXX2\n"); > return; > } > mbp->msg_seqmod = SEQMOD(size); > @@ -117,10 +124,12 @@ void > msgbuf_clear(struct msgbuf *mbp) > { > > +printf("ZZZ1\n"); > bzero(mbp->msg_ptr, mbp->msg_size); > mbp->msg_wseq = 0; > mbp->msg_rseq = 0; > mbp->msg_cksum = 0; > +printf("ZZZ2\n"); > } > > /* From owner-freebsd-current@freebsd.org Tue Dec 13 14:34:04 2016 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 9A9DBC75A6E for ; Tue, 13 Dec 2016 14:34:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 5C6B8B5F for ; Tue, 13 Dec 2016 14:34:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGo9Z-000O4T-VI; Tue, 13 Dec 2016 17:34:01 +0300 Date: Tue, 13 Dec 2016 17:34:01 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: "A. Wilcox" , freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213143401.GK90287@zxy.spb.ru> References: <20161212183647.GL54029@kib.kiev.ua> <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213141114.GJ90287@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 14:34:04 -0000 On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > > > Boot with NUMA enabled and interleave off. > > > > > > Already with patched kernel > > > > > > > Patch kernel with the 'if (1 || ...)' patch. > > > > Reboot, enter BIOS setup and enable interleave there. > > > > Try to boot - does it boot ? > > > > > > No. > > > > > > > If it did not booted, power machine off for 10 minutes. > > > > > > OK > > > > > > > Power it on, try to boot (with the same patched kernel). > > > > Does the machine boot now ? > > > > > > Don't boot. > > > > I am really puzzled. In other words, touching all memory causes the > > msgbuf to not hang. > > yes > > > Can you try one more experiment ? > > Take the patch below, apply it. > > >From the config where interleave is disabled, install new kernel. > > Reboot, enter BIOS setup and enable interleave. > > Set late_console to zero in loader. > > Do not enable memory test. > > Boot the patched kernel. > > Kernel must hang, according to your previous reports. > > I want to see the console log. > > Hmm. I am [already] show output from ddb, and guess kernel will be > hang at first wirte to *mbp, i.e. you don't see any in console log. > > OK, anyway I am try this pacth. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000099c00 SMAP type=02 base=0000000000099c00 len=0000000000006400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007906b000 SMAP type=02 base=000000007916b000 len=0000000000936000 SMAP type=04 base=0000000079aa1000 len=0000000000509000 SMAP type=02 base=0000000079faa000 len=0000000002056000 SMAP type=01 base=0000000100000000 len=0000001f80000000 SMAP type=02 base=000000007c000000 len=0000000014000000 SMAP type=02 base=00000000fed1c000 len=0000000000029000 SMAP type=02 base=00000000ff000000 len=0000000001000000 XXX1 YYY1 ZZZ1 From owner-freebsd-current@freebsd.org Tue Dec 13 15:01:49 2016 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 C470DC754DA for ; Tue, 13 Dec 2016 15:01:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 504FF1D7F for ; Tue, 13 Dec 2016 15:01:49 +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 uBDF1dHJ085915 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 17:01:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDF1dHJ085915 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDF1dr6085914; Tue, 13 Dec 2016 17:01:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 17:01:39 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213150139.GZ54029@kib.kiev.ua> References: <20161212192619.GF90287@zxy.spb.ru> <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213143401.GK90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 15:01:49 -0000 On Tue, Dec 13, 2016 at 05:34:01PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote: > > > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > > > > Boot with NUMA enabled and interleave off. > > > > > > > > Already with patched kernel > > > > > > > > > Patch kernel with the 'if (1 || ...)' patch. > > > > > Reboot, enter BIOS setup and enable interleave there. > > > > > Try to boot - does it boot ? > > > > > > > > No. > > > > > > > > > If it did not booted, power machine off for 10 minutes. > > > > > > > > OK > > > > > > > > > Power it on, try to boot (with the same patched kernel). > > > > > Does the machine boot now ? > > > > > > > > Don't boot. > > > > > > I am really puzzled. In other words, touching all memory causes the > > > msgbuf to not hang. > > > > yes > > > > > Can you try one more experiment ? > > > Take the patch below, apply it. > > > >From the config where interleave is disabled, install new kernel. > > > Reboot, enter BIOS setup and enable interleave. > > > Set late_console to zero in loader. > > > Do not enable memory test. > > > Boot the patched kernel. > > > Kernel must hang, according to your previous reports. > > > I want to see the console log. > > > > Hmm. I am [already] show output from ddb, and guess kernel will be > > hang at first wirte to *mbp, i.e. you don't see any in console log. > > > > OK, anyway I am try this pacth. > > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=0000000000099c00 > SMAP type=02 base=0000000000099c00 len=0000000000006400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000007906b000 > SMAP type=02 base=000000007916b000 len=0000000000936000 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > SMAP type=02 base=0000000079faa000 len=0000000002056000 > SMAP type=01 base=0000000100000000 len=0000001f80000000 > SMAP type=02 base=000000007c000000 len=0000000014000000 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > SMAP type=02 base=00000000ff000000 len=0000000001000000 > XXX1 > YYY1 > ZZZ1 Ok, please do exactly the same testing with the following patch. If the patched kernel boots succesfully, or if the patched kernel boots further, I will provide one more, last patch, to test. diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..1be7a629f65 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) mbp->msg_ptr = ptr; mbp->msg_size = size; mbp->msg_seqmod = SEQMOD(size); +printf("YYY1\n"); msgbuf_clear(mbp); +printf("YYY2\n"); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_flags = 0; +printf("YYY3\n"); bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); +printf("YYY4\n"); } + /* * Reinitialize a message buffer, retaining its previous contents if * the size and checksum are correct. If the old contents cannot be @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { +printf("XXX1\n"); msgbuf_init(mbp, ptr, size); +printf("XXX2\n"); return; } mbp->msg_seqmod = SEQMOD(size); @@ -117,10 +124,12 @@ void msgbuf_clear(struct msgbuf *mbp) { +printf("ZZZ1\n"); bzero(mbp->msg_ptr, mbp->msg_size); mbp->msg_wseq = 0; mbp->msg_rseq = 0; mbp->msg_cksum = 0; +printf("ZZZ2\n"); } /* diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c index e78863830c7..435412d55ea 100644 --- a/sys/kern/subr_prf.c +++ b/sys/kern/subr_prf.c @@ -998,6 +998,8 @@ msgbufinit(void *ptr, int size) char *cp; static struct msgbuf *oldp = NULL; +printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size); +bzero(ptr, size); size -= sizeof(*msgbufp); cp = (char *)ptr; msgbufp = (struct msgbuf *)(cp + size); From owner-freebsd-current@freebsd.org Tue Dec 13 15:24:18 2016 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 54EF0C7502C for ; Tue, 13 Dec 2016 15:24:18 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2487F1234 for ; Tue, 13 Dec 2016 15:24:18 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1481642653; bh=LZ+HNbuNC UvoIlWutWO/5NAxrdsW0r4GwYOIbVJhmrM=; b=RDziOxCPGKCR89VOi2o6kVQDS iQAdFyLUcyVtCNKIXJHDSi/J++oszmbtOzDPwCK9vxnIBLeKwiqnlk95O6hOlWbm 4rtXcHN33jMdj2zQ6p86hA27uzxtLIYcF8+QotTAyVHphCXUCE55J1ET21ddTQKT zbl6vsDOI6/ukdXqVw= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 072E51B997 for ; Tue, 13 Dec 2016 10:24:13 -0500 (EST) To: FreeBSD Current From: Michael Butler Subject: Log spam: Limiting * response from 1 to 200 packets/sec Message-ID: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> Date: Tue, 13 Dec 2016 10:24:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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, 13 Dec 2016 15:24:18 -0000 Any hints as to why all of my -current equipment is complaining like below. Is there a sysctl to moderate/turn this off? Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:00:21 archive last message repeated 13 times Dec 13 10:02:21 archive last message repeated 18 times Dec 13 10:06:21 archive last message repeated 36 times Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:08:21 archive last message repeated 17 times Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 packets/sec Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:10:21 archive last message repeated 17 times Dec 13 10:12:21 archive last message repeated 18 times Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:14:21 archive last message repeated 17 times Dec 13 10:16:21 archive last message repeated 18 times Michael From owner-freebsd-current@freebsd.org Tue Dec 13 15:28:41 2016 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 56D57C752E0 for ; Tue, 13 Dec 2016 15:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 1A07C1683 for ; Tue, 13 Dec 2016 15:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGp0Q-000PXK-7b; Tue, 13 Dec 2016 18:28:38 +0300 Date: Tue, 13 Dec 2016 18:28:38 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213152838.GL90287@zxy.spb.ru> References: <584F22B1.9000903@Wilcox-Tech.com> <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213150139.GZ54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 15:28:41 -0000 On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote: > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > XXX1 > > YYY1 > > ZZZ1 > > Ok, please do exactly the same testing with the following patch. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000099c00 SMAP type=02 base=0000000000099c00 len=0000000000006400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007906b000 SMAP type=02 base=000000007916b000 len=0000000000936000 SMAP type=04 base=0000000079aa1000 len=0000000000509000 SMAP type=02 base=0000000079faa000 len=0000000002056000 SMAP type=01 base=0000000100000000 len=0000001f80000000 SMAP type=02 base=000000007c000000 len=0000000014000000 SMAP type=02 base=00000000fed1c000 len=0000000000029000 SMAP type=02 base=00000000ff000000 len=0000000001000000 TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 > If the patched kernel boots succesfully, or if the patched kernel > boots further, I will provide one more, last patch, to test. please, next time point what verion of source need to patch: vanila or already patched. From owner-freebsd-current@freebsd.org Tue Dec 13 15:30:10 2016 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 68E40C75454 for ; Tue, 13 Dec 2016 15:30:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (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 2F8CA192A for ; Tue, 13 Dec 2016 15:30:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0C43112B1D; Tue, 13 Dec 2016 16:30:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E224AE77-2ABC-47E2-B1AC-99EF64BEBC1D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec From: Dimitry Andric In-Reply-To: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> Date: Tue, 13 Dec 2016 16:29:55 +0100 Cc: FreeBSD Current Message-Id: <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> To: Michael Butler 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, 13 Dec 2016 15:30:10 -0000 --Apple-Mail=_E224AE77-2ABC-47E2-B1AC-99EF64BEBC1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Dec 2016, at 16:24, Michael Butler = wrote: >=20 > Any hints as to why all of my -current equipment is complaining like = below. Somebody is most likely port scanning your machines. I see this all the time on boxes connected to the internet. > Is there a sysctl to moderate/turn this off? >=20 > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 = to 200 packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to = 200 packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 = to 200 packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from = 4 to 200 packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 = to 200 packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to = 200 packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 = to 200 packets/sec > Dec 13 10:14:21 archive last message repeated 17 times > Dec 13 10:16:21 archive last message repeated 18 times sysctl net.inet.icmp.icmplim_output=3D0, or increase the ICMP limit, if you want to help the port scanners. :-) -Dimitry --Apple-Mail=_E224AE77-2ABC-47E2-B1AC-99EF64BEBC1D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhQE/wACgkQsF6jCi4glqOllACgjjwjCexO6fRJHIB+/gpDmp1s jhwAnjGdOYULj4H2ulYB0rTf+CoOyTjh =Ik20 -----END PGP SIGNATURE----- --Apple-Mail=_E224AE77-2ABC-47E2-B1AC-99EF64BEBC1D-- From owner-freebsd-current@freebsd.org Tue Dec 13 15:43:31 2016 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 64D69C75A66 for ; Tue, 13 Dec 2016 15:43:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34939308; Tue, 13 Dec 2016 15:43:30 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s=201508; t= 1481643808; bh=U0gs6DdCLubhZdk8dbHSc5zBILPud7rnh6unoK1cR8U=; b=G tFJ+1uHpZNHn1/v0cPPOiQ+OwAGz2mkfY5KoJ1cAUJFY2gmXodEpMWROCU7BzTGu 7zS4iJ/U+4nwEnEMKd4yYaWXwvWm3Rcbfxxi+NL9/xBxdFonqjNwA86ci8GdSj/G 22ycdGlOBcATWT0kJ1iu5Z7I6uByVYE5KQD1rkL9j8= Received: from toshi.auburn.protected-networks.net (unknown [IPv6:2001:470:1f07:4e1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 576A51BECA; Tue, 13 Dec 2016 10:43:28 -0500 (EST) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: Dimitry Andric References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> Cc: FreeBSD Current From: Michael Butler Message-ID: <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> Date: Tue, 13 Dec 2016 10:43:27 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2016 15:43:31 -0000 On 12/13/16 10:29, Dimitry Andric wrote: > Somebody is most likely port scanning your machines. I see this all the > time on boxes connected to the internet. As are mine. I wouldn't mind so much if the message contained sufficient useful information that could be acted on, e.g. originating IP address and, when appropriate, destination port. > sysctl net.inet.icmp.icmplim_output=0, or increase the ICMP limit, if > you want to help the port scanners. :-) I've added the sysctl to mute the warnings - thanks :-) Michael From owner-freebsd-current@freebsd.org Tue Dec 13 15:49:10 2016 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 668C6C75DA9 for ; Tue, 13 Dec 2016 15:49:10 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5155ACA5; Tue, 13 Dec 2016 15:49:09 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id AE7595648E; Tue, 13 Dec 2016 09:49:02 -0600 (CST) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: Michael Butler , FreeBSD Current , glebius@FreeBSD.org, rrs@FreeBSD.org, jtl@FreeBSD.org References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> From: Eric van Gyzen Message-ID: <689f6fbe-c59f-2e3a-44d6-bc9d19d31bf9@FreeBSD.org> Date: Tue, 13 Dec 2016 09:48:59 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> Content-Type: text/plain; charset=windows-1252 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, 13 Dec 2016 15:49:10 -0000 On 12/13/2016 09:24, Michael Butler wrote: > Any hints as to why all of my -current equipment is complaining like below. Is > there a sysctl to moderate/turn this off? > > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 > packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec What Subversion revision are you running? Did this start happening after a recent update? I ask because r309745 was committed a few days ago and might have changed the behavior. Eric From owner-freebsd-current@freebsd.org Tue Dec 13 15:53:04 2016 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 3B330C750DA for ; Tue, 13 Dec 2016 15:53:04 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFE0110D2 for ; Tue, 13 Dec 2016 15:53:03 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from host-4-75.office.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id E2DA17662 for ; Tue, 13 Dec 2016 15:52:59 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/E2DA17662; dkim=none; dkim-atps=neutral Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: freebsd-current@freebsd.org References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> From: Matthew Seaman Message-ID: <357f7400-3058-d890-c1c5-973d6bde614a@FreeBSD.org> Date: Tue, 13 Dec 2016 15:52:59 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="40JEdxUHi6MRWTEQv2JMFc2aD9ACVB3tm" X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,RCVD_IN_RP_RNBL, RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk 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, 13 Dec 2016 15:53:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --40JEdxUHi6MRWTEQv2JMFc2aD9ACVB3tm Content-Type: multipart/mixed; boundary="BCi629lBvfPCxTO2bCUA9imoxrB7K32W3"; protected-headers="v1" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <357f7400-3058-d890-c1c5-973d6bde614a@FreeBSD.org> Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> In-Reply-To: <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> --BCi629lBvfPCxTO2bCUA9imoxrB7K32W3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016/12/13 15:43, Michael Butler wrote: > On 12/13/16 10:29, Dimitry Andric wrote: >=20 >> Somebody is most likely port scanning your machines. I see this all t= he >> time on boxes connected to the internet. >=20 > As are mine. I wouldn't mind so much if the message contained sufficien= t > useful information that could be acted on, e.g. originating IP address > and, when appropriate, destination port. If you want that sort of information, you can use pf(4) with a default rule to log and reject connections to your system. (Plus rules to permit traffic to legitimate services, obviously.) You can also just 'drop' the denied connections rather than the default response of sending back an ICMP unreachable or reset response, which will save you sending out a lot of itty-bitty packets that the port scanners wouldn't pay attention to anyhow. Cheers, Matthew --BCi629lBvfPCxTO2bCUA9imoxrB7K32W3-- --40JEdxUHi6MRWTEQv2JMFc2aD9ACVB3tm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJYUBlbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnLd4P/3sIOxRp22JNSIEAGaqj/jEX iOW+Hu+aVdOQxDrwHkDFJVfMKWPhqX9iOu8XZAEBLMAtPqlHkB4B91fxmmkZzH3O 6fHrkbvTXN/xf/JL+uE3MIDurPHrLeFW4c+u9KtY5nY7uMQBtbzW7UFYhHp8KNBm euHGCzCeQY4lygxt71gracfzpME/cFvQXM0Up+0XN8cHNt9JiBB4X/llaz/vaa9i P3iny6uGWtUEfsePKcSmEMqk1HwV8slMfM5Quv6gXvSq6HcIqEvmEEHu4gkMGoa7 4onnZ5SqziHqIAtOvEWwBLugg443f9tovLV+wzznJvsKjT5KB8zpvFJB/tmkDLE/ r9nmSMGWN7RytyRt7NXE1ST3Gqj+txDFSa/OzT5RAVNeqXN8GkPmevFuY2+UHEMS TV7uTpoAw4XLJtv26AmBqQcpzPBoZGHQpEkWqRg82v362CVPTYWUq8IPSFR0cZ36 dKI5cwCe02KNpFR0qs5ZhB6nQPIqJFAl+OPUfI7mFiRft3T3YVsrijST861Ns247 Ofdz5HwmRd6B1v0a94ZGSWJdMOYOpp31wuS49mwuMQ45YBHQYUqQkTCvAx38JYKP xeCuvuPJddbI3t8rfW0vQW0jUhYX/u/OdkSvj4c4kbG8KJMbHT+6dPsEY4q2IAZ6 MxGQsCNXj1HjzOdYACN7 =fJn4 -----END PGP SIGNATURE----- --40JEdxUHi6MRWTEQv2JMFc2aD9ACVB3tm-- From owner-freebsd-current@freebsd.org Tue Dec 13 16:07:25 2016 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 60AFCC759E1 for ; Tue, 13 Dec 2016 16:07:25 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA8C31C6C; Tue, 13 Dec 2016 16:07:23 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s=201508; t= 1481645241; bh=gdO+sYXO9fqCqaDUwgPwz6DRHWfShZcXjfcXEhPWrNg=; b=K f0FCFdUc81f7PC9IFKWnFeCef8Iq8TFWVtW12yE6y7TNaeIXd5RPts7Mxv8EKt5U XQ/6mc6pbbEJvUBEjHbZYo15aemqw9KtOygFBkggbwIx6Chm1MXHult+NZM7pctL jQ5+arTF9BEErS0JVMcPm1Ui1CorNHOHNhyUFoQno4= Received: from toshi.auburn.protected-networks.net (unknown [IPv6:2001:470:1f07:4e1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 96CAF1B1D3; Tue, 13 Dec 2016 11:07:20 -0500 (EST) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: Eric van Gyzen , FreeBSD Current , glebius@FreeBSD.org, rrs@FreeBSD.org, jtl@FreeBSD.org References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <689f6fbe-c59f-2e3a-44d6-bc9d19d31bf9@FreeBSD.org> From: Michael Butler Message-ID: <3dbb632b-e095-1d34-d97f-132bbf54245a@protected-networks.net> Date: Tue, 13 Dec 2016 11:07:19 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <689f6fbe-c59f-2e3a-44d6-bc9d19d31bf9@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2016 16:07:25 -0000 On 12/13/16 10:48, Eric van Gyzen wrote: > On 12/13/2016 09:24, Michael Butler wrote: >> Any hints as to why all of my -current equipment is complaining like below. Is >> there a sysctl to moderate/turn this off? >> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 >> packets/sec >> Dec 13 10:00:21 archive last message repeated 13 times >> Dec 13 10:02:21 archive last message repeated 18 times >> Dec 13 10:06:21 archive last message repeated 36 times >> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 >> packets/sec >> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 >> packets/sec >> Dec 13 10:08:21 archive last message repeated 17 times >> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 >> packets/sec >> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 >> packets/sec >> Dec 13 10:10:21 archive last message repeated 17 times >> Dec 13 10:12:21 archive last message repeated 18 times >> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 >> packets/sec >> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 >> packets/sec > > What Subversion revision are you running? Did this start happening after a > recent update? I ask because r309745 was committed a few days ago and might > have changed the behavior. That's consistent with my observations. I was in Australia for a couple of weeks and have just updated from SVN r309056 to r309852, Michael From owner-freebsd-current@freebsd.org Tue Dec 13 16:15:28 2016 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 301B8C75E19 for ; Tue, 13 Dec 2016 16:15:28 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 EE6E42D1; Tue, 13 Dec 2016 16:15:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cGpjh-000OrR-GQ; Tue, 13 Dec 2016 16:15:25 +0000 Date: Tue, 13 Dec 2016 16:15:25 +0000 From: Gary Palmer To: Michael Butler Cc: Dimitry Andric , FreeBSD Current Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec Message-ID: <20161213161525.GA7032@in-addr.com> References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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, 13 Dec 2016 16:15:28 -0000 On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: > On 12/13/16 10:29, Dimitry Andric wrote: > > > Somebody is most likely port scanning your machines. I see this all the > > time on boxes connected to the internet. > > As are mine. I wouldn't mind so much if the message contained sufficient > useful information that could be acted on, e.g. originating IP address > and, when appropriate, destination port. sysctl net.inet.tcp.log_in_vain=1 sysctl net.inet.udp.log_in_vain=1 be prepared for a lot of logs if you are being port scanned Regards, Gary From owner-freebsd-current@freebsd.org Tue Dec 13 16:19:24 2016 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 38FC6C760AD for ; Tue, 13 Dec 2016 16:19:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 064DE8CB; Tue, 13 Dec 2016 16:19:24 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s=201508; t= 1481645959; bh=smWwMKNIXicBEZ2XayiitguJu2JH2nKc6ZRflrHmDwg=; b=I TFsdRk4yzaQuPsj39MAIPNhWTGTMnLL+KVemDV7wpcS6GFcZn2jdSi8GrnyLDzlS r/VnCENbajr5abxlFOoOzkUvRQrE1fII59Td2RxI1xvhD4o9inn1VIFaXYQ6FKxv v+30gmu0Ev5cPy0uQjBsAYCAFVlmkp/Q55uzQFj5zg= Received: from toshi.auburn.protected-networks.net (unknown [IPv6:2001:470:1f07:4e1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 185D31B3A1; Tue, 13 Dec 2016 11:19:18 -0500 (EST) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: Gary Palmer References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> <20161213161525.GA7032@in-addr.com> Cc: Dimitry Andric , FreeBSD Current From: Michael Butler Message-ID: Date: Tue, 13 Dec 2016 11:19:18 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161213161525.GA7032@in-addr.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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, 13 Dec 2016 16:19:24 -0000 On 12/13/16 11:15, Gary Palmer wrote: > On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: >> On 12/13/16 10:29, Dimitry Andric wrote: >> >>> Somebody is most likely port scanning your machines. I see this all the >>> time on boxes connected to the internet. >> >> As are mine. I wouldn't mind so much if the message contained sufficient >> useful information that could be acted on, e.g. originating IP address >> and, when appropriate, destination port. > > sysctl net.inet.tcp.log_in_vain=1 > sysctl net.inet.udp.log_in_vain=1 > > be prepared for a lot of logs if you are being port scanned Or, apparently, have a windoze box on that segment :-( Michael From owner-freebsd-current@freebsd.org Tue Dec 13 16:23:44 2016 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 8BC90C7634C for ; Tue, 13 Dec 2016 16:23:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73C5BE7C; Tue, 13 Dec 2016 16:23:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id uBDGNg1S075842 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Dec 2016 08:23:42 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id uBDGNgvK075841; Tue, 13 Dec 2016 08:23:42 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 13 Dec 2016 08:23:42 -0800 From: Gleb Smirnoff To: Michael Butler Cc: Eric van Gyzen , FreeBSD Current , rrs@FreeBSD.org, jtl@FreeBSD.org Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec Message-ID: <20161213162342.GO27748@FreeBSD.org> References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <689f6fbe-c59f-2e3a-44d6-bc9d19d31bf9@FreeBSD.org> <3dbb632b-e095-1d34-d97f-132bbf54245a@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3dbb632b-e095-1d34-d97f-132bbf54245a@protected-networks.net> User-Agent: Mutt/1.7.0 (2016-08-17) 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, 13 Dec 2016 16:23:44 -0000 On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote: M> On 12/13/16 10:48, Eric van Gyzen wrote: M> > On 12/13/2016 09:24, Michael Butler wrote: M> >> Any hints as to why all of my -current equipment is complaining like below. Is M> >> there a sysctl to moderate/turn this off? M> >> M> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:00:21 archive last message repeated 13 times M> >> Dec 13 10:02:21 archive last message repeated 18 times M> >> Dec 13 10:06:21 archive last message repeated 36 times M> >> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:08:21 archive last message repeated 17 times M> >> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 M> >> packets/sec M> >> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:10:21 archive last message repeated 17 times M> >> Dec 13 10:12:21 archive last message repeated 18 times M> >> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> > M> > What Subversion revision are you running? Did this start happening after a M> > recent update? I ask because r309745 was committed a few days ago and might M> > have changed the behavior. M> M> That's consistent with my observations. I was in Australia for a couple M> of weeks and have just updated from SVN r309056 to r309852, Yes, this is our fail. I will take a look today. -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Tue Dec 13 16:49:40 2016 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 DD2EAC751CD for ; Tue, 13 Dec 2016 16:49:40 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B06BD954; Tue, 13 Dec 2016 16:49:40 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1481647778; bh=f9VqeYwO1 l3Df4s651atY8FbekAaTQM2ecQCr/XGHQM=; b=TAmpkINbYWx/Gax+jmhB2Y2SH 2TzYW3rWMBJpz+GaYw4ZzsEyC1/ADpAlkbJSFilzvTo6px4CzamdZ4r56FiWOaFX AmsZy5RETa2Ayre/WvJCUjCgCstdm4l1qzMedzLeB3ktPt2dAylr2eukaCh9ntnv 3lfJv6PkerZ06Vi/U4= Received: from toshi.auburn.protected-networks.net (unknown [IPv6:2001:470:1f07:4e1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id C24461B734; Tue, 13 Dec 2016 11:49:38 -0500 (EST) To: FreeBSD Current Cc: kib@freebsd.org From: Michael Butler Subject: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current Message-ID: <57abe23a-d7b5-953c-9119-c1d281106db6@protected-networks.net> Date: Tue, 13 Dec 2016 11:49:37 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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, 13 Dec 2016 16:49:41 -0000 I've been bitten by this twice on a KDE desktop in the last 24 hours .. same error on both occasions :-( error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped) [ .. ] error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped) I see only one change in the dev/drm2 sources (r309712) but there have been many in the vm code. Any hints/pointers appreciated, Michael From owner-freebsd-current@freebsd.org Tue Dec 13 17:07:49 2016 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 AD420C75C25 for ; Tue, 13 Dec 2016 17:07:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 299D218F1 for ; Tue, 13 Dec 2016 17:07:48 +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 uBDH7dam016331 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 19:07:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDH7dam016331 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDH7d0r016330; Tue, 13 Dec 2016 19:07:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 19:07:39 +0200 From: Konstantin Belousov To: Michael Butler Cc: FreeBSD Current Subject: Re: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current Message-ID: <20161213170739.GB54029@kib.kiev.ua> References: <57abe23a-d7b5-953c-9119-c1d281106db6@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57abe23a-d7b5-953c-9119-c1d281106db6@protected-networks.net> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 17:07:49 -0000 On Tue, Dec 13, 2016 at 11:49:37AM -0500, Michael Butler wrote: > I've been bitten by this twice on a KDE desktop in the last 24 hours .. > same error on both occasions :-( > > error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count > == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT > pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped) > > [ .. ] > > error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON: > obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT > pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped) > > I see only one change in the dev/drm2 sources (r309712) but there have > been many in the vm code. > > Any hints/pointers appreciated, This is indeed a bug in r309712, it seems. Please try this. diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c index 2a53ae8f8ed..0fa5249e553 100644 --- a/sys/dev/drm2/i915/i915_gem.c +++ b/sys/dev/drm2/i915/i915_gem.c @@ -1521,7 +1521,7 @@ retry: /* Now bind it into the GTT if needed */ ret = i915_gem_object_pin(obj, 0, true, false); if (ret) - goto unpin; + goto unlock; pinned = 1; ret = i915_gem_object_set_to_gtt_domain(obj, write); @@ -1580,6 +1580,8 @@ have_page: return (VM_PAGER_OK); unpin: + i915_gem_object_unpin(obj); +unlock: DRM_UNLOCK(dev); out: KASSERT(ret != 0, ("i915_gem_pager_fault: wrong return")); From owner-freebsd-current@freebsd.org Tue Dec 13 17:25:02 2016 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 DE240C76658 for ; Tue, 13 Dec 2016 17:25:02 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 A9825E1A; Tue, 13 Dec 2016 17:25:02 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cGqp3-000P18-9R; Tue, 13 Dec 2016 17:25:01 +0000 Date: Tue, 13 Dec 2016 17:25:01 +0000 From: Gary Palmer To: Michael Butler Cc: Dimitry Andric , FreeBSD Current Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec Message-ID: <20161213172501.GB7032@in-addr.com> References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <8332C070-E7C8-4CF3-B5DF-2355D9FA20D1@FreeBSD.org> <1eb2e94b-c460-8116-8ffc-f7884be644f7@protected-networks.net> <20161213161525.GA7032@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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, 13 Dec 2016 17:25:03 -0000 On Tue, Dec 13, 2016 at 11:19:18AM -0500, Michael Butler wrote: > On 12/13/16 11:15, Gary Palmer wrote: > > On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: > >> On 12/13/16 10:29, Dimitry Andric wrote: > >> > >>> Somebody is most likely port scanning your machines. I see this all the > >>> time on boxes connected to the internet. > >> > >> As are mine. I wouldn't mind so much if the message contained sufficient > >> useful information that could be acted on, e.g. originating IP address > >> and, when appropriate, destination port. > > > > sysctl net.inet.tcp.log_in_vain=1 > > sysctl net.inet.udp.log_in_vain=1 > > > > be prepared for a lot of logs if you are being port scanned > > Or, apparently, have a windoze box on that segment :-( Windows client boxes at least do a lot of broadcasts, but in my experience they don't trigger log_in_vain (maybe they will if you have promisc network interfaces enabled). Not sure about servers as I don't have any at home. Gary From owner-freebsd-current@freebsd.org Tue Dec 13 17:25:39 2016 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 69431C766F2 for ; Tue, 13 Dec 2016 17:25:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECD6BF55 for ; Tue, 13 Dec 2016 17:25: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 uBDHPTCc020276 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Dec 2016 19:25:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBDHPTCc020276 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBDHPTbU020274; Tue, 13 Dec 2016 19:25:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2016 19:25:29 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213172529.GC54029@kib.kiev.ua> References: <20161212233714.GA90401@zxy.spb.ru> <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213152838.GL90287@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2016 17:25:39 -0000 On Tue, Dec 13, 2016 at 06:28:38PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote: > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=0000000000099c00 > SMAP type=02 base=0000000000099c00 len=0000000000006400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000007906b000 > SMAP type=02 base=000000007916b000 len=0000000000936000 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > SMAP type=02 base=0000000079faa000 len=0000000002056000 > SMAP type=01 base=0000000100000000 len=0000001f80000000 > SMAP type=02 base=000000007c000000 len=0000000014000000 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > SMAP type=02 base=00000000ff000000 len=0000000001000000 > TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 This is not what I expected. Also, I realized that I mis-read the memory test code. It does not obliterate memory, old content is preserved. Please do exactly the same testing with another patch, at the end of the message. There could be more output, up to 256 lines. > > > If the patched kernel boots succesfully, or if the patched kernel > > boots further, I will provide one more, last patch, to test. > > please, next time point what verion of source need to patch: vanila or > already patched. I usually send full patches, i.e. the patch must be applied to the clean checkout. Patch the vanilla sources. diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..1be7a629f65 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) mbp->msg_ptr = ptr; mbp->msg_size = size; mbp->msg_seqmod = SEQMOD(size); +printf("YYY1\n"); msgbuf_clear(mbp); +printf("YYY2\n"); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_flags = 0; +printf("YYY3\n"); bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); +printf("YYY4\n"); } + /* * Reinitialize a message buffer, retaining its previous contents if * the size and checksum are correct. If the old contents cannot be @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { +printf("XXX1\n"); msgbuf_init(mbp, ptr, size); +printf("XXX2\n"); return; } mbp->msg_seqmod = SEQMOD(size); @@ -117,10 +124,12 @@ void msgbuf_clear(struct msgbuf *mbp) { +printf("ZZZ1\n"); bzero(mbp->msg_ptr, mbp->msg_size); mbp->msg_wseq = 0; mbp->msg_rseq = 0; mbp->msg_cksum = 0; +printf("ZZZ2\n"); } /* diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c index e78863830c7..a72984dbc19 100644 --- a/sys/kern/subr_prf.c +++ b/sys/kern/subr_prf.c @@ -998,6 +998,14 @@ msgbufinit(void *ptr, int size) char *cp; static struct msgbuf *oldp = NULL; +printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size); +for (int i = 0; i < size; i++) { +if (i % PAGE_SIZE == 0) printf(". %x\n", i); + volatile char *c = (char *)ptr + i; + char tmp; + tmp = *c; + *c = tmp; +} size -= sizeof(*msgbufp); cp = (char *)ptr; msgbufp = (struct msgbuf *)(cp + size); From owner-freebsd-current@freebsd.org Tue Dec 13 17:45:25 2016 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 59FE4C76DE2 for ; Tue, 13 Dec 2016 17:45:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 1BF0B1CC0 for ; Tue, 13 Dec 2016 17:45:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cGr7B-0003FY-QE; Tue, 13 Dec 2016 20:43:45 +0300 Date: Tue, 13 Dec 2016 20:43:45 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161213174345.GB98176@zxy.spb.ru> References: <20161213110535.GS54029@kib.kiev.ua> <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213172529.GC54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 13 Dec 2016 17:45:25 -0000 On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > This is not what I expected. > Also, I realized that I mis-read the memory test code. It does not > obliterate memory, old content is preserved. > > Please do exactly the same testing with another patch, at the end of the > message. There could be more output, up to 256 lines. No problem. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000099c00 SMAP type=02 base=0000000000099c00 len=0000000000006400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007906b000 SMAP type=02 base=000000007916b000 len=0000000000936000 SMAP type=04 base=0000000079aa1000 len=0000000000509000 SMAP type=02 base=0000000079faa000 len=0000000002056000 SMAP type=01 base=0000000100000000 len=0000001f80000000 SMAP type=02 base=000000007c000000 len=0000000014000000 SMAP type=02 base=00000000fed1c000 len=0000000000029000 SMAP type=02 base=00000000ff000000 len=0000000001000000 TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 . 0 . 1000 . 2000 . 3000 . 4000 . 5000 . 6000 . 7000 . 8000 . 9000 . a000 . b000 . c000 . d000 . e000 . f000 . 10000 . 11000 . 12000 . 13000 . 14000 . 15000 . 16000 . 17000 . 18000 . 19000 . 1a000 . 1b000 . 1c000 . 1d000 . 1e000 . 1f000 . 20000 . 21000 . 22000 . 23000 . 24000 . 25000 . 26000 . 27000 . 28000 . 29000 . 2a000 . 2b000 > > > > > If the patched kernel boots succesfully, or if the patched kernel > > > boots further, I will provide one more, last patch, to test. > > > > please, next time point what verion of source need to patch: vanila or > > already patched. > I usually send full patches, i.e. the patch must be applied to the clean > checkout. Patch the vanilla sources. np. From owner-freebsd-current@freebsd.org Tue Dec 13 18:04:25 2016 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 CEBB1C764FE for ; Tue, 13 Dec 2016 18:04:25 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 B2F62E2E for ; Tue, 13 Dec 2016 18:04:25 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 75D38BD87 for ; Tue, 13 Dec 2016 18:04:18 +0000 (UTC) Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec To: freebsd-current@freebsd.org References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> From: Allan Jude Message-ID: <9412c59f-f2d9-4bda-470e-78f41e11e7f5@freebsd.org> Date: Tue, 13 Dec 2016 13:04:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> Content-Type: text/plain; charset=windows-1252 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, 13 Dec 2016 18:04:25 -0000 On 2016-12-13 10:24, Michael Butler wrote: > Any hints as to why all of my -current equipment is complaining like > below. Is there a sysctl to moderate/turn this off? > > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to > 200 packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 > to 200 packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to > 200 packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:14:21 archive last message repeated 17 times > Dec 13 10:16:21 archive last message repeated 18 times > > Michael > _______________________________________________ > 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" Yeah, this is a bug. When working as intended, the message would read: kernel: Limiting closed port RST response from 201 to 200 packets/sec The first value would be higher than the 2nd value (net.inet.icmp.icmplim). It should only alert if it is actually limiting the response rate. You can mute it by setting: net.inet.icmp.icmplim_output=0 -- Allan Jude From owner-freebsd-current@freebsd.org Tue Dec 13 18:45:35 2016 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 7458BC7630F for ; Tue, 13 Dec 2016 18:45:35 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D30D91056 for ; Tue, 13 Dec 2016 18:45:33 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s=201508; t= 1481654729; bh=vGp3Vq2WnrRB4he84uHEzUwOQFSYlVu2/J4Trpa+rV8=; b=U cD+dMWJ9/RH5V/VGB79yrO1AtewJxoC/b2z8jhAU+Z+CAfSHK+vWhZXqrMJcUXE6 6eoJ37hmvb1qLFxYfjXjV0ZsDWdWVpTOiwhQ8IJR/RfJUAnNxpEXkK53i10D1J+k c9x8qhhyU3ljPL30QD4cERGuI9FWNbt4tipXxLN78w= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 3C9541BEF4; Tue, 13 Dec 2016 13:45:29 -0500 (EST) Subject: Re: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current To: Konstantin Belousov References: <57abe23a-d7b5-953c-9119-c1d281106db6@protected-networks.net> <20161213170739.GB54029@kib.kiev.ua> Cc: FreeBSD Current From: Michael Butler Message-ID: <6c7a60d3-f46e-c0af-3d8d-ee57f1cb0e44@protected-networks.net> Date: Tue, 13 Dec 2016 13:45:28 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161213170739.GB54029@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2016 18:45:35 -0000 On 12/13/16 12:07, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 11:49:37AM -0500, Michael Butler wrote: >> I've been bitten by this twice on a KDE desktop in the last 24 hours .. >> same error on both occasions :-( >> >> error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count >> == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT >> pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped) >> >> [ .. ] >> >> error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON: >> obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT >> pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped) >> >> I see only one change in the dev/drm2 sources (r309712) but there have >> been many in the vm code. >> >> Any hints/pointers appreciated, > > This is indeed a bug in r309712, it seems. Please try this. > > diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c > index 2a53ae8f8ed..0fa5249e553 100644 > --- a/sys/dev/drm2/i915/i915_gem.c > +++ b/sys/dev/drm2/i915/i915_gem.c > @@ -1521,7 +1521,7 @@ retry: [ .. ] That seems to have fixed it - thanks for the quick response :-) Michael From owner-freebsd-current@freebsd.org Tue Dec 13 20:12:21 2016 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 122C5C76CF4 for ; Tue, 13 Dec 2016 20:12:21 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE3E5FBE; Tue, 13 Dec 2016 20:12:20 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id uBDKCDr0077781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Dec 2016 12:12:14 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id uBDKCDVl077780; Tue, 13 Dec 2016 12:12:13 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 13 Dec 2016 12:12:13 -0800 From: Gleb Smirnoff To: Michael Butler Cc: Eric van Gyzen , FreeBSD Current , rrs@FreeBSD.org, jtl@FreeBSD.org Subject: Re: Log spam: Limiting * response from 1 to 200 packets/sec Message-ID: <20161213201213.GQ27748@FreeBSD.org> References: <630314dc-e14f-02e7-aa48-4456b0feeef9@protected-networks.net> <689f6fbe-c59f-2e3a-44d6-bc9d19d31bf9@FreeBSD.org> <3dbb632b-e095-1d34-d97f-132bbf54245a@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3dbb632b-e095-1d34-d97f-132bbf54245a@protected-networks.net> User-Agent: Mutt/1.7.0 (2016-08-17) 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, 13 Dec 2016 20:12:21 -0000 On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote: M> >> Any hints as to why all of my -current equipment is complaining like below. Is M> >> there a sysctl to moderate/turn this off? M> >> M> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:00:21 archive last message repeated 13 times M> >> Dec 13 10:02:21 archive last message repeated 18 times M> >> Dec 13 10:06:21 archive last message repeated 36 times M> >> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:08:21 archive last message repeated 17 times M> >> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 M> >> packets/sec M> >> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:10:21 archive last message repeated 17 times M> >> Dec 13 10:12:21 archive last message repeated 18 times M> >> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> > M> > What Subversion revision are you running? Did this start happening after a M> > recent update? I ask because r309745 was committed a few days ago and might M> > have changed the behavior. M> M> That's consistent with my observations. I was in Australia for a couple M> of weeks and have just updated from SVN r309056 to r309852, The r310032 should fix it. I'm sorry for the problem. -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Wed Dec 14 01:31:06 2016 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 E5890C7558D for ; Wed, 14 Dec 2016 01:31:06 +0000 (UTC) (envelope-from qiz@vmware.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 B57A0180B for ; Wed, 14 Dec 2016 01:31:06 +0000 (UTC) (envelope-from qiz@vmware.com) Received: by mailman.ysv.freebsd.org (Postfix) id B4CE3C7558C; Wed, 14 Dec 2016 01:31:06 +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 B474CC75589 for ; Wed, 14 Dec 2016 01:31:06 +0000 (UTC) (envelope-from qiz@vmware.com) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0072.outbound.protection.outlook.com [104.47.42.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6E61809 for ; Wed, 14 Dec 2016 01:31:05 +0000 (UTC) (envelope-from qiz@vmware.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9787Oxz+9txRXsh7ao1fNwW6q6lqE9wR/Pz11SAofZI=; b=ozXJCLDBd8sbKQ55k7uaN43L73GsKFGQaxi1r43YmTnziHrNZ0Jo69w4yME+ssuMRAQuqbc72dmbmuDWfTwpzdJHSUHgwM/FeViaNHN2sUuG3WnyS9SuIWZIju4AI/DKrIxaesXO2dndxus7x1jecO4PA7QdNWC405VFLwlLWUU= Received: from CY1PR05MB2748.namprd05.prod.outlook.com (10.167.18.18) by CY1PR05MB2746.namprd05.prod.outlook.com (10.167.18.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 14 Dec 2016 01:31:04 +0000 Received: from CY1PR05MB2748.namprd05.prod.outlook.com ([10.167.18.18]) by CY1PR05MB2748.namprd05.prod.outlook.com ([10.167.18.18]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 01:31:04 +0000 From: Qi Zhang To: "current@freebsd.org" Subject: Questions about FreeBSD support for NVDIMM Thread-Topic: Questions about FreeBSD support for NVDIMM Thread-Index: AdJVpZua7gSunwiCSd+6kLj6ZuNj9w== Date: Wed, 14 Dec 2016 01:31:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=qiz@vmware.com; x-originating-ip: [208.91.1.34] x-ms-office365-filtering-correlation-id: db80012d-9341-4e52-d390-08d423c0de9e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2746; x-microsoft-exchange-diagnostics: 1; CY1PR05MB2746; 7:mslq6cc8aCEpm7Q4LuqTOOEW04ioufjmJvuub5FRT90BI4QPgYZ1qZu8QvHokigaVr6NfuyuLUoSTwU4aNxb4FViUfjAuDHTE9jnthCFgBZF8+vneU12kEzSbr0+pRzupCmlRdI4LdR0omNep90T8VuHAH+TKHpfyJkLWRRiVjXRDXdy/voH1E034eg9Ierlkl9d3uVGNArwnj6qFAhJmVPf/G9ki6v8WO50lbkvTxrsmOpCNnWM9j1mHr5qUJf6hoghOGRcHxc+L0F1DCJgqwJJvwrovIk4pU4eMU02EGixlrtOdYLUEw+ZXiJrDSSgJ15qeGBmcZ6/cuUG9a82+kW2TjaHlG0Y3ho2L/rrue/191KX+hdzC/kwz6t0FeAh8cEMLHnoUvH2G7thzNWPe6zy12mTHLS9yN+C6md4+voYIBCT64xix2BP8JzieGfdS9I+cRrfRm10sVpUm/e71A==; 20:mLgbheFB1N0EcxB/BwtJRph3KP3CvaOuBlWgVkQH/jCNy1t6LZ/+E1/yTgYekJklfHHMQsdVrsjkL9Q+bvgOdCNoZR0xnMhYHVUxvjM3SLQWlmaJNA8RBWvwsqY+PCjng23voLI++qeLedbYJB+kjHp1/k4N97bNnFVCmSH1CrY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR05MB2746; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2746; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377424004)(189002)(199003)(33656002)(6116002)(8936002)(3846002)(102836003)(97736004)(5640700002)(8676002)(107886002)(86362001)(7736002)(74316002)(76576001)(6506006)(106356001)(105586002)(3280700002)(2351001)(101416001)(92566002)(99286002)(450100001)(110136003)(77096006)(122556002)(38730400001)(2900100001)(5660300001)(7696004)(6916009)(2906002)(1730700003)(2501003)(81156014)(305945005)(9686002)(50986999)(68736007)(81166006)(6436002)(54356999)(66066001)(189998001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR05MB2746; H:CY1PR05MB2748.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 01:31:03.8663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2746 X-Mailman-Approved-At: Wed, 14 Dec 2016 05:35:53 +0000 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: Wed, 14 Dec 2016 01:31:07 -0000 Dear FreeBSD folks, I am Qi Zhang from VMware Guest OS Validation team. And I am doing some inv= estigation about NVDIMM supporint in FreeBSD. I heard from George Neville-N= eil that NVDIMM support in FreeBSD has been moving along for a while. But I= couldn't find detail project description from freebsd.org, but only one pi= ece information about "Have "Traditional" NVDIMM support (rpokala@)" on htt= ps://wiki.freebsd.org/VendorDevSummit/201611/HaveNeedWant. Can you please s= hare with me what is the progress and schedule for FreeBSD supporting NVDIM= M? If you can share more details with me, I will much appreciate. Thanks Best Regards - Qi (Keira) GOSV | 18F, Raycom, Beijing | +86-10-599 34604 From owner-freebsd-current@freebsd.org Wed Dec 14 08:13:41 2016 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 55434C774A4 for ; Wed, 14 Dec 2016 08:13:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 42E831A3C for ; Wed, 14 Dec 2016 08:13:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4247AC774A3; Wed, 14 Dec 2016 08:13: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 41EF3C774A2 for ; Wed, 14 Dec 2016 08:13:41 +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 0DA821A3A for ; Wed, 14 Dec 2016 08:13:40 +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 3011E1FE157; Wed, 14 Dec 2016 09:13:38 +0100 (CET) Subject: Re: Help To: Lewis ingraham , current@freebsd.org References: From: Hans Petter Selasky Message-ID: <490d5253-c8ce-62da-dc62-ade73b9c5683@selasky.org> Date: Wed, 14 Dec 2016 09:13:11 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 14 Dec 2016 08:13:41 -0000 On 12/13/16 05:08, Lewis ingraham wrote: > 4. Another potential problem with usb drive detection as well. Usb ports > work just fine in something like windows and linux but not FreeBSD. Can you show dmesg of failed enumerations? Did you try to set some device quirks? --HPS From owner-freebsd-current@freebsd.org Wed Dec 14 09:54:01 2016 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 3F2D9C76A96 for ; Wed, 14 Dec 2016 09:54:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAE0819D8 for ; Wed, 14 Dec 2016 09:54:00 +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 uBE9rp4W076446 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 11:53:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBE9rp4W076446 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBE9rpV3076445; Wed, 14 Dec 2016 11:53:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 11:53:50 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214095350.GE94325@kib.kiev.ua> References: <20161213111437.GH90287@zxy.spb.ru> <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213174345.GB98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 09:54:01 -0000 On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > This is not what I expected. > > Also, I realized that I mis-read the memory test code. It does not > > obliterate memory, old content is preserved. > > > > Please do exactly the same testing with another patch, at the end of the > > message. There could be more output, up to 256 lines. > > No problem. > > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=0000000000099c00 > SMAP type=02 base=0000000000099c00 len=0000000000006400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000007906b000 > SMAP type=02 base=000000007916b000 len=0000000000936000 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > SMAP type=02 base=0000000079faa000 len=0000000002056000 > SMAP type=01 base=0000000100000000 len=0000001f80000000 > SMAP type=02 base=000000007c000000 len=0000000014000000 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > SMAP type=02 base=00000000ff000000 len=0000000001000000 > TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 > . 0 > . 1000 > . 2000 > . 3000 > . 4000 > . 5000 > . 6000 > . 7000 > . 8000 > . 9000 > . a000 > . b000 > . c000 > . d000 > . e000 > . f000 > . 10000 > . 11000 > . 12000 > . 13000 > . 14000 > . 15000 > . 16000 > . 17000 > . 18000 > . 19000 > . 1a000 > . 1b000 > . 1c000 > . 1d000 > . 1e000 > . 1f000 > . 20000 > . 21000 > . 22000 > . 23000 > . 24000 > . 25000 > . 26000 > . 27000 > . 28000 > . 29000 > . 2a000 > . 2b000 > Do you still have access to the machine ? If yes, please try this patch (against clean tree, as always) with the same instructions as before. diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index b2283339405..917ea4475f3 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -1673,6 +1673,14 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D); /* + * Temporary forge some valid pointer to PCB, for exception + * handlers. It is reinitialized properly below after FPU is + * set up. + */ + cpu_max_ext_state_size = sizeof(struct savefpu); + thread0.td_pcb = get_pcb_td(&thread0); + + /* * The console and kdb should be initialized even earlier than here, * but some console drivers don't work until after getmemsize(). * Default to late console initialization to support these drivers. diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..1be7a629f65 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) mbp->msg_ptr = ptr; mbp->msg_size = size; mbp->msg_seqmod = SEQMOD(size); +printf("YYY1\n"); msgbuf_clear(mbp); +printf("YYY2\n"); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_flags = 0; +printf("YYY3\n"); bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); +printf("YYY4\n"); } + /* * Reinitialize a message buffer, retaining its previous contents if * the size and checksum are correct. If the old contents cannot be @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { +printf("XXX1\n"); msgbuf_init(mbp, ptr, size); +printf("XXX2\n"); return; } mbp->msg_seqmod = SEQMOD(size); @@ -117,10 +124,12 @@ void msgbuf_clear(struct msgbuf *mbp) { +printf("ZZZ1\n"); bzero(mbp->msg_ptr, mbp->msg_size); mbp->msg_wseq = 0; mbp->msg_rseq = 0; mbp->msg_cksum = 0; +printf("ZZZ2\n"); } /* diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c index e78863830c7..a72984dbc19 100644 --- a/sys/kern/subr_prf.c +++ b/sys/kern/subr_prf.c @@ -998,6 +998,14 @@ msgbufinit(void *ptr, int size) char *cp; static struct msgbuf *oldp = NULL; +printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size); +for (int i = 0; i < size; i++) { +if (i % PAGE_SIZE == 0) printf(". %x\n", i); + volatile char *c = (char *)ptr + i; + char tmp; + tmp = *c; + *c = tmp; +} size -= sizeof(*msgbufp); cp = (char *)ptr; msgbufp = (struct msgbuf *)(cp + size); From owner-freebsd-current@freebsd.org Wed Dec 14 10:27:18 2016 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 66820C7745C for ; Wed, 14 Dec 2016 10:27:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DE911CCD for ; Wed, 14 Dec 2016 10:27:17 +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 uBEARCnH084939 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 12:27:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBEARCnH084939 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBEARCW5084938; Wed, 14 Dec 2016 12:27:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 12:27:11 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214102711.GF94325@kib.kiev.ua> References: <20161213112340.GT54029@kib.kiev.ua> <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214095350.GE94325@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 10:27:18 -0000 On Wed, Dec 14, 2016 at 11:53:50AM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > > > This is not what I expected. > > > Also, I realized that I mis-read the memory test code. It does not > > > obliterate memory, old content is preserved. > > > > > > Please do exactly the same testing with another patch, at the end of the > > > message. There could be more output, up to 256 lines. > > > > No problem. > > > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 > > . 0 > > . 1000 > > . 2000 > > . 3000 > > . 4000 > > . 5000 > > . 6000 > > . 7000 > > . 8000 > > . 9000 > > . a000 > > . b000 > > . c000 > > . d000 > > . e000 > > . f000 > > . 10000 > > . 11000 > > . 12000 > > . 13000 > > . 14000 > > . 15000 > > . 16000 > > . 17000 > > . 18000 > > . 19000 > > . 1a000 > > . 1b000 > > . 1c000 > > . 1d000 > > . 1e000 > > . 1f000 > > . 20000 > > . 21000 > > . 22000 > > . 23000 > > . 24000 > > . 25000 > > . 26000 > > . 27000 > > . 28000 > > . 29000 > > . 2a000 > > . 2b000 > > > > Do you still have access to the machine ? > If yes, please try this patch (against clean tree, as always) with the > same instructions as before. > Updated patch, it should provide the expected information in case of page fault. diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index b2283339405..682307f5fe4 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -1673,6 +1673,16 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D); /* + * Temporary forge some valid pointer to PCB, for exception + * handlers. It is reinitialized properly below after FPU is + * set up. Also set up td_critnest to short-cut the page + * fault handler. + */ + cpu_max_ext_state_size = sizeof(struct savefpu); + thread0.td_pcb = get_pcb_td(&thread0); + thread0.td_critnest = 1; + + /* * The console and kdb should be initialized even earlier than here, * but some console drivers don't work until after getmemsize(). * Default to late console initialization to support these drivers. @@ -1762,6 +1772,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) #ifdef FDT x86_init_fdt(); #endif + thread0.td_critnest = 0; /* Location of kernel stack for locore */ return ((u_int64_t)thread0.td_pcb); diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index f275aef3b4f..1be7a629f65 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) mbp->msg_ptr = ptr; mbp->msg_size = size; mbp->msg_seqmod = SEQMOD(size); +printf("YYY1\n"); msgbuf_clear(mbp); +printf("YYY2\n"); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_flags = 0; +printf("YYY3\n"); bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); +printf("YYY4\n"); } + /* * Reinitialize a message buffer, retaining its previous contents if * the size and checksum are correct. If the old contents cannot be @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) { u_int cksum; - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) { +printf("XXX1\n"); msgbuf_init(mbp, ptr, size); +printf("XXX2\n"); return; } mbp->msg_seqmod = SEQMOD(size); @@ -117,10 +124,12 @@ void msgbuf_clear(struct msgbuf *mbp) { +printf("ZZZ1\n"); bzero(mbp->msg_ptr, mbp->msg_size); mbp->msg_wseq = 0; mbp->msg_rseq = 0; mbp->msg_cksum = 0; +printf("ZZZ2\n"); } /* diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c index e78863830c7..a72984dbc19 100644 --- a/sys/kern/subr_prf.c +++ b/sys/kern/subr_prf.c @@ -998,6 +998,14 @@ msgbufinit(void *ptr, int size) char *cp; static struct msgbuf *oldp = NULL; +printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size); +for (int i = 0; i < size; i++) { +if (i % PAGE_SIZE == 0) printf(". %x\n", i); + volatile char *c = (char *)ptr + i; + char tmp; + tmp = *c; + *c = tmp; +} size -= sizeof(*msgbufp); cp = (char *)ptr; msgbufp = (struct msgbuf *)(cp + size); From owner-freebsd-current@freebsd.org Wed Dec 14 10:52:15 2016 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 16DBAC779FF for ; Wed, 14 Dec 2016 10:52:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 C691F1A89 for ; Wed, 14 Dec 2016 10:52:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cH7AR-000BK9-GU; Wed, 14 Dec 2016 13:52:11 +0300 Date: Wed, 14 Dec 2016 13:52:11 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214105211.GC98176@zxy.spb.ru> References: <20161213124931.GI90287@zxy.spb.ru> <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214102711.GF94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 10:52:15 -0000 On Wed, Dec 14, 2016 at 12:27:11PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 11:53:50AM +0200, Konstantin Belousov wrote: > > On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > > > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > > > > > This is not what I expected. > > > > Also, I realized that I mis-read the memory test code. It does not > > > > obliterate memory, old content is preserved. > > > > > > > > Please do exactly the same testing with another patch, at the end of the > > > > message. There could be more output, up to 256 lines. > > > > > > No problem. > > > > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > SMAP type=01 base=0000000000000000 len=0000000000099c00 > > > SMAP type=02 base=0000000000099c00 len=0000000000006400 > > > SMAP type=02 base=00000000000e0000 len=0000000000020000 > > > SMAP type=01 base=0000000000100000 len=000000007906b000 > > > SMAP type=02 base=000000007916b000 len=0000000000936000 > > > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > > > SMAP type=02 base=0000000079faa000 len=0000000002056000 > > > SMAP type=01 base=0000000100000000 len=0000001f80000000 > > > SMAP type=02 base=000000007c000000 len=0000000014000000 > > > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > > > SMAP type=02 base=00000000ff000000 len=0000000001000000 > > > TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 > > > . 0 > > > . 1000 > > > . 2000 > > > . 3000 > > > . 4000 > > > . 5000 > > > . 6000 > > > . 7000 > > > . 8000 > > > . 9000 > > > . a000 > > > . b000 > > > . c000 > > > . d000 > > > . e000 > > > . f000 > > > . 10000 > > > . 11000 > > > . 12000 > > > . 13000 > > > . 14000 > > > . 15000 > > > . 16000 > > > . 17000 > > > . 18000 > > > . 19000 > > > . 1a000 > > > . 1b000 > > > . 1c000 > > > . 1d000 > > > . 1e000 > > > . 1f000 > > > . 20000 > > > . 21000 > > > . 22000 > > > . 23000 > > > . 24000 > > > . 25000 > > > . 26000 > > > . 27000 > > > . 28000 > > > . 29000 > > > . 2a000 > > > . 2b000 > > > > > > > Do you still have access to the machine ? > > If yes, please try this patch (against clean tree, as always) with the > > same instructions as before. > > > > Updated patch, it should provide the expected information in case of > page fault. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000099c00 SMAP type=02 base=0000000000099c00 len=0000000000006400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007906b000 SMAP type=02 base=000000007916b000 len=0000000000936000 SMAP type=04 base=0000000079aa1000 len=0000000000509000 SMAP type=02 base=0000000079faa000 len=0000000002056000 SMAP type=01 base=0000000100000000 len=0000001f80000000 SMAP type=02 base=000000007c000000 len=0000000014000000 SMAP type=02 base=00000000fed1c000 len=0000000000029000 SMAP type=02 base=00000000ff000000 len=0000000001000000 TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 . 0 . 1000 . 2000 . 3000 . 4000 . 5000 . 6000 . 7000 . 8000 . 9000 . a000 . b000 . c000 . d000 . e000 . f000 . 10000 . 11000 . 12000 . 13000 . 14000 . 15000 . 16000 . 17000 . 18000 . 19000 . 1a000 . 1b000 . 1c000 . 1d000 . 1e000 . 1f000 . 20000 . 21000 . 22000 . 23000 . 24000 . 25000 . 26000 . 27000 . 28000 . 29000 . 2a000 . 2b000 From owner-freebsd-current@freebsd.org Wed Dec 14 11:39:37 2016 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 68FBEC763B8 for ; Wed, 14 Dec 2016 11:39:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10C351F4A for ; Wed, 14 Dec 2016 11:39:36 +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 uBEBdRrw001979 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 13:39:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBEBdRrw001979 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBEBdRjG001977; Wed, 14 Dec 2016 13:39:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 13:39:27 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214113927.GG94325@kib.kiev.ua> References: <20161213135759.GY54029@kib.kiev.ua> <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214105211.GC98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 11:39:37 -0000 On Wed, Dec 14, 2016 at 01:52:11PM +0300, Slawa Olhovchenkov wrote: > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=0000000000099c00 > SMAP type=02 base=0000000000099c00 len=0000000000006400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000007906b000 > SMAP type=02 base=000000007916b000 len=0000000000936000 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 > SMAP type=02 base=0000000079faa000 len=0000000002056000 > SMAP type=01 base=0000000100000000 len=0000001f80000000 > SMAP type=02 base=000000007c000000 len=0000000014000000 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 > SMAP type=02 base=00000000ff000000 len=0000000001000000 > TTT1 0xfffff8207ff00000 0xfffff8207fffffb8 100000 > . 0 > . 1000 > . 2000 > . 3000 > . 4000 > . 5000 > . 6000 > . 7000 > . 8000 > . 9000 > . a000 > . b000 > . c000 > . d000 > . e000 > . f000 > . 10000 > . 11000 > . 12000 > . 13000 > . 14000 > . 15000 > . 16000 > . 17000 > . 18000 > . 19000 > . 1a000 > . 1b000 > . 1c000 > . 1d000 > . 1e000 > . 1f000 > . 20000 > . 21000 > . 22000 > . 23000 > . 24000 > . 25000 > . 26000 > . 27000 > . 28000 > . 29000 > . 2a000 > . 2b000 In other words, it is almost certainly the hang and not a fault causing hang. This means that the machine is not compliant with the IA32 architecture, in particular, the region reported as normal memory by E820 BIOS service does not behave as normal memory. Since regardless of the option setting, the memory map is same, and bootstrap page table only depend on the memory map, we use the same page table when hanging and when operating correctly. We do not fault or hang when the option is turned off, which together with the improved early fault handling in the patch, makes it almost certain that the problem is in hardware configuration and not in our early setup. Of course, the most puzzling part is that memory test makes the hang go away, while repeating memory test operation only on the msgbuf region does not. msgbuf is special in that it is located at TOHM (top of high memory). It spans 128KB from below it to the last byte of the last physical segment. The only ideas I have right now is that there is either a bug in the Caching Agent/Home agent/IMC configuration in BIOS, in which case there is nothing OS can do to mitigate it. Or it might be that the memory map reported by CMS is wrong (you said that you use legacy boot, right ?). This is not too surprising if true, because non-EFI boot code path definitely get less and less testing. For the later case (potential bug in CMS), could you switch to EFI boot mode and see whether the issue magically healths itself ? You could boot from USB stick in EFI mode without reinstalling for test. Do you use latest BIOS for your motherboard ? From owner-freebsd-current@freebsd.org Wed Dec 14 12:13:40 2016 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 73E98C77A4E for ; Wed, 14 Dec 2016 12:13:40 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 34E681A4C for ; Wed, 14 Dec 2016 12:13:40 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cH8RE-000DbJ-IJ; Wed, 14 Dec 2016 15:13:36 +0300 Date: Wed, 14 Dec 2016 15:13:36 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214121336.GD98176@zxy.spb.ru> References: <20161213141114.GJ90287@zxy.spb.ru> <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214113927.GG94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 12:13:40 -0000 On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > In other words, it is almost certainly the hang and not a fault causing > hang. This means that the machine is not compliant with the IA32 > architecture, in particular, the region reported as normal memory by > E820 BIOS service does not behave as normal memory. > > Since regardless of the option setting, the memory map is same, and > bootstrap page table only depend on the memory map, we use the same page > table when hanging and when operating correctly. We do not fault or hang > when the option is turned off, which together with the improved early > fault handling in the patch, makes it almost certain that the problem is > in hardware configuration and not in our early setup. > > Of course, the most puzzling part is that memory test makes the hang > go away, while repeating memory test operation only on the msgbuf region > does not. msgbuf is special in that it is located at TOHM (top of high > memory). It spans 128KB from below it to the last byte of the last > physical segment. > > The only ideas I have right now is that there is either a bug in the > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > is nothing OS can do to mitigate it. Or it might be that the memory > map reported by CMS is wrong (you said that you use legacy boot, right > ?). This is not too surprising if true, because non-EFI boot code path > definitely get less and less testing. > > For the later case (potential bug in CMS), could you switch to EFI boot > mode and see whether the issue magically healths itself ? You could boot > from USB stick in EFI mode without reinstalling for test. I can't boot from USB stick -- this is remote DC and IPMI allow only CDROM emulation. OK, I am boot in UEFI 12.0 snapshot ISO. Boot ok. Can I convert installed OS to UEFI mode? > Do you use latest BIOS for your motherboard ? This is new MB (X10DRi) w/ BIOS 2.0, new is 2.1 but update is not simple (need to prepare bootable dos ISO, mostly utilites don't work under FreeBSD). From owner-freebsd-current@freebsd.org Wed Dec 14 11:03:16 2016 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 E8735C77C55 for ; Wed, 14 Dec 2016 11:03:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D83171F86; Wed, 14 Dec 2016 11:03:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D16502B7; Wed, 14 Dec 2016 11:03:16 +0000 (UTC) Date: Wed, 14 Dec 2016 11:03:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, bdrewery@FreeBSD.org, lifanov@FreeBSD.org, cem@FreeBSD.org, np@FreeBSD.org, dteske@FreeBSD.org, kib@FreeBSD.org, hrs@FreeBSD.org, sephe@FreeBSD.org, jkim@FreeBSD.org, andrew@FreeBSD.org, ganbold@FreeBSD.org, gjb@FreeBSD.org, glebius@FreeBSD.org, jhb@FreeBSD.org, brueffer@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1792565640.84.1481626976123.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1792565640.84.1481626976123.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1732 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Wed, 14 Dec 2016 12:14:34 +0000 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:03:17 -0000 FreeBSD_HEAD_amd64_gcc - Build #1732 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1= 732/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/173= 2/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1732= /console Change summaries: 310049 by np: cxgbe(4): Fix the tid range shown for T6 cards in misc.tids. MFC after:=093 days 310048 by sephe: hyperv: Implement "enlightened" time counter, which is rdtsc based. Reviewed by:=09kib MFC after:=091 week Sponsored by:=09Microsoft Differential Revision:=09https://reviews.freebsd.org/D8763 310047 by gjb: - Resize FreeBSD to the size of the OpenStack flavor (growfs). - Speeds up the boot process by disabling sendmail. - Allows an user to ssh as root with a public key. - Make ssh(1) respond faster by disabling DNS lookups. - Enable DHCP on the vtnet(4) interface. Note: The CLOUDWARE list has not yet been changed to include the OpenStack target by default yet. Submitted by:=09Diego Casati PR:=09=09215258 MFC after:=091 week Sponsored by:=09The FreeBSD Foundation 310046 by jhb: Add 'const' to fn_name's return type to remove a cast. 310045 by jhb: Use casts to force an unsigned comparison in db_search_symbol(). On all of our platforms, db_expr_t is a signed integer while db_addr_t is an unsigned integer value. db_search_symbol used variables of type db_expr_t to hold the current offset of the requested address from the "best" symbol found so far. This value was initialized to '~0'. When a new symbol is found from a symbol table, the associated diff for the new symbol is compared against the existing value as 'if (newdiff < diff)' to determine if the new symbol had a smaller diff and was thus a closer match. On 64-bit MIPS, the '~0' was treated as a negative value (-1). A lookup that found a perfect match of an address against a symbol returned a diff of 0. However, in signed comparisons, 0 is not less than -1. As a result, DDB on 64-bit MIPS never resolved any addresses to symbols. Workaround this by using casts to force an unsigned comparison. Probably the diff returned from db_search_symbol() and X_db_search_symbol() should be changed to a db_addr_t instead of a db_expr_t as it is an unsigned value (and is an offset of an address, so should fit in the same size as an address). Sponsored by:=09DARPA / AFRL 310038 by dteske: Revert r309918 -- modern POSIX has deprecated -<#>/+<#> syntax Special thanks to:=09jilles 310037 by jhb: Fix stack traces in DDB for the debugger thread. When the kernel debugger is entered, makectx() is called to store appropriate state from the trapframe for the debugger into a global kdb_pcb used as the thread context of the thread entering the debugger. Stack unwinders for DDB called via db_trace_thread() are supposed to then use this saved context so that the stack trace for the current thread starts at the location of the event that triggered debugger entry. MIPS was instead starting the stack trace of the current thread from the context of db_trace_thread itself and unwinding back out through the debugger to the original frame. Fix a couple of things to bring MIPS inline with other platforms: - Fix makectx() to store the PC, SP, and RA in the right portion of the PCB used by db_trace_thread(). - Fix db_trace_thread() to always use kdb_thr_ctx() (and thus kdb_pcb for the debugger thread). - Move the logic for tracing curthread from within the current function into db_trace_self() to match other architectures. Sponsored by:=09DARPA / AFRL 310036 by jkim: MFV:=09r309561 Merge byacc 20161202. 310035 by hrs: Remove an extra "break" which could incorrectly terminate an STAILQ_FOREACH() loop when an AF_INET6 rule matched. Spotted by:=09cem 310033 by np: cxgbe(4): Retire t4_bus_space_read_8 and t4_bus_space_write_8. MFC after:=093 days Sponsored by:=09Chelsio Communications 310032 by glebius: Zero return value when counter_rate() switches over to next second and value is positive, but below the limit. 310031 by cem: linuxkpi: Fix not-found case of linux_pci_find_irq_dev Linux list_for_each_entry() does not neccessarily end with the iterator NULL (it may be an offset from NULL if the list member is not the first element of the member struct). Reported by:=09Coverity CID:=09=091366940 Reviewed by:=09hselasky@ Sponsored by:=09Dell EMC Isilon Differential Revision:=09https://reviews.freebsd.org/D8780 310030 by jhb: Use register_t instead of uintptr_t for register values in backtraces. This fixes backtraces from DDB in n32 kernels as uintptr_t is only a uint32_t. In particular, the upper 32-bits of each register value were treated as the register's value breaking both the output of register values, but also the values of 'ra' and 'sp' required to walk up to the previous frame. Sponsored by:=09DARPA / AFRL 310029 by jhb: Fix remove_userlocal_code() for n32. n32 kernels use a 64-bit store to the TLS register rather than a 32-bit store. Sponsored by:=09DARPA / AFRL 310028 by jhb: Use db_lookup_proc() in the DDB 'show procvm' command. This allows processes to be identified by PID as well as a pointer address. MFC after:=092 weeks Sponsored by:=09DARPA / AFRL 310027 by kib: Fix bug in r309712, do not leak gem object pin count in case of error or retry. Reported and tested by:=09Michael Butler Sponsored by:=09The FreeBSD Foundation MFC after:=0916 days 310026 by brueffer: Language and mdoc cleanup. 310025 by bdrewery: Take write lock for rtld_bind before modifying obj_list in dl_iterate_phdr(= ). This avoids a race with readers such as dladdr(3)/dlinfo(3)/dlsym(3) and the atexit(3) handler. This race was introduced in r294373. Reviewed by:=09markj, kib, kan MFC after:=092 weeks Sponsored by:=09Dell EMC Isilon 310024 by lifanov: add myself as a ports committer and update mentor/mentee relationship Reviewed by:=09matthew Approved by:=09matthew (mentor) Differential Revision:=09https://reviews.freebsd.org/D8774 310023 by mav: Reduce diff from Illumos by better variables mapping. 310022 by andrew: Use the platform_*_t typedefs to help check the platform function types are correct. Sponsored by:=09ABT Systems Ltd 310021 by andrew: Add the missing void to function signatures in much of the arm code. Sponsored by:=09ABT Systems Ltd 310020 by andrew: Use platform_*_t to check the platform function signatures are correct in the Rockchip platform code and correct the one place they differ. Sponsored by:=09ABT Systems Ltd 310019 by ganbold: Switch Rockchip RK3188 SoC to use the platform code. Reviewed by:=09andrew, manu Differential Revision:=09https://reviews.freebsd.org/D8769 The end of the build log: [...truncated 93710 lines...] /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo:116:62: warning: dereferencing type-punned pointer wi= ll break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast(&__type_name);} ^ --- all_subdir_lib/libmagic --- --- funcs.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.funcs.o -MTfuncs.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -= Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-= error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-er= ror=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogi= cal-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized= -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-err= or=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_= amd64_gcc/lib/libmagic/../../contrib/file/src/funcs.c -o funcs.o --- is_tar.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.is_tar.o -MTis_tar.o -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign= -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wn= o-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-= error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlo= gical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitializ= ed -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-e= rror=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEA= D_amd64_gcc/lib/libmagic/../../contrib/file/src/is_tar.c -o is_tar.o --- magic.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.magic.o -MTmagic.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -= Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-= error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-er= ror=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogi= cal-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized= -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-err= or=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_= amd64_gcc/lib/libmagic/../../contrib/file/src/magic.c -o magic.o --- print.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.print.o -MTprint.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -= Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-= error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-er= ror=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogi= cal-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized= -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-err= or=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_= amd64_gcc/lib/libmagic/../../contrib/file/src/print.c -o print.o --- readcdf.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.readcdf.o -MTreadcdf.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -= Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wn= o-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3D= logical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitial= ized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno= -error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_H= EAD_amd64_gcc/lib/libmagic/../../contrib/file/src/readcdf.c -o readcdf.o --- all_subdir_lib/clang --- --- AArch64GenMCPseudoLowering.inc --- llvm-tblgen -gen-pseudo-lowering -I /builds/FreeBSD_HEAD_amd64_gcc/contrib= /llvm/include -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AAr= ch64 -d AArch64GenMCPseudoLowering.inc.d -o AArch64GenMCPseudoLowering.inc= /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64/AArch64.td --- all_subdir_lib/libmagic --- --- readelf.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.readelf.o -MTreadelf.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -= Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wn= o-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3D= logical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitial= ized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno= -error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_H= EAD_amd64_gcc/lib/libmagic/../../contrib/file/src/readelf.c -o readelf.o --- all_subdir_lib/libdevdctl --- --- exception.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeB= SD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/buil= ds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/= builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_= amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd= /bin/ -fpic -DPIC -g -O2 -pipe -MD -MF.depend.exception.pico -MTexception.p= ico -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno= -unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-error=3Daddress -= Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare = -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -W= no-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -= Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-= but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wn= o-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdc= tl/exception.cc -o exception.pico In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/memory:601:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/algorithm:634, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/string:442, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:15, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo: In member function 'size_t std::type_info::hash_code= () const': /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo:116:62: warning: dereferencing type-punned pointer wi= ll break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast(&__type_name);} ^ --- all_subdir_lib/libmagic --- --- softmagic.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DMAGIC=3D'"/usr/share/misc/mag= ic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/build= s/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic -I/= builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src -MD -M= F.depend.softmagic.o -MTsoftmagic.o -std=3Dgnu99 -fstack-protector-strong -= Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointe= r-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattribut= es -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered= -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-erro= r=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error=3Dunini= tialized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow -c /builds/FreeB= SD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/softmagic.c -o softma= gic.o --- all_subdir_lib/libgssapi --- =3D=3D=3D> lib/libgssapi (all) --- all_subdir_lib/libmagic --- --- apprentice.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -DMAGIC=3D'"/usr/= share/misc/magic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/lib= magic -I/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/li= b/libmagic -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file= /src -MD -MF.depend.apprentice.pico -MTapprentice.pico -std=3Dgnu99 -fst= ack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uni= nitialized -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds= -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-er= ror=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-alias= ing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-er= ror=3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflo= w -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src= /apprentice.c -o apprentice.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__mutex_base:16:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error: At global scope: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error:345:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/__mutex_base:289:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ostream:138:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/sstream:174, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/ios:392:1: warning: type attributes ignored after type is alre= ady defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/cstdio:99:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/excepti= on.cc:40: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2635:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2636:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2637:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2638:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ --- all_subdir_lib/clang --- --- AArch64GenRegisterInfo.inc --- llvm-tblgen -gen-register-info -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/l= lvm/include -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch= 64 -d AArch64GenRegisterInfo.inc.d -o AArch64GenRegisterInfo.inc /builds/= FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64/AArch64.td --- all_subdir_lib/libdevdctl --- --- guid.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeB= SD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/buil= ds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/= builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_= amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd= /bin/ -fpic -DPIC -g -O2 -pipe -MD -MF.depend.guid.pico -MTguid.pico -fstac= k-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-pa= rameter -Wpointer-arith -Wno-uninitialized -Wno-error=3Daddress -Wno-error= =3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-erro= r=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error= =3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-= variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-error= =3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid= .cc -o guid.pico --- all_subdir_lib/libmagic --- --- apptype.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -DMAGIC=3D'"/usr/= share/misc/magic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/lib= magic -I/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/li= b/libmagic -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file= /src -MD -MF.depend.apptype.pico -MTapptype.pico -std=3Dgnu99 -fstack-pr= otector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parame= ter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitial= ized -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-= error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-e= rror=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3D= inline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing -W= no-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-error=3D= unused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow = -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/appty= pe.c -o apptype.pico --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/memory:601:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/algorithm:634, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/string:442, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:15, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo: In member function 'size_t std::type_info::hash_code= () const': /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/typeinfo:116:62: warning: dereferencing type-punned pointer wi= ll break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast(&__type_name);} ^ --- all_subdir_lib/librpcsec_gss --- =3D=3D=3D> lib/librpcsec_gss (all) --- .depend --- echo librpcsec_gss.so.1.full: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/Fre= eBSD_HEAD_amd64_gcc/tmp/usr/lib/libgssapi.a >> .depend --- rpcsec_gss.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/librpcsec_gss/../../include -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libr= pcsec_gss/../../libc_rpc -MD -MF.depend.rpcsec_gss.o -MTrpcsec_gss.o -st= d=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -= W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-= arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-= parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredund= ant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Daddress -Wn= o-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-compare -W= no-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno= -error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses -Wn= o-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Dunused-bu= t-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-value -Wno-= error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/librpcsec= _gss/rpcsec_gss.c -o rpcsec_gss.o --- rpcsec_gss_prot.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/librpcsec_gss/../../include -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libr= pcsec_gss/../../libc_rpc -MD -MF.depend.rpcsec_gss_prot.o -MTrpcsec_gss_= prot.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow= -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-extern= s -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Da= ddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-= compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-co= mpare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-paren= theses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error= =3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused= -value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/l= ib/librpcsec_gss/rpcsec_gss_prot.c -o rpcsec_gss_prot.o --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__mutex_base:16:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error: At global scope: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/system_error:345:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/mutex:189:0, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/__locale:18, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/ios:216, from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/__mutex_base:289:1: warning: type attributes ignored after typ= e is already defined [-Wattributes] }; ^ --- all_subdir_lib/libmagic --- --- ascmagic.pico --- --- all_subdir_lib/librpcsec_gss --- --- rpcsec_gss_conf.o --- --- all_subdir_lib/libmagic --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -DMAGIC=3D'"/usr/= share/misc/magic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/lib= magic -I/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/li= b/libmagic -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file= /src -MD -MF.depend.ascmagic.pico -MTascmagic.pico -std=3Dgnu99 -fstack-= protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uniniti= alized -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wn= o-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno= -error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error= =3Dinline -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing= -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-error= =3Dunused-function -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow = -c /builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/as= cmagic.c -o ascmagic.pico --- all_subdir_lib/librpcsec_gss --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/librpcsec_gss/../../include -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libr= pcsec_gss/../../libc_rpc -MD -MF.depend.rpcsec_gss_conf.o -MTrpcsec_gss_= conf.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow= -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-extern= s -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Da= ddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-= compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-co= mpare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-paren= theses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error= =3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused= -value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/l= ib/librpcsec_gss/rpcsec_gss_conf.c -o rpcsec_gss_conf.o --- all_subdir_lib/libdevdctl --- In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/iostream:38:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :46: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/ios:392:1: warning: type attributes ignored after type is alre= ady defined [-Wattributes] }; ^ In file included from /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEA= D_amd64_gcc/tmp/usr/include/c++/v1/stdlib.h:88:0, from /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl/guid.cc= :42: /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2635:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2636:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2637:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/in= clude/c++/v1/locale:2638:1: warning: type attributes ignored after type is = already defined [-Wattributes] _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_TYPE_VIS moneypunct_byname) ^ --- all_subdir_lib/clang --- --- AArch64GenSubtargetInfo.inc --- llvm-tblgen -gen-subtarget -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/= include -I /builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64 = -d AArch64GenSubtargetInfo.inc.d -o AArch64GenSubtargetInfo.inc /builds/Fr= eeBSD_HEAD_amd64_gcc/contrib/llvm/lib/Target/AArch64/AArch64.td --- all_subdir_lib/libmagic --- --- cdf.pico --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -g -O2 -pipe -DMAGIC=3D'"/usr/= share/misc/magic"' -DHAVE_CONFIG_H -I/builds/FreeBSD_HEAD_amd64_gcc/lib/lib= magic -I/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/li= b/libmagic -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file= /src -MD -MF.depend.cdf.pico -MTcdf.pico -std=3Dgnu99 -fstack-protector-= strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wn= o-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3D= attributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dc= lobbered -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline -= Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing -Wno-error= =3Duninitialized -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-f= unction -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow -c /buil= ds/FreeBSD_HEAD_amd64_gcc/lib/libmagic/../../contrib/file/src/cdf.c -o cdf.= pico --- all_subdir_lib/librpcsec_gss --- --- rpcsec_gss_misc.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/librpcsec_gss/../../include -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libr= pcsec_gss/../../libc_rpc -MD -MF.depend.rpcsec_gss_misc.o -MTrpcsec_gss_= misc.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow= -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-extern= s -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Da= ddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-= compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-co= mpare -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-paren= theses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error= =3Dunused-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused= -value -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/l= ib/librpcsec_gss/rpcsec_gss_misc.c -o rpcsec_gss_misc.o --- svc_rpcsec_gss.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/= FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysr= oot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp = -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gc= c/lib/librpcsec_gss/../../include -I/builds/FreeBSD_HEAD_amd64_gcc/lib/libr= pcsec_gss/../../libc_rpc -MD -MF.depend.svc_rpcsec_gss.o -MTsvc_rpcsec_g= ss.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-form= at-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -W= pointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -= Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=3Dadd= ress -Wno-error=3Darray-bounds -Wno-error=3Dattributes -Wno-error=3Dbool-co= mpare -Wno-error=3Dcast-align -Wno-error=3Dclobbered -Wno-error=3Denum-comp= are -Wno-error=3Dextra -Wno-error=3Dinline -Wno-error=3Dlogical-not-parenth= eses -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized -Wno-error=3Du= nused-but-set-variable -Wno-error=3Dunused-function -Wno-error=3Dunused-val= ue -Wno-error=3Dstrict-overflow -c /builds/FreeBSD_HEAD_amd64_gcc/lib/l= ibrpcsec_gss/svc_rpcsec_gss.c -o svc_rpcsec_gss.o --- all_subdir_lib/libdevdctl --- --- libprivatedevdctl.a --- building static devdctl library /usr/local/x86_64-freebsd/bin/ar -crD libprivatedevdctl.a `NM=3D'/usr/local= /x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder consumer.o event.o event_facto= ry.o exception.o guid.o | tsort -q`=20 /usr/local/x86_64-freebsd/bin/ranlib -D libprivatedevdctl.a --- libprivatedevdctl.so.0.full --- building shared library libprivatedevdctl.so.0 /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -std=3D= c++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBS= D_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/build= s/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/obj/b= uilds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_a= md64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd/= bin/ -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--wa= rn-shared-textrel -o libprivatedevdctl.so.0.full -Wl,-soname,libprivatedev= dctl.so.0 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder con= sumer.pico event.pico event_factory.pico exception.pico guid.pico | tsort = -q`=20 /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status *** [libprivatedevdctl.so.0.full] Error code 1 bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl 1 error bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libdevdctl *** [all_subdir_lib/libdevdctl] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib --- all_subdir_lib/librpcsec_gss --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/librpcsec_gss *** [all_subdir_lib/librpcsec_gss] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib --- all_subdir_lib/libmagic --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libmagic *** [all_subdir_lib/libmagic] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib --- all_subdir_lib/clang --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang/libllvm *** [all_subdir_lib/clang/libllvm] Error code 2 bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang 1 error bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/clang *** [all_subdir_lib/clang] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib 4 errors bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib *** [lib__L] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [libraries] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [_libraries] Error code 2 bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [buildworld] Error code 2 make: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error make: stopped in /builds/FreeBSD_HEAD_amd64_gcc Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Wed Dec 14 14:22:17 2016 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 79E34C77494; Wed, 14 Dec 2016 14:22:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB7CDE0; Wed, 14 Dec 2016 14:22:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 75D8E2BB; Wed, 14 Dec 2016 14:22:17 +0000 (UTC) Date: Wed, 14 Dec 2016 14:22:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: ed@FreeBSD.org, kib@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1507178583.88.1481725337491.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #4383 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:22:17 -0000 FreeBSD_HEAD_i386 - Build #4383 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4383/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4383/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4383/console Change summaries: 310056 by ed: Let all FEATURE()s use the same Prometheus metric. Without this change, every individual FEATURE() declaration would have an individual metric in Prometheus. Though this wouldn't be harmful, it would look very cluttered. By letting it use a single metric with the name of the feature attached as a label, it also becomes easier to search, as you can apply regex matching, etc. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310055 by ed: Add a "device_index" label to all sysctls under dev.$driver.$index. This way it becomes possible to graph a property for all instances of a single driver. For example, graphing the number of packets across all USB controllers, the amount of dropped packets on all NICs, etc. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310054 by ed: Attach a "thermal_zone" label to the ACPI thermal zone sysctls. In order to make Prometheus do graphing/alerting on thermal sensors in a generic fashion, we should attach the name of the thermal zone device as a label. That way there is only a single metric for the temperature of a thermal zone, with its name attached as a label. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310053 by ed: Add labels to sysctls related to clocks. Sysctls like kern.eventtimer.et.*.quality currently embed the name of the clock device. This is problematic for the Prometheus metrics exporter for two reasons: - Some of those clocks have dashes in their names, which Prometheus doesn't allow to be used in metric names. - It doesn't allow for extracting the same property of all clocks on the system from within a single query. Attach these nodes to have a label, so that the Prometheus metrics exporter gives these metric a uniform name with the name of the clock attached as a label. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310052 by ed: Add label annotations to CAM sysctls. Under kern.cam we have certain sysctls that are per-device, such as the ones under kern.cam.ada.[0-9]+.*. Add a "device_index" label annotation to such sysctls, so that the Prometheus metrics exporter will give all of those metrics the same name. The device number will be added to the metric name as the "device_index" label. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310051 by ed: Add support for attaching aggregation labels to sysctl objects. I'm currently working on writing a metrics exporter for the Prometheus monitoring system to provide access to sysctl metrics. Prometheus and sysctl have some structural differences: - sysctl is a tree of string component names. - Prometheus uses a flat namespace for its metrics, but allows you to attach labels with values to them, so that you can do aggregation. An initial version of my exporter simply translated hw.acpi.thermal.tz1.temperature to sysctl_hw_acpi_thermal_tz1_temperature_celcius while we should ideally have sysctl_hw_acpi_thermal_temperature_celcius{thermal_zone="tz1"} allowing you to graph all thermal zones on a system in one go. The change presented in this commit adds support for accomplishing this, by providing the ability to attach labels to nodes. In the example I gave above, the label "thermal_zone" would be attached to "tz1". As this is a feature that will only be used very rarely, I decided to not change the KPI too aggressively. Discussed on: hackers@ Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D8775 310050 by kib: Provide non-final but valid PCB pointer for thread0 for duration of hammer_time(). This makes assembler exception handlers not fault itself when setting PCB flags, and allow normal kernel trap handler to get control. The pointer is reset after FPU parameters are obtained. Set thread0.td_critnest to 1 for duration of hammer_time() as well. In particular, page faults at that early stage panic immediately instead of trying to call not yet operational VM to resolve it. As result, faults during second half of the hammer_time() execution have a chance to be reported instead of silent machine reboot or hang. Sponsored by: The FreeBSD Foundation MFC after: 2 weeks The end of the build log: [...truncated 149114 lines...] --- all_subdir_apm --- ctfconvert -L VERSION -g apm.o --- apm.kld --- ld -d -warn-common -r -d -o apm.kld apm.o ctfmerge -L VERSION -g -o apm.kld apm.o echo apm_display apm_softc > export_syms awk -f /usr/src/sys/conf/kmod_syms.awk apm.kld export_syms | xargs -J% objcopy % apm.kld --- all_subdir_arcmsr --- --- machine --- machine -> /usr/src/sys/i386/include --- all_subdir_apm --- --- apm.ko.full --- ld -Bshareable -d -warn-common -o apm.ko.full apm.kld --- all_subdir_arcmsr --- --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_scsi.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h --- all_subdir_apm --- --- apm.ko.debug --- objcopy --only-keep-debug apm.ko.full apm.ko.debug --- all_subdir_arcmsr --- --- opt_cam.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- all_subdir_apm --- --- apm.ko --- --- all_subdir_arcmsr --- --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- all_subdir_apm --- objcopy --strip-debug --add-gnu-debuglink=apm.ko.debug apm.ko.full apm.ko --- all_subdir_arcmsr --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- all_subdir_arcnet --- ===> arcnet (all) --- all_subdir_arcmsr --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- all_subdir_arcnet --- --- machine --- machine -> /usr/src/sys/i386/include --- all_subdir_arcmsr --- --- arcmsr.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.arcmsr.o -MTarcmsr.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/arcmsr/../../dev/arcmsr/arcmsr.c -o arcmsr.o --- all_subdir_arcnet --- --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_inet.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet.h opt_inet.h --- opt_inet6.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet6.h opt_inet6.h --- opt_ofed.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ofed.h opt_ofed.h --- if_arcsubr.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.if_arcsubr.o -MTif_arcsubr.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/arcnet/../../net/if_arcsubr.c -o if_arcsubr.o --- all_subdir_amr --- ctfconvert -L VERSION -g amr.o --- amr.kld --- ld -d -warn-common -r -d -o amr.kld amr.o amr_pci.o amr_disk.o ctfmerge -L VERSION -g -o amr.kld amr.o amr_pci.o amr_disk.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk amr.kld export_syms | xargs -J% objcopy % amr.kld --- amr.ko.full --- ld -Bshareable -d -warn-common -o amr.ko.full amr.kld --- amr.ko.debug --- objcopy --only-keep-debug amr.ko.full amr.ko.debug --- amr.ko --- objcopy --strip-debug --add-gnu-debuglink=amr.ko.debug amr.ko.full amr.ko --- all_subdir_asmc --- ===> asmc (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_acpi.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_acpi.h opt_acpi.h --- opt_intr_filter.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_intr_filter.h opt_intr_filter.h --- acpi_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/acpica/acpi_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- asmc.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.asmc.o -MTasmc.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/asmc/../../dev/asmc/asmc.c -o asmc.o --- all_subdir_arcnet --- ctfconvert -L VERSION -g if_arcsubr.o --- arcnet.kld --- ld -d -warn-common -r -d -o arcnet.kld if_arcsubr.o ctfmerge -L VERSION -g -o arcnet.kld if_arcsubr.o echo arc_frag_init arc_frag_next arc_ifattach arc_ifdetach arc_input arc_ioctl arc_isphds arc_output arc_storelladdr > export_syms awk -f /usr/src/sys/conf/kmod_syms.awk arcnet.kld export_syms | xargs -J% objcopy % arcnet.kld --- arcnet.ko.full --- ld -Bshareable -d -warn-common -o arcnet.ko.full arcnet.kld --- arcnet.ko.debug --- objcopy --only-keep-debug arcnet.ko.full arcnet.ko.debug --- arcnet.ko --- objcopy --strip-debug --add-gnu-debuglink=arcnet.ko.debug arcnet.ko.full arcnet.ko --- all_subdir_ata --- ===> ata (all) --- all_subdir_ata/atacore --- ===> ata/atacore (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- ata_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -h --- opt_cam.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- ata_if.c --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -c --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ata_if.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.ata_if.o -MTata_if.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c ata_if.c -o ata_if.o ctfconvert -L VERSION -g ata_if.o --- ata-lowlevel.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.ata-lowlevel.o -MTata-lowlevel.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ata/atacore/../../../dev/ata/ata-lowlevel.c -o ata-lowlevel.o --- all_subdir_asmc --- ctfconvert -L VERSION -g asmc.o --- asmc.kld --- ld -d -warn-common -r -d -o asmc.kld asmc.o ctfmerge -L VERSION -g -o asmc.kld asmc.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk asmc.kld export_syms | xargs -J% objcopy % asmc.kld --- asmc.ko.full --- ld -Bshareable -d -warn-common -o asmc.ko.full asmc.kld --- asmc.ko.debug --- objcopy --only-keep-debug asmc.ko.full asmc.ko.debug --- asmc.ko --- objcopy --strip-debug --add-gnu-debuglink=asmc.ko.debug asmc.ko.full asmc.ko --- all_subdir_ata --- --- ata-all.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -MD -MF.depend.ata-all.o -MTata-all.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c -o ata-all.o --- all_subdir_an --- ctfconvert -L VERSION -g if_an.o --- if_an.kld --- ld -d -warn-common -r -d -o if_an.kld if_an.o if_an_pccard.o if_an_pci.o if_an_isa.o ctfmerge -L VERSION -g -o if_an.kld if_an.o if_an_pccard.o if_an_pci.o if_an_isa.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_an.kld export_syms | xargs -J% objcopy % if_an.kld --- if_an.ko.full --- ld -Bshareable -d -warn-common -o if_an.ko.full if_an.kld --- if_an.ko.debug --- objcopy --only-keep-debug if_an.ko.full if_an.ko.debug --- if_an.ko --- objcopy --strip-debug --add-gnu-debuglink=if_an.ko.debug if_an.ko.full if_an.ko --- all_subdir_ata --- --- all_subdir_ata/atacard --- ===> ata/atacard (all) --- all_subdir_ata/atacore --- /usr/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:83:70: error: too few arguments provided to function-like macro invocation FEATURE(ata_cam, "ATA devices are accessed through the cam(4) driver"); ^ /usr/src/sys/sys/sysctl.h:799:9: note: macro 'FEATURE' defined here #define FEATURE(name, desc, label) \ ^ /usr/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:83:1: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] FEATURE(ata_cam, "ATA devices are accessed through the cam(4) driver"); ^ --- all_subdir_ata/atacard --- --- machine --- machine -> /usr/src/sys/i386/include --- all_subdir_ata/atacore --- 2 errors generated. --- all_subdir_ata/atacard --- --- x86 --- x86 -> /usr/src/sys/x86/include --- all_subdir_ata/atacore --- *** [ata-all.o] Error code 1 bmake[5]: stopped in /usr/src/sys/modules/ata/atacore --- all_subdir_ata/atacard --- --- ata_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -h A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/sys/modules/ata/atacard *** [all_subdir_ata/atacard] Error code 2 bmake[4]: stopped in /usr/src/sys/modules/ata --- all_subdir_ata/atacore --- --- ata-lowlevel.o --- ctfconvert -L VERSION -g ata-lowlevel.o 1 error bmake[5]: stopped in /usr/src/sys/modules/ata/atacore *** [all_subdir_ata/atacore] Error code 2 bmake[4]: stopped in /usr/src/sys/modules/ata 2 errors bmake[4]: stopped in /usr/src/sys/modules/ata *** [all_subdir_ata] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_arcmsr --- ctfconvert -L VERSION -g arcmsr.o A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/sys/modules/arcmsr *** [all_subdir_arcmsr] Error code 2 bmake[3]: stopped in /usr/src/sys/modules 2 errors bmake[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson8706097995635178971.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Wed Dec 14 14:40:42 2016 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 88543C77BCF for ; Wed, 14 Dec 2016 14:40:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 302711A02 for ; Wed, 14 Dec 2016 14:40:42 +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 uBEEeXb0048234 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 16:40:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBEEeXb0048234 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBEEeXp5048233; Wed, 14 Dec 2016 16:40:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 16:40:33 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214144033.GH94325@kib.kiev.ua> References: <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214121336.GD98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 14:40:42 -0000 On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > In other words, it is almost certainly the hang and not a fault causing > > hang. This means that the machine is not compliant with the IA32 > > architecture, in particular, the region reported as normal memory by > > E820 BIOS service does not behave as normal memory. > > > > Since regardless of the option setting, the memory map is same, and > > bootstrap page table only depend on the memory map, we use the same page > > table when hanging and when operating correctly. We do not fault or hang > > when the option is turned off, which together with the improved early > > fault handling in the patch, makes it almost certain that the problem is > > in hardware configuration and not in our early setup. > > > > Of course, the most puzzling part is that memory test makes the hang > > go away, while repeating memory test operation only on the msgbuf region > > does not. msgbuf is special in that it is located at TOHM (top of high > > memory). It spans 128KB from below it to the last byte of the last > > physical segment. > > > > The only ideas I have right now is that there is either a bug in the > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > is nothing OS can do to mitigate it. Or it might be that the memory > > map reported by CMS is wrong (you said that you use legacy boot, right > > ?). This is not too surprising if true, because non-EFI boot code path > > definitely get less and less testing. > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > mode and see whether the issue magically healths itself ? You could boot > > from USB stick in EFI mode without reinstalling for test. > > I can't boot from USB stick -- this is remote DC and IPMI allow only > CDROM emulation. > > OK, I am boot in UEFI 12.0 snapshot ISO. > Boot ok. > > Can I convert installed OS to UEFI mode? I am not sure what do you ask there. Are you asking whether I need any further information from the broken setup ? I believe that no, I cannot debug this any further. I think that the interesting piece of data that can be obtained now is the memmap command output from the EFI loader from all three configurations, NUMA on/off and interleaving. > > > Do you use latest BIOS for your motherboard ? > > This is new MB (X10DRi) w/ BIOS 2.0, new is 2.1 but update is not > simple (need to prepare bootable dos ISO, mostly utilites don't work > under FreeBSD). IMO the only way to fix this issue, if it is really important, is to contact supermicro and show them the bug. But this only makes sense if repeated on the latest firmware version. From owner-freebsd-current@freebsd.org Wed Dec 14 14:47:08 2016 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 47416C77D62 for ; Wed, 14 Dec 2016 14:47:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 0882F1F88 for ; Wed, 14 Dec 2016 14:47:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHApl-000Hpi-1d; Wed, 14 Dec 2016 17:47:05 +0300 Date: Wed, 14 Dec 2016 17:47:05 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214144704.GE98176@zxy.spb.ru> References: <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214144033.GH94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214144033.GH94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 14:47:08 -0000 On Wed, Dec 14, 2016 at 04:40:33PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > In other words, it is almost certainly the hang and not a fault causing > > > hang. This means that the machine is not compliant with the IA32 > > > architecture, in particular, the region reported as normal memory by > > > E820 BIOS service does not behave as normal memory. > > > > > > Since regardless of the option setting, the memory map is same, and > > > bootstrap page table only depend on the memory map, we use the same page > > > table when hanging and when operating correctly. We do not fault or hang > > > when the option is turned off, which together with the improved early > > > fault handling in the patch, makes it almost certain that the problem is > > > in hardware configuration and not in our early setup. > > > > > > Of course, the most puzzling part is that memory test makes the hang > > > go away, while repeating memory test operation only on the msgbuf region > > > does not. msgbuf is special in that it is located at TOHM (top of high > > > memory). It spans 128KB from below it to the last byte of the last > > > physical segment. > > > > > > The only ideas I have right now is that there is either a bug in the > > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > > is nothing OS can do to mitigate it. Or it might be that the memory > > > map reported by CMS is wrong (you said that you use legacy boot, right > > > ?). This is not too surprising if true, because non-EFI boot code path > > > definitely get less and less testing. > > > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > > mode and see whether the issue magically healths itself ? You could boot > > > from USB stick in EFI mode without reinstalling for test. > > > > I can't boot from USB stick -- this is remote DC and IPMI allow only > > CDROM emulation. > > > > OK, I am boot in UEFI 12.0 snapshot ISO. > > Boot ok. > > > > Can I convert installed OS to UEFI mode? > I am not sure what do you ask there. Are you asking whether I need any > further information from the broken setup ? I believe that no, I cannot > debug this any further. I am don't touch UEFI before. I am try to know how to switch for existing installtion from legacy boot to UEFI boot (for use less broken setup). [may be NUMA+interleaving don't give me any good, but I am need test for sure] > I think that the interesting piece of data that can be obtained now is > the memmap command output from the EFI loader from all three configurations, > NUMA on/off and interleaving. What you mean 'EFI loader'? FreeBSD loader for UEFI mode? Or UEFI shell from BIOS? > > > > > Do you use latest BIOS for your motherboard ? > > > > This is new MB (X10DRi) w/ BIOS 2.0, new is 2.1 but update is not > > simple (need to prepare bootable dos ISO, mostly utilites don't work > > under FreeBSD). > IMO the only way to fix this issue, if it is really important, is > to contact supermicro and show them the bug. But this only makes sense if > repeated on the latest firmware version. From owner-freebsd-current@freebsd.org Wed Dec 14 15:26:31 2016 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 03513C8080E for ; Wed, 14 Dec 2016 15:26:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 AED171827 for ; Wed, 14 Dec 2016 15:26:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHBRr-000IrT-A5; Wed, 14 Dec 2016 18:26:27 +0300 Date: Wed, 14 Dec 2016 18:26:27 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214152627.GF98176@zxy.spb.ru> References: <20161213143401.GK90287@zxy.spb.ru> <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214121336.GD98176@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 15:26:31 -0000 On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > In other words, it is almost certainly the hang and not a fault causing > > hang. This means that the machine is not compliant with the IA32 > > architecture, in particular, the region reported as normal memory by > > E820 BIOS service does not behave as normal memory. > > > > Since regardless of the option setting, the memory map is same, and > > bootstrap page table only depend on the memory map, we use the same page > > table when hanging and when operating correctly. We do not fault or hang > > when the option is turned off, which together with the improved early > > fault handling in the patch, makes it almost certain that the problem is > > in hardware configuration and not in our early setup. > > > > Of course, the most puzzling part is that memory test makes the hang > > go away, while repeating memory test operation only on the msgbuf region > > does not. msgbuf is special in that it is located at TOHM (top of high > > memory). It spans 128KB from below it to the last byte of the last > > physical segment. > > > > The only ideas I have right now is that there is either a bug in the > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > is nothing OS can do to mitigate it. Or it might be that the memory > > map reported by CMS is wrong (you said that you use legacy boot, right > > ?). This is not too surprising if true, because non-EFI boot code path > > definitely get less and less testing. > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > mode and see whether the issue magically healths itself ? You could boot > > from USB stick in EFI mode without reinstalling for test. > > I can't boot from USB stick -- this is remote DC and IPMI allow only > CDROM emulation. > > OK, I am boot in UEFI 12.0 snapshot ISO. > Boot ok. Sorry. Overload bu work and test wrong combination (NUMA=ON, interleave=OFF) snapshot iso don't boot with NUMA=ON interleave=ON For test hardware setup (NUMA+interleave), what ISO I can try to boot? PS: memmaps: NUMA=ON interleave=OFF OK memmap Type Physical Virtual #Pages Attr BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB Reserved 00007916b000 000000000000 00000817 UC WC WT WB ConventionalMemory 000079982000 000000000000 0000011f UC WC WT WB ACPIMemoryNVS 000079aa1000 000000000000 00000509 UC WC WT WB RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB Reserved 00007c000000 000000000000 00004000 MemoryMappedIO 000080000000 000000000000 00010000 UC MemoryMappedIO 0000fed1c000 000000000000 00000029 UC MemoryMappedIO 0000ff000000 000000000000 00001000 UC NUMA=ON interleave=ON Type Physical Virtual #Pages Attr BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB Reserved 00007916b000 000000000000 00000817 UC WC WT WB ConventionalMemory 000079982000 000000000000 0000011f UC WC WT WB ACPIMemoryNVS 000079aa1000 000000000000 00000509 UC WC WT WB RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB Reserved 00007c000000 000000000000 00004000 MemoryMappedIO 000080000000 000000000000 00010000 UC MemoryMappedIO 0000fed1c000 000000000000 00000029 UC MemoryMappedIO 0000ff000000 000000000000 00001000 UC NUMA=OFF interleave=ON Type Physical Virtual #Pages Attr BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB Reserved 00007916b000 000000000000 00000817 UC WC WT WB ConventionalMemory 000079982000 000000000000 00000123 UC WC WT WB ACPIMemoryNVS 000079aa5000 000000000000 00000505 UC WC WT WB RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB Reserved 00007c000000 000000000000 00004000 MemoryMappedIO 000080000000 000000000000 00010000 UC MemoryMappedIO 0000fed1c000 000000000000 00000029 UC MemoryMappedIO 0000ff000000 000000000000 00001000 UC From owner-freebsd-current@freebsd.org Wed Dec 14 16:32:41 2016 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 4CD51C805D7; Wed, 14 Dec 2016 16:32:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE4919AF; Wed, 14 Dec 2016 16:32:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A97652BF; Wed, 14 Dec 2016 16:32:41 +0000 (UTC) Date: Wed, 14 Dec 2016 16:32:39 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hselasky@FreeBSD.org, manu@FreeBSD.org, ed@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1689406542.90.1481733161728.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1507178583.88.1481725337491.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1507178583.88.1481725337491.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #4384 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:32:41 -0000 FreeBSD_HEAD_i386 - Build #4384 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4384/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4384/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4384/console Change summaries: 310061 by manu: Add new compatible string "allwinner,sun7i-a20-mmc". New upstream DTS is using this now for A20 SoC. MFC after: 3 days 310058 by hselasky: Fix initialisation of mlx4_pci_table's .driver_data fields. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D8791 Sponsored by: Mellanox Technologies Submitted by: Dexuan Cui 310057 by ed: Revert accidental change made in r310056. Because I had to cherry-pick some of my changes in r310051, I accidentally made a typo when manually applying the rest in r310056. From owner-freebsd-current@freebsd.org Wed Dec 14 16:52:48 2016 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 52A74C80EE4; Wed, 14 Dec 2016 16:52:48 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0B7B12ED; Wed, 14 Dec 2016 16:52:47 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:25:3ab8:f974:3d2c:f3c1:4d79] ([IPv6:2a02:2698:25:3ab8:f974:3d2c:f3c1:4d79]) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id uBEGqgTj009311 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Dec 2016 21:52:42 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1481734363; bh=cml99fktx70YHnro/pCyBFzELIlNv5MqJmtaQ1+UX5E=; h=Subject:To:References:From:Cc:Date:In-Reply-To; b=jO//swshNQeQ/YxbTeeiotghEUIISGlP7Cg7hr1k4NQPOm88HwBBgupt1URdAtVFM qixUMszRKlNk23mxCgP9cSAV+n9bWdMTsOi4hT1mUL3itniYyimQFlarQdx0a1GY6V D6vXKNXFNIHUZTwyzeJgN6+nJSBCwPehdr2DRmH8= Subject: Re: [RFC/RFT] projects/ipsec To: freebsd-current@freebsd.org References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> From: "Eugene M. Zheganin" Cc: freebsd-net Message-ID: <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> Date: Wed, 14 Dec 2016 21:52:43 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed 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: Wed, 14 Dec 2016 16:52:48 -0000 Hi, On 11.12.2016 4:07, Andrey V. Elsukov wrote: > Hi All, > > I am pleased to announce that projects/ipsec, that I started several > months ago is ready for testing and review. > The main goals were: > * rework locking to make IPsec code more friendly for concurrent > processing; > * make lookup in SADB/SPDB faster; > * revise PFKEY implementation, remove stale code, make it closer > to RFC; > * implement IPsec VTI (virtual tunneling interface); > * make IPsec code loadable as kernel module. > > Currently all, except the last one is mostly done. So, I decided ask for > a help to test the what already done, while I will work on the last task. > Well, at last FreeBSD got one of the most anticipated features in it's ipsec stack. When I wrote the message in the freebsd-net ML in the middle of 2012 (https://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html) I had a very little hope that someone will actually implement this, and now I'm very grateful that Andrey got the time to do this (and I'm really sorry for being such a pain in the ass, I'm saying so because I was bothering Andrey all this time in IRC). This isn't definitely a feature that every FreeBSD enthusiast will use, and, sadly, even not the feature that every network engineer that use ipsec in it's every day work will configure (many people still use obsoleted legacy interfaceless ipsec approach, not to mention weird and hybrid software routers like openvpn), but it's definitely a feature that will be appreciated by every skilled L3 VPN engineer that is using FreeBSD in it's operating stack. I've ran some tests in my production network and I should say that even on it's initial release state if_ipsec is fully operational with Juniper st tunnel on the other side, so I'm already running one FreeBSD <--> Juniper tunnel at my work: # ifconfig ipsec0 ipsec0: flags=8051 metric 0 mtu 1400 tunnel inet 128.127.144.19 --> 128.127.146.1 inet 172.16.3.104 --> 172.16.3.105 netmask 0xffffffff inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9 nd6 options=21 reqid: 16385 groups: ipsec racoon.conf: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp 128.127.144.19 [500]; strict_address; # requires that all addresses must be bound. } timer { counter 5; interval 20 sec; persend 1; phase1 30 sec; phase2 15 sec; } # # SPb, Test # remote 128.127.146.1 { exchange_mode main; lifetime time 1 hour; my_identifier address 128.127.144.19; peers_identifier address 128.127.146.1; passive off; proposal_check obey; dpd_delay 20; proposal { encryption_algorithm des; hash_algorithm md5; authentication_method pre_shared_key; dh_group modp768; } } # # SPb, Test # sainfo address 0.0.0.0/0 [500] any address 0.0.0.0/0 [500] any { pfs_group modp768; lifetime time 60 min; encryption_algorithm des; authentication_algorithm non_auth; compression_algorithm deflate; } Juniper side: > show configuration interfaces st0.147 description "Perm, FreeBSD Test Server"; family inet { mtu 1455; address 172.16.3.105/32 { destination 172.16.3.104; } } > show configuration security ike policy kosm65 proposals norma-ike; pre-shared-key ascii-text "$9$-SV4ZUDkqPQUjBIclLXgoJUqf9CuESeAp-w2gGUjHqfQn"; ## SECRET-DATA > show configuration security ike gateway kosm65-freebsd-test ike-policy perm-freebsd-test; address 128.127.144.19; local-identity inet 128.127.146.1; remote-identity inet 128.127.144.19; external-interface reth1.2; > show configuration security ipsec vpn kosm65-freebsd-test bind-interface st0.147; ike { gateway kosm65-freebsd-test; ipsec-policy norma-policy; } > show configuration security ipsec policy norma-policy perfect-forward-secrecy { keys group1; } proposals norma-ipsec; > show configuration security ipsec proposal norma-ipsec protocol esp; encryption-algorithm des-cbc; lifetime-seconds 600; > show configuration security ike proposal norma-ike authentication-method pre-shared-keys; dh-group group1; authentication-algorithm md5; encryption-algorithm des-cbc; In it's initial state if_ipsec allows to use only one set of encryption parameters (because only one sainfo anonyumous is possible), so at this time it doesn't allow to create multiple tunnels with VPN hubs that use different cipers and/or transform sets, but as far as I understand this is subject to change and Andrey is already working on a support of this feature from ipsec-tools IKE daemon. But even in this state this feature is already useful and I'm excited to see it commited to HEAD and then MFC'd to 11.x, to start using it in my production network (as you may know, buiding gre/ipsec tunnels on Juniper is very hackish and tricky, bit I still have more than dozen of them). I've already saw a discussion on FreeBSD web forums, and people there are excited about if_ipsec too. Furthermore, I believe that guys using pfSense will be very happy about if_ipsec in their routers, because I saw several discussions mentioning missing VTI support there. It's very easy to configure, because it uses ifconfig syntax and it creates all the needed policies in the SADB automatically, so one less thing to bother with. And when I say "fully opertational with Juniper" I mean it: no tricky or hackish configuration directives are required oin the Juniper side, everything is like it's a Juniper or Cisco on the other side. So I'm pretty sure this will work with Cisco too (didn't run any test with Cisco though). Once again, I thank Andrey for this. Eugene. From owner-freebsd-current@freebsd.org Wed Dec 14 19:03:56 2016 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 2AF26C8056A for ; Wed, 14 Dec 2016 19:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD9327C for ; Wed, 14 Dec 2016 19:03:55 +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 uBEJ3nbj013459 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 21:03:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBEJ3nbj013459 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBEJ3ng7013458; Wed, 14 Dec 2016 21:03:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 21:03:49 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214190349.GJ94325@kib.kiev.ua> References: <20161213150139.GZ54029@kib.kiev.ua> <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214152627.GF98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 19:03:56 -0000 On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > In other words, it is almost certainly the hang and not a fault causing > > > hang. This means that the machine is not compliant with the IA32 > > > architecture, in particular, the region reported as normal memory by > > > E820 BIOS service does not behave as normal memory. > > > > > > Since regardless of the option setting, the memory map is same, and > > > bootstrap page table only depend on the memory map, we use the same page > > > table when hanging and when operating correctly. We do not fault or hang > > > when the option is turned off, which together with the improved early > > > fault handling in the patch, makes it almost certain that the problem is > > > in hardware configuration and not in our early setup. > > > > > > Of course, the most puzzling part is that memory test makes the hang > > > go away, while repeating memory test operation only on the msgbuf region > > > does not. msgbuf is special in that it is located at TOHM (top of high > > > memory). It spans 128KB from below it to the last byte of the last > > > physical segment. > > > > > > The only ideas I have right now is that there is either a bug in the > > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > > is nothing OS can do to mitigate it. Or it might be that the memory > > > map reported by CMS is wrong (you said that you use legacy boot, right > > > ?). This is not too surprising if true, because non-EFI boot code path > > > definitely get less and less testing. > > > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > > mode and see whether the issue magically healths itself ? You could boot > > > from USB stick in EFI mode without reinstalling for test. > > > > I can't boot from USB stick -- this is remote DC and IPMI allow only > > CDROM emulation. > > > > OK, I am boot in UEFI 12.0 snapshot ISO. > > Boot ok. > > Sorry. Overload bu work and test wrong combination (NUMA=ON, > interleave=OFF) > > snapshot iso don't boot with NUMA=ON interleave=ON Ok. > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? Didn't you already tried ? > > PS: memmaps: > > NUMA=ON interleave=OFF > OK memmap > Type Physical Virtual #Pages Attr > BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB > ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB > BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB > BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB > ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB > BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB > ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB > LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB > LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB > BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB > ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB > BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB > Reserved 00007916b000 000000000000 00000817 UC WC WT WB > ConventionalMemory 000079982000 000000000000 0000011f UC WC WT WB > ACPIMemoryNVS 000079aa1000 000000000000 00000509 UC WC WT WB > RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB > RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB > BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB > RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB > BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB > ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB > Reserved 00007c000000 000000000000 00004000 > MemoryMappedIO 000080000000 000000000000 00010000 UC > MemoryMappedIO 0000fed1c000 000000000000 00000029 UC > MemoryMappedIO 0000ff000000 000000000000 00001000 UC > > NUMA=ON interleave=ON > Type Physical Virtual #Pages Attr > BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB > ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB > BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB > BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB > ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB > BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB > ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB > LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB > LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB > BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB > ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB > BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB > Reserved 00007916b000 000000000000 00000817 UC WC WT WB > ConventionalMemory 000079982000 000000000000 0000011f UC WC WT WB > ACPIMemoryNVS 000079aa1000 000000000000 00000509 UC WC WT WB > RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB > RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB > BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB > RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB > BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB > ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB > Reserved 00007c000000 000000000000 00004000 > MemoryMappedIO 000080000000 000000000000 00010000 UC > MemoryMappedIO 0000fed1c000 000000000000 00000029 UC > MemoryMappedIO 0000ff000000 000000000000 00001000 UC So my opinion did not changed, this sounds like firmware problem. I do not see how can I drill into it more. > > NUMA=OFF interleave=ON > Type Physical Virtual #Pages Attr > BootServicesCode 000000000000 000000000000 00000008 UC WC WT WB > ConventionalMemory 000000008000 000000000000 00000027 UC WC WT WB > BootServicesData 00000002f000 000000000000 00000011 UC WC WT WB > BootServicesCode 000000040000 000000000000 00000060 UC WC WT WB > ConventionalMemory 000000100000 000000000000 000660a3 UC WC WT WB > BootServicesData 0000661a3000 000000000000 00000080 UC WC WT WB > ConventionalMemory 000066223000 000000000000 000076b8 UC WC WT WB > LoaderData 00006d8db000 000000000000 00008000 UC WC WT WB > LoaderCode 0000758db000 000000000000 00000070 UC WC WT WB > BootServicesData 00007594b000 000000000000 00003220 UC WC WT WB > ConventionalMemory 000078b6b000 000000000000 0000028e UC WC WT WB > BootServicesCode 000078df9000 000000000000 00000372 UC WC WT WB > Reserved 00007916b000 000000000000 00000817 UC WC WT WB > ConventionalMemory 000079982000 000000000000 00000123 UC WC WT WB > ACPIMemoryNVS 000079aa5000 000000000000 00000505 UC WC WT WB > RuntimeServicesData 000079faa000 000000000000 00001dbd UC WC WT WB > RuntimeServicesCode 00007bd67000 000000000000 00000061 UC WC WT WB > BootServicesData 00007bdc8000 000000000000 00000001 UC WC WT WB > RuntimeServicesData 00007bdc9000 000000000000 00000086 UC WC WT WB > BootServicesData 00007be4f000 000000000000 000001b1 UC WC WT WB > ConventionalMemory 000100000000 000000000000 01f80000 UC WC WT WB > Reserved 00007c000000 000000000000 00004000 > MemoryMappedIO 000080000000 000000000000 00010000 UC > MemoryMappedIO 0000fed1c000 000000000000 00000029 UC > MemoryMappedIO 0000ff000000 000000000000 00001000 UC From owner-freebsd-current@freebsd.org Wed Dec 14 19:29:51 2016 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 B1752C80FFB for ; Wed, 14 Dec 2016 19:29:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 73E991554 for ; Wed, 14 Dec 2016 19:29:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHFFH-000PYn-I0; Wed, 14 Dec 2016 22:29:43 +0300 Date: Wed, 14 Dec 2016 22:29:43 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214192943.GG98176@zxy.spb.ru> References: <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214190349.GJ94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 19:29:51 -0000 On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > > > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > > > In other words, it is almost certainly the hang and not a fault causing > > > > hang. This means that the machine is not compliant with the IA32 > > > > architecture, in particular, the region reported as normal memory by > > > > E820 BIOS service does not behave as normal memory. > > > > > > > > Since regardless of the option setting, the memory map is same, and > > > > bootstrap page table only depend on the memory map, we use the same page > > > > table when hanging and when operating correctly. We do not fault or hang > > > > when the option is turned off, which together with the improved early > > > > fault handling in the patch, makes it almost certain that the problem is > > > > in hardware configuration and not in our early setup. > > > > > > > > Of course, the most puzzling part is that memory test makes the hang > > > > go away, while repeating memory test operation only on the msgbuf region > > > > does not. msgbuf is special in that it is located at TOHM (top of high > > > > memory). It spans 128KB from below it to the last byte of the last > > > > physical segment. > > > > > > > > The only ideas I have right now is that there is either a bug in the > > > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > > > is nothing OS can do to mitigate it. Or it might be that the memory > > > > map reported by CMS is wrong (you said that you use legacy boot, right > > > > ?). This is not too surprising if true, because non-EFI boot code path > > > > definitely get less and less testing. > > > > > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > > > mode and see whether the issue magically healths itself ? You could boot > > > > from USB stick in EFI mode without reinstalling for test. > > > > > > I can't boot from USB stick -- this is remote DC and IPMI allow only > > > CDROM emulation. > > > > > > OK, I am boot in UEFI 12.0 snapshot ISO. > > > Boot ok. > > > > Sorry. Overload bu work and test wrong combination (NUMA=ON, > > interleave=OFF) > > > > snapshot iso don't boot with NUMA=ON interleave=ON > Ok. > > > > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? > Didn't you already tried ? Different from FreeBSD. For sure about firmware problem and complains to Supermicro. I think FreeBSD problem don't be accepted by Supermicro. From owner-freebsd-current@freebsd.org Wed Dec 14 19:43:29 2016 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 2CB5FC805FE for ; Wed, 14 Dec 2016 19:43:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B54F61081 for ; Wed, 14 Dec 2016 19:43:28 +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 uBEJhOvc029943 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Dec 2016 21:43:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBEJhOvc029943 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBEJhOcC029942; Wed, 14 Dec 2016 21:43:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Dec 2016 21:43:24 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214194324.GM94325@kib.kiev.ua> References: <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161214192943.GG98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214192943.GG98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 14 Dec 2016 19:43:29 -0000 On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? > > Didn't you already tried ? > > Different from FreeBSD. Can you reformulate the statement ? Did you booted some other (non-FreeBSD) OS and it hung with that options as well ? > For sure about firmware problem and complains to Supermicro. > I think FreeBSD problem don't be accepted by Supermicro. You never know. From owner-freebsd-current@freebsd.org Wed Dec 14 19:49:02 2016 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 EC88DC8079A for ; Wed, 14 Dec 2016 19:49:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 A2C5213C5 for ; Wed, 14 Dec 2016 19:49:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHFXv-00006J-T8; Wed, 14 Dec 2016 22:48:59 +0300 Date: Wed, 14 Dec 2016 22:48:59 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161214194859.GI98176@zxy.spb.ru> References: <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161214192943.GG98176@zxy.spb.ru> <20161214194324.GM94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214194324.GM94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 14 Dec 2016 19:49:03 -0000 On Wed, Dec 14, 2016 at 09:43:24PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > > > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? > > > Didn't you already tried ? > > > > Different from FreeBSD. > Can you reformulate the statement ? > Did you booted some other (non-FreeBSD) OS and it hung with that options > as well ? No, I don't try now, can you advice some OS for test? > > For sure about firmware problem and complains to Supermicro. > > I think FreeBSD problem don't be accepted by Supermicro. > You never know. From owner-freebsd-current@freebsd.org Wed Dec 14 20:08:06 2016 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 1BEA1C80C77 for ; Wed, 14 Dec 2016 20:08:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::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 CA653A0; Wed, 14 Dec 2016 20:08:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id x190so4584457qkb.0; Wed, 14 Dec 2016 12:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4Jrdl1wRxDUiNYGRbpeTEyxzXlyYvCCSUEbHYfFpACw=; b=FP4oGVmCmYC8D7HMNyYda4Gz06FT/59/ypBg2cua2YKWcpdBLiyTU77EYD63doB/0e eEIq6wxIG9K4JRIlpHIo6BYW5iAHjRAPRyn1WYmDshC8p88xFnB8bsSS864ZnmQcV1KC trYi8xm8pQcyXp/JvQ78ghWeBP6BjYPZ+Q1YXHexTa3d4t/89FDsT57ysQj2kCRFw6rn 2CxuOovhkKTQZ9VSFn0G6+BFcS+6fKzxVRaMYO4LSLTVGMc28CI9Vscgoix9Ys1gv8Hp ZD+Q350MQACDe14WS/UqJ9UZaE0zP+y1QVrmUWASFuWp1ai8zGJ+vatmASREzZA8rBfy jSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=4Jrdl1wRxDUiNYGRbpeTEyxzXlyYvCCSUEbHYfFpACw=; b=Wn/b8NLcVLUculshrdUODosKP9otboTiVSlHRQkVt7Coi7rcRNbvxOJnxa7cA5BeHn 4hAt8tzvBmh1tUvfr5Cx2NRb3Rail+qXXJKOlDeijS1dlY6r5EnGZNNn25LkOfZ55kx1 8QKtLPYzQjU8DtBWvGhXGPBzgaQX/+CTT5SzxMv/J4gA5+gvfVd2RX4CZdQCYIDAgBV6 dHTOtUJshrA7HnzTKKCcuIua6HltS3/Z5HLdk4a36PjbbCziEoAV/LRcPS0wNgGaA8/g ilBEVvyOlDlSceDvawXMfz1BHxwJFCwuEeq/xIUsvS7DHSNeWko54zSzkbMSCmfByby3 i8rA== X-Gm-Message-State: AKaTC02kHu9tynBHiZfLM4TBRB4gwYLLvDYSm6FtJ2pzQo5b1cVdZZdyaZR+JGIlcm0c5w== X-Received: by 10.55.69.67 with SMTP id s64mr30117033qka.102.1481746085002; Wed, 14 Dec 2016 12:08:05 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id r8sm32454601qtc.32.2016.12.14.12.08.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 12:08:04 -0800 (PST) Sender: Mark Johnston Date: Wed, 14 Dec 2016 12:14:16 -0800 From: Mark Johnston To: kargl@uw.edu Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> References: <20161214194848.GA881@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214194848.GA881@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 14 Dec 2016 20:08:06 -0000 On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > Well, after 3 days of bisection, I finally found the commit > that renders my system unbootable. The system does not panic. > It simply gets stuck in some state. Nonfunctional keyboard, > so can't break into debugger. No serial console available. > The verbose dmesg.boot for a working kernel from revision > 309656 is at > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > The kernel config file is at > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > In looking at /usr/src/UPDATING, there is no warning that one > can create a boat anchor by upgrading to 309657. If compiling > a kernel with 'options DDB' is no longer supported, this should > be stated in UPDATING. Or, UPDATING should state that 'options > DDB' requires 'options STACK'. Or, 'options DDB' should simply > to the right thing and pull in whatever 'option STACK' does. It is supported though - the point of that change was to fix a problem that occurred when DDB is configured but STACK isn't. While testing I tried every combination of the two options, and I just tried and successfully booted a kernel with DDB and !STACK. Does the kernel boot successfully if STACK is added to your configuration? From owner-freebsd-current@freebsd.org Wed Dec 14 22:04:36 2016 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 74237C803F5 for ; Wed, 14 Dec 2016 22:04:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DF90D1B; Wed, 14 Dec 2016 22:04:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id n6so39291478qtd.1; Wed, 14 Dec 2016 14:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NwF1N6pBXLTD2lB0HeTBuByf0LAfBjDCiWMhCtoodZk=; b=hrJzQxmk51jbuM76FF6Suhn5meFHiT88ew5llrUUncnbVL7GacXFnbRIyhZ/flqzov bCjO9aPt1m4ZYP4S7p2DiCE9ywF2oCpxhK2HzM6tDzbY2jjyjDT7aOHSK2zNuvovtUY2 OnM/H49ShDiwVHc169Q3pPb2ceYb8B5v9r7+esmAg2QO13/A1KGyUVQ8kR+woHLawcaD rSVfpQdVxpZHQZ1jxo56j51lvXrZmDT8Ch8XEFlY3efevtY3nvQjXB+Y7kuffhSGSQcI 34eS1ZgzrIaD6ZB74O4WXcO4MMHPUSdl3MIelPzGD+vuc3b4G90bi/7yfC/FKA5JX7Z8 z60Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=NwF1N6pBXLTD2lB0HeTBuByf0LAfBjDCiWMhCtoodZk=; b=F1oziCE7V5q5WRYti6nUPYvsKIJ3MHQoAfNaDAl07rAFNUEmFKgMGIui3vZ9srMgOl 4rjjy/rvxWvgLfqguRym2XrAuMT2ftq+sm5HEsx/GdtXCX+jIYnPHcIhLQ6F7srZoZt/ 8WuofQL1vF0ddx65UqztuldF9uI4iVR4IhcCcdOCV7nuFTwZbkENoau3Th5A1lQkPKjd cllttUwS0GiQhtiFp/CJpnW0s3zSgOrTn4E9pgXxtEfyOnpdRYkUSufngFvnlTXTJyA+ +L3J/59EkjINDr3hV5vSD+5hs1AKoU9wafMVGb13npei6j2e3VVDQuOUyIFarrTIeuuG Gubg== X-Gm-Message-State: AKaTC010k8ukkTbhhmhaiyWkv3t7xylrlVWq0MWq+UWZsE//d7GOVTeC9XWG1Yf+WWPX3w== X-Received: by 10.200.38.39 with SMTP id u36mr98863381qtu.31.1481753075350; Wed, 14 Dec 2016 14:04:35 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id s65sm32810470qtd.2.2016.12.14.14.04.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 14:04:34 -0800 (PST) Sender: Mark Johnston Date: Wed, 14 Dec 2016 14:10:48 -0800 From: Mark Johnston To: kargl@uw.edu Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161214221048.GB64767@wkstn-mjohnston.west.isilon.com> References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 14 Dec 2016 22:04:36 -0000 On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > Well, after 3 days of bisection, I finally found the commit > > that renders my system unbootable. The system does not panic. > > It simply gets stuck in some state. Nonfunctional keyboard, > > so can't break into debugger. No serial console available. > > The verbose dmesg.boot for a working kernel from revision > > 309656 is at > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > The kernel config file is at > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > In looking at /usr/src/UPDATING, there is no warning that one > > can create a boat anchor by upgrading to 309657. If compiling > > a kernel with 'options DDB' is no longer supported, this should > > be stated in UPDATING. Or, UPDATING should state that 'options > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > to the right thing and pull in whatever 'option STACK' does. > > It is supported though - the point of that change was to fix a problem > that occurred when DDB is configured but STACK isn't. While testing I > tried every combination of the two options, and I just tried and > successfully booted a kernel with DDB and !STACK. > > Does the kernel boot successfully if STACK is added to your > configuration? I tried your config (plus virtio drivers) and was able to reproduce the hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of my change to re-add dead code into the kernel. My VM was always hanging after printing 000.000050 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 Sure enough, removing "device netmap" from your config also fixes the hang. When the hang occurs, I can see with "bhyvectl --get-rip" that we're stuck in DELAY(), but I can't get a stack at that point. I think my change is an innocent bystander - it just happened to expose a latent issue elsewhere. I don't have much more time to look at this right now, but I'll look into it more tonight. From owner-freebsd-current@freebsd.org Wed Dec 14 22:33:06 2016 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 186A7C80C78 for ; Wed, 14 Dec 2016 22:33:06 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.foxkit.us [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F31861DC0 for ; Wed, 14 Dec 2016 22:33:05 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 32065 invoked from network); 14 Dec 2016 22:30:14 -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.foxkit.us with ESMTPA; 14 Dec 2016 22:30:14 -0000 Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: freebsd-current@freebsd.org References: <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161214192943.GG98176@zxy.spb.ru> <20161214194324.GM94325@kib.kiev.ua> <20161214194859.GI98176@zxy.spb.ru> From: "A. Wilcox" Message-ID: <5851C7F0.1030507@Wilcox-Tech.com> Date: Wed, 14 Dec 2016 16:30:08 -0600 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: <20161214194859.GI98176@zxy.spb.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ola5rNQQDG3E6CvAXJD3eNLAgSdeRBsf" 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, 14 Dec 2016 22:33:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ola5rNQQDG3E6CvAXJD3eNLAgSdeRBsf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14/12/16 13:48, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:43:24PM +0200, Konstantin Belousov wrote: >=20 >> On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: >>> On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: >>> >>>> On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: >>>>> For test hardware setup (NUMA+interleave), what ISO I can try to bo= ot? >>>> Didn't you already tried ? >>> >>> Different from FreeBSD. >> Can you reformulate the statement ? >> Did you booted some other (non-FreeBSD) OS and it hung with that optio= ns >> as well ? >=20 > No, I don't try now, can you advice some OS for test? Ugh, Supermicro is big pain. Try CentOS, also try Debian. Just to see. Maybe you get lucky, and one of them hangs too... Debian usually runs older kernels, so more likely to not have a workaround. Best solution: new mainboard vendor, until Supermicro works out their dumb firmware and makes it less dumb. :( --arw --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --7ola5rNQQDG3E6CvAXJD3eNLAgSdeRBsf 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 iQIcBAEBCAAGBQJYUcfwAAoJEMspy1GSK50UxgoP/jJoSlXUBRviMgoGDjwnt0nf lI7r+Mer5qdS6UmpStijFvTmL9EXHEabkOy6G+3E4MlDJiPSCCyYuhvWBtblbdC9 rlTrnhuoTkAcqrjrYJmZ9/Etjx4gY+lXt+p1+b+LINpPjJxfvEX3yQ9KIe/YCAwX AhyPh3uT9dQc+uv5v0oK7/XlWBdnPjkGAr+qAiY10aN0na70HRetPOyqL3pzOMOy RqI7kf4gYWSweXkVpGtoGskuJbwh3R2sEwePsDJ5MWBXo0xO7PISUYZ7+IDxsZ2g +D5SrUFVLLK9fbIfsX9iZHeU3HF72jPXUw4eRKCztIA5oi7rkwrjAJuLx+jVsx2E yRMH1V+NtcAm2aFBtnt6/d4tjR7nJVhMPE5mI5Bf3fIJlxzOtnCeImfOr9xkc/Vn 6NvDbUCl4i4t6f4PA99mczBgmhheicCASUTAnCdGDkhOTu1/Zp8cKJdB6mJCc11E RARDQaabKL+hOqActo09/MEGGLBtP1Cezhx8WCwbeaV6HgnqnwQUy+FxAftdZBLS DskgvnWMfUi829mmIHSWm7LtaEtbW1+7Mly2koAlyUVqgeg5XigundUaDsKlnbYP p80d8qoRgURJz/8S/N01QNWfay3Rw+Dlr+kCqkwD5MMnc/sVUsSufXcC4FmCJ886 qRHKaEUYC4/eIm8+uOGQ =jcaO -----END PGP SIGNATURE----- --7ola5rNQQDG3E6CvAXJD3eNLAgSdeRBsf-- From owner-freebsd-current@freebsd.org Thu Dec 15 00:44:12 2016 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 4885AC750E6 for ; Thu, 15 Dec 2016 00:44:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::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 01D2C819; Thu, 15 Dec 2016 00:44:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id h201so5277579qke.3; Wed, 14 Dec 2016 16:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=c9HpRDt4lPR0av7gju99Obtne0ygN0Y0/yXZYnFp5ds=; b=TrD8WwxXto6IiMBLA5TEAOBzaggMwYyvdrRrxB5YkhOY7o9ZErOIHsEsrM7p+vVwTB EcxdYOf0tUPIVI9Vayf3Nz8yuceX2q1hn03SjnUKy+pov5j6le+oI+Ubb2MTs6ibzRbA v1Du3WA0HTLB7fqnf1t5r7PGIVCM0qGYdv7J8Z1Orncmc1h149ZjZfyA2McIaMPWaIwi biByo7OZ7OpMHgbcyK45/iog3RadIag2p4rSl3GrG5T/8amO5bU+m36ri7A4tHGp3now 6CZ3+ohICrvK3Jwzmm90nIzf0vaGk5mbYKqEGGxmAcTcOvpJjgwHDMbgY97pUSsNvoOM Nj2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=c9HpRDt4lPR0av7gju99Obtne0ygN0Y0/yXZYnFp5ds=; b=gFrsB3Bhlzm2SiLXEHeznipko+XEzWxEYgEO3PzGHqhNQZEAUtTztKW/XSfWUIboK2 E5vo90d1/1BI1cbOb0dGxaTcbGJkJUhP3gwP8b4ydmRUYZNgdWsO3CXc7vEC6aAyx62/ McDL1elPpdYrDhpowp7u2AQ11ITVoXQPisGsNcbCKiwhgbSGgMkeCYbnAK9B5G2MPhw5 h7pYShVLXCv9GAyb27MmxefDWsp8vMQ57Y2Cl1SDNHF44+SFrioi+B6Ivee8BLOyKdaf 8uI47lRqSD3S4clgQmsMRHxPb9MBJDGdxutCi5alj9G3P5y+R1gVOrczizhJZaqPnWWi Y8gg== X-Gm-Message-State: AKaTC003jViInfdWGXqynOyyDCKrWqm1nPC+a3zenb132NsEALB51+hk3yWE0hSIkdx7eQ== X-Received: by 10.55.127.129 with SMTP id a123mr87230973qkd.129.1481762650668; Wed, 14 Dec 2016 16:44:10 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id h47sm33077386qtc.27.2016.12.14.16.44.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 16:44:10 -0800 (PST) Sender: Mark Johnston Date: Wed, 14 Dec 2016 16:50:21 -0800 From: Mark Johnston To: kargl@uw.edu Cc: freebsd-current@freebsd.org, kib@freebsd.org, jhb@FreeBSD.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> <20161214221048.GB64767@wkstn-mjohnston.west.isilon.com> <20161214234804.GA26443@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214234804.GA26443@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 15 Dec 2016 00:44:12 -0000 On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote: > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > > Well, after 3 days of bisection, I finally found the commit > > > > that renders my system unbootable. The system does not panic. > > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > > so can't break into debugger. No serial console available. > > > > The verbose dmesg.boot for a working kernel from revision > > > > 309656 is at > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > > > The kernel config file is at > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > > can create a boat anchor by upgrading to 309657. If compiling > > > > a kernel with 'options DDB' is no longer supported, this should > > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > > to the right thing and pull in whatever 'option STACK' does. > > > > > > It is supported though - the point of that change was to fix a problem > > > that occurred when DDB is configured but STACK isn't. While testing I > > > tried every combination of the two options, and I just tried and > > > successfully booted a kernel with DDB and !STACK. > > > > > > Does the kernel boot successfully if STACK is added to your > > > configuration? > > > > I tried your config (plus virtio drivers) and was able to reproduce the > > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > > my change to re-add dead code into the kernel. My VM was always hanging > > after printing > > > > 000.000050 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 > > > > Sure enough, removing "device netmap" from your config also fixes the > > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > > we're stuck in DELAY(), but I can't get a stack at that point. I think > > my change is an innocent bystander - it just happened to expose a latent > > issue elsewhere. > > > > I don't have much more time to look at this right now, but I'll look > > into it more tonight. > > Yes, adding STACK got me to a booting kernel. I can't remember > why I added netmap to my config file. Re-adding dead code seems to > point to some memory corruption issue or a rogue pointer. :( It's not quite that bad, as it turns out. The key is that adding/removing the dead code changes the ordering of the items in the sysinit linker set. I discovered that if the ctl(4) module is initialized before the vtnet driver attaches, the hang occurs, and reverting my commit results in a sysinit order where vtnet comes _before_ ctl(4). So my change triggers the problem just because it happens to perturb something in the compile-time linker. > > BTW, I think it would be prudent to add something like > > 20161206: > At revision 309657, 'options STACK' was introduced into > sys/x86/x86/mstack_machdep.c. Old kernel configuration files > that included 'options DDB' are now required to include also > 'options STACK'. > > to UPDATING or some such wording. I was jumping from circ Oct 10th world > to top of tree, and got caught by ~3000 commits. The issue actually seems to be in 4BSD, and more specifically in r308564 and r308565. Switching to ULE or reverting either of those two commits fixes the hang. Here's what happens: 1. ctl_init() runs and creates ctl_thresh_thread. This thread's main loop cause pause(9) when it has no work to do. During boot, pause(9) just calls DELAY() and does not yield the CPU. 2. thread0 attaches the vtnet driver. As part of this, it creates and starts some high-priority taskqueue threads in _taskqueue_thread_start(). They're added to the scheduler with: thread_lock(); sched_pri(...); sched_add(...); thread_unlock(); 4BSD's sched_add() will call maybe_preempt() in this case, which as of r308564 will unconditionally set td_owepreempt in the current thread. 3. thread_unlock() will release the critical section held by the current thread and because td_owepreempt is set, we'll yield the CPU. The taskqueue threads have nothing to do, but ctl_thresh_thread runs and ends up busy-waiting in pause() forever. r308565 removes a check in maybe_preempt() that would have stopped td_owepreempt from being set. Before r308564, maybe_preempt() would have switched directly to the new thread and apparently always switched back immediately. I'm not sure what the correct fix is - jhb might have an idea. I wonder if pause() should try to yield periodically when called during boot. From owner-freebsd-current@freebsd.org Wed Dec 14 19:49:26 2016 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 BB321C8081D for ; Wed, 14 Dec 2016 19:49:26 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DFDD15F7; Wed, 14 Dec 2016 19:49:26 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id uBEJnQrf001176 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 11:49:26 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id uBEJnQDF001175; Wed, 14 Dec 2016 11:49:26 -0800 (PST) (envelope-from kargl) Date: Wed, 14 Dec 2016 11:49:26 -0800 From: "Steven G. Kargl" To: freebsd-current@freebsd.org, markj@freebsd.org, kib@freebsd.org Subject: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161214194848.GA881@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Thu, 15 Dec 2016 00:53:51 +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: Wed, 14 Dec 2016 19:49:26 -0000 Well, after 3 days of bisection, I finally found the commit that renders my system unbootable. The system does not panic. It simply gets stuck in some state. Nonfunctional keyboard, so can't break into debugger. No serial console available. The verbose dmesg.boot for a working kernel from revision 309656 is at http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt The kernel config file is at http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt In looking at /usr/src/UPDATING, there is no warning that one can create a boat anchor by upgrading to 309657. If compiling a kernel with 'options DDB' is no longer supported, this should be stated in UPDATING. Or, UPDATING should state that 'options DDB' requires 'options STACK'. Or, 'options DDB' should simply to the right thing and pull in whatever 'option STACK' does. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ From owner-freebsd-current@freebsd.org Wed Dec 14 23:48:05 2016 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 C8859C803BD for ; Wed, 14 Dec 2016 23:48:05 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2165CEB; Wed, 14 Dec 2016 23:48:05 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id uBENm4dR064714 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 15:48:04 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id uBENm4ZL064711; Wed, 14 Dec 2016 15:48:04 -0800 (PST) (envelope-from kargl) Date: Wed, 14 Dec 2016 15:48:04 -0800 From: "Steven G. Kargl" To: Mark Johnston Cc: kargl@uw.edu, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161214234804.GA26443@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> <20161214221048.GB64767@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214221048.GB64767@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Thu, 15 Dec 2016 00:59:28 +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: Wed, 14 Dec 2016 23:48:05 -0000 On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > Well, after 3 days of bisection, I finally found the commit > > > that renders my system unbootable. The system does not panic. > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > so can't break into debugger. No serial console available. > > > The verbose dmesg.boot for a working kernel from revision > > > 309656 is at > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > The kernel config file is at > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > can create a boat anchor by upgrading to 309657. If compiling > > > a kernel with 'options DDB' is no longer supported, this should > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > to the right thing and pull in whatever 'option STACK' does. > > > > It is supported though - the point of that change was to fix a problem > > that occurred when DDB is configured but STACK isn't. While testing I > > tried every combination of the two options, and I just tried and > > successfully booted a kernel with DDB and !STACK. > > > > Does the kernel boot successfully if STACK is added to your > > configuration? > > I tried your config (plus virtio drivers) and was able to reproduce the > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > my change to re-add dead code into the kernel. My VM was always hanging > after printing > > 000.000050 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 > > Sure enough, removing "device netmap" from your config also fixes the > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > we're stuck in DELAY(), but I can't get a stack at that point. I think > my change is an innocent bystander - it just happened to expose a latent > issue elsewhere. > > I don't have much more time to look at this right now, but I'll look > into it more tonight. Yes, adding STACK got me to a booting kernel. I can't remember why I added netmap to my config file. Re-adding dead code seems to point to some memory corruption issue or a rogue pointer. :( BTW, I think it would be prudent to add something like 20161206: At revision 309657, 'options STACK' was introduced into sys/x86/x86/mstack_machdep.c. Old kernel configuration files that included 'options DDB' are now required to include also 'options STACK'. to UPDATING or some such wording. I was jumping from circ Oct 10th world to top of tree, and got caught by ~3000 commits. Oh, and thanks for the work you've done on FreeBSD. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ From owner-freebsd-current@freebsd.org Thu Dec 15 01:03:15 2016 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 C46CEC75784 for ; Thu, 15 Dec 2016 01:03:15 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACB1A1595; Thu, 15 Dec 2016 01:03:15 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id uBF13Eh8037766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 17:03:14 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id uBF13EQ2037765; Wed, 14 Dec 2016 17:03:14 -0800 (PST) (envelope-from kargl) Date: Wed, 14 Dec 2016 17:03:14 -0800 From: "Steven G. Kargl" To: Mark Johnston Cc: kargl@uw.edu, freebsd-current@freebsd.org, kib@freebsd.org, jhb@FreeBSD.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161215010314.GA56272@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214201416.GA64767@wkstn-mjohnston.west.isilon.com> <20161214221048.GB64767@wkstn-mjohnston.west.isilon.com> <20161214234804.GA26443@troutmask.apl.washington.edu> <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Thu, 15 Dec 2016 01:27:32 +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: Thu, 15 Dec 2016 01:03:15 -0000 On Wed, Dec 14, 2016 at 04:50:21PM -0800, Mark Johnston wrote: > On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote: > > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > > > Well, after 3 days of bisection, I finally found the commit > > > > > that renders my system unbootable. The system does not panic. > > > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > > > so can't break into debugger. No serial console available. > > > > > The verbose dmesg.boot for a working kernel from revision > > > > > 309656 is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > > > > > The kernel config file is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > > > can create a boat anchor by upgrading to 309657. If compiling > > > > > a kernel with 'options DDB' is no longer supported, this should > > > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > > > to the right thing and pull in whatever 'option STACK' does. > > > > > > > > It is supported though - the point of that change was to fix a problem > > > > that occurred when DDB is configured but STACK isn't. While testing I > > > > tried every combination of the two options, and I just tried and > > > > successfully booted a kernel with DDB and !STACK. > > > > > > > > Does the kernel boot successfully if STACK is added to your > > > > configuration? > > > > > > I tried your config (plus virtio drivers) and was able to reproduce the > > > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > > > my change to re-add dead code into the kernel. My VM was always hanging > > > after printing > > > > > > 000.000050 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 > > > > > > Sure enough, removing "device netmap" from your config also fixes the > > > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > > > we're stuck in DELAY(), but I can't get a stack at that point. I think > > > my change is an innocent bystander - it just happened to expose a latent > > > issue elsewhere. > > > > > > I don't have much more time to look at this right now, but I'll look > > > into it more tonight. > > > > Yes, adding STACK got me to a booting kernel. I can't remember > > why I added netmap to my config file. Re-adding dead code seems to > > point to some memory corruption issue or a rogue pointer. :( > > It's not quite that bad, as it turns out. The key is that > adding/removing the dead code changes the ordering of the items in the > sysinit linker set. I discovered that if the ctl(4) module is > initialized before the vtnet driver attaches, the hang occurs, and > reverting my commit results in a sysinit order where vtnet comes > _before_ ctl(4). So my change triggers the problem just because it > happens to perturb something in the compile-time linker. Thanks for the explanation. > The issue actually seems to be in 4BSD, and more specifically in r308564 > and r308565. Switching to ULE or reverting either of those two commits > fixes the hang. Oh, this is bad. The last time I checked (and it has been awhile ago), ULE has/had some very bad performance issues for numerical computations that use OpenMPI (or likely any MPI implementation) if a node becomes oversubscribed. 4BSD at least manages to recover. Thanks for the pointer to r308564 and 65. I'll take a look later tonight as I've managed to break both firefox and chrome during the upgrade. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ From owner-freebsd-current@freebsd.org Thu Dec 15 10:51:22 2016 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 DBCC5C80609 for ; Thu, 15 Dec 2016 10:51:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 9B2EDAD3 for ; Thu, 15 Dec 2016 10:51:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHTd8-0003lp-Td; Thu, 15 Dec 2016 13:51:18 +0300 Date: Thu, 15 Dec 2016 13:51:18 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161215105118.GK98176@zxy.spb.ru> References: <20161213152838.GL90287@zxy.spb.ru> <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161214190349.GJ94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 15 Dec 2016 10:51:23 -0000 On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > So my opinion did not changed, this sounds like firmware problem. > I do not see how can I drill into it more. I am don't know how it related. msgbufp mapped different with and w/o memory test: w/o memory test, hang: msgbufp=0xfffff8207ff00000 pa_indx=7 phys_avail[pa_indx]=207ff00000 w/ memory test, boot: msgbufp=0xfffff8203ff00000 pa_indx=7 phys_avail[pa_indx]=203ff00000 From owner-freebsd-current@freebsd.org Thu Dec 15 11:42:27 2016 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 B0C72C81D4C for ; Thu, 15 Dec 2016 11:42:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (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 7931BC67; Thu, 15 Dec 2016 11:42:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B6ACD12CB0; Thu, 15 Dec 2016 12:42:14 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_175CFEA3-39E2-4079-B580-9103000D16CB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing From: Dimitry Andric In-Reply-To: <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Thu, 15 Dec 2016 12:42:00 +0100 Cc: freebsd-current@FreeBSD.org, Baptiste Daroussin Message-Id: <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> References: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> To: jenkins-admin@freebsd.org 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: Thu, 15 Dec 2016 11:42:27 -0000 --Apple-Mail=_175CFEA3-39E2-4079-B580-9103000D16CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Dec 2016, at 12:03, jenkins-admin@freebsd.org wrote: >=20 > FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: >=20 > Build information: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/ > Full change log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes > Full build log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/console ... > building shared library libprivatedevdctl.so.0 > /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem = /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/i= nclude/c++/v1 -std=3Dc++11 -nostdinc++ -isystem = /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/i= nclude = -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr= /lib = -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr= /lib = --sysroot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_g= cc/tmp -B/usr/local/x86_64-freebsd/bin/ -fstack-protector-strong = -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o = libprivatedevdctl.so.0.full -Wl,-soname,libprivatedevdctl.so.0 = `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder = consumer.pico event.pico event_factory.pico exception.pico guid.pico | = tsort -q` > /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ Dear Jenkins admins, can you please install a more recent version of amd64-xtoolchain-gcc on the slave? This is required to avoid the above error about not being able to find libstdc++. -Dimitry --Apple-Mail=_175CFEA3-39E2-4079-B580-9103000D16CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhSgZQACgkQsF6jCi4glqPMWwCdERAFYaMialmWlSSPzX8EM9Ab wO0AnjKCeoavUx1WRO3WOxTLiq3oK4sV =B+hI -----END PGP SIGNATURE----- --Apple-Mail=_175CFEA3-39E2-4079-B580-9103000D16CB-- From owner-freebsd-current@freebsd.org Thu Dec 15 12:33:39 2016 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 EDCFCC76EC6 for ; Thu, 15 Dec 2016 12:33:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6407D105C for ; Thu, 15 Dec 2016 12:33:39 +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 uBFCXUdE082469 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Dec 2016 14:33:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBFCXUdE082469 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBFCXUPt082468; Thu, 15 Dec 2016 14:33:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Dec 2016 14:33:30 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161215123330.GQ94325@kib.kiev.ua> References: <20161213172529.GC54029@kib.kiev.ua> <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161215105118.GK98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215105118.GK98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 15 Dec 2016 12:33:40 -0000 On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > So my opinion did not changed, this sounds like firmware problem. > > I do not see how can I drill into it more. > > I am don't know how it related. msgbufp mapped different with and w/o > memory test: > > w/o memory test, hang: > msgbufp=0xfffff8207ff00000 pa_indx=7 phys_avail[pa_indx]=207ff00000 > > w/ memory test, boot: > msgbufp=0xfffff8203ff00000 pa_indx=7 phys_avail[pa_indx]=203ff00000 Interesting. Can you show me - the output of the smap command from the loader (yes, I know it was already shown, I want it in the same mail as the data below for convenience); - the output of sysctl machdep.smap after the succesfull boot with the memtest enabled. Possibly, the dmesg of the boot (with late_console=0) with this and only this patch applied against stock HEAD. This might be long. diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 682307f5fe4..072c8d76acf 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first) */ *(int *)ptr = tmp; +if (page_bad) printf("pb 0x%lx\n", pa); skip_memtest: /* * Adjust array of valid/good pages. From owner-freebsd-current@freebsd.org Thu Dec 15 13:16:28 2016 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 3B382C81B7B for ; Thu, 15 Dec 2016 13:16:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 F07308E1 for ; Thu, 15 Dec 2016 13:16:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHVtY-00084s-Ry; Thu, 15 Dec 2016 16:16:24 +0300 Date: Thu, 15 Dec 2016 16:16:24 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161215131624.GL98176@zxy.spb.ru> References: <20161213174345.GB98176@zxy.spb.ru> <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161215105118.GK98176@zxy.spb.ru> <20161215123330.GQ94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215123330.GQ94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 15 Dec 2016 13:16:28 -0000 On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote: > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > > > So my opinion did not changed, this sounds like firmware problem. > > > I do not see how can I drill into it more. > > > > I am don't know how it related. msgbufp mapped different with and w/o > > memory test: > > > > w/o memory test, hang: > > msgbufp=0xfffff8207ff00000 pa_indx=7 phys_avail[pa_indx]=207ff00000 > > > > w/ memory test, boot: > > msgbufp=0xfffff8203ff00000 pa_indx=7 phys_avail[pa_indx]=203ff00000 > Interesting. > > Can you show me > - the output of the smap command from the loader (yes, I know it was already > shown, I want it in the same mail as the data below for convenience); OK set hw.memtest.tests=1 OK smap SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > - the output of sysctl machdep.smap after the succesfull boot with the > memtest enabled. machdep.smap: SMAP type=01, xattr=01, base=0000000000000000, len=0000000000099c00 SMAP type=02, xattr=01, base=0000000000099c00, len=0000000000006400 SMAP type=02, xattr=01, base=00000000000e0000, len=0000000000020000 SMAP type=01, xattr=01, base=0000000000100000, len=000000007906b000 SMAP type=02, xattr=01, base=000000007916b000, len=0000000000936000 SMAP type=04, xattr=01, base=0000000079aa1000, len=0000000000509000 SMAP type=02, xattr=01, base=0000000079faa000, len=0000000002056000 SMAP type=01, xattr=01, base=0000000100000000, len=0000001f80000000 SMAP type=02, xattr=01, base=000000007c000000, len=0000000014000000 SMAP type=02, xattr=01, base=00000000fed1c000, len=0000000000029000 SMAP type=02, xattr=01, base=00000000ff000000, len=0000000001000000 > Possibly, the dmesg of the boot (with late_console=0) with this and only > this patch applied against stock HEAD. This might be long. Do you need all (262144?) lines? Testing system memory........................................................................................................................pb 0x2040000000 pb 0x2040001000 pb 0x2040002000 pb 0x2040003000 pb 0x2040004000 pb 0x2040005000 pb 0x2040006000 [...] pb 0x207ffff000 > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > index 682307f5fe4..072c8d76acf 100644 > --- a/sys/amd64/amd64/machdep.c > +++ b/sys/amd64/amd64/machdep.c > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first) > */ > *(int *)ptr = tmp; > > +if (page_bad) printf("pb 0x%lx\n", pa); > skip_memtest: > /* > * Adjust array of valid/good pages. PS: memtest86 hung at test 128-130G (server have 128G installed). From owner-freebsd-current@freebsd.org Thu Dec 15 13:57:03 2016 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 53DC7C81B13 for ; Thu, 15 Dec 2016 13:57:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE2571FDB for ; Thu, 15 Dec 2016 13:57: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 uBFDuvCH003024 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Dec 2016 15:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBFDuvCH003024 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBFDuubE003022; Thu, 15 Dec 2016 15:56:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Dec 2016 15:56:56 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161215135656.GS94325@kib.kiev.ua> References: <20161214095350.GE94325@kib.kiev.ua> <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161215105118.GK98176@zxy.spb.ru> <20161215123330.GQ94325@kib.kiev.ua> <20161215131624.GL98176@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215131624.GL98176@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 15 Dec 2016 13:57:03 -0000 On Thu, Dec 15, 2016 at 04:16:24PM +0300, Slawa Olhovchenkov wrote: > On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote: > > > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > > > > > So my opinion did not changed, this sounds like firmware problem. > > > > I do not see how can I drill into it more. > > > > > > I am don't know how it related. msgbufp mapped different with and w/o > > > memory test: > > > > > > w/o memory test, hang: > > > msgbufp=0xfffff8207ff00000 pa_indx=7 phys_avail[pa_indx]=207ff00000 > > > > > > w/ memory test, boot: > > > msgbufp=0xfffff8203ff00000 pa_indx=7 phys_avail[pa_indx]=203ff00000 > > Interesting. > > > > Can you show me > > - the output of the smap command from the loader (yes, I know it was already > > shown, I want it in the same mail as the data below for convenience); > > OK set hw.memtest.tests=1 > OK smap > SMAP type=01 base=0000000000000000 len=0000000000099c00 attr=01 > SMAP type=02 base=0000000000099c00 len=0000000000006400 attr=01 > SMAP type=02 base=00000000000e0000 len=0000000000020000 attr=01 > SMAP type=01 base=0000000000100000 len=000000007906b000 attr=01 > SMAP type=02 base=000000007916b000 len=0000000000936000 attr=01 > SMAP type=04 base=0000000079aa1000 len=0000000000509000 attr=01 > SMAP type=02 base=0000000079faa000 len=0000000002056000 attr=01 > SMAP type=01 base=0000000100000000 len=0000001f80000000 attr=01 > SMAP type=02 base=000000007c000000 len=0000000014000000 attr=01 > SMAP type=02 base=00000000fed1c000 len=0000000000029000 attr=01 > SMAP type=02 base=00000000ff000000 len=0000000001000000 attr=01 > > > - the output of sysctl machdep.smap after the succesfull boot with the > > memtest enabled. > > machdep.smap: > SMAP type=01, xattr=01, base=0000000000000000, len=0000000000099c00 > SMAP type=02, xattr=01, base=0000000000099c00, len=0000000000006400 > SMAP type=02, xattr=01, base=00000000000e0000, len=0000000000020000 > SMAP type=01, xattr=01, base=0000000000100000, len=000000007906b000 > SMAP type=02, xattr=01, base=000000007916b000, len=0000000000936000 > SMAP type=04, xattr=01, base=0000000079aa1000, len=0000000000509000 > SMAP type=02, xattr=01, base=0000000079faa000, len=0000000002056000 > SMAP type=01, xattr=01, base=0000000100000000, len=0000001f80000000 > SMAP type=02, xattr=01, base=000000007c000000, len=0000000014000000 > SMAP type=02, xattr=01, base=00000000fed1c000, len=0000000000029000 > SMAP type=02, xattr=01, base=00000000ff000000, len=0000000001000000 > > > Possibly, the dmesg of the boot (with late_console=0) with this and only > > this patch applied against stock HEAD. This might be long. > > Do you need all (262144?) lines? > > Testing system > memory........................................................................................................................pb 0x2040000000 > pb 0x2040001000 > pb 0x2040002000 > pb 0x2040003000 > pb 0x2040004000 > pb 0x2040005000 > pb 0x2040006000 > [...] > pb 0x207ffff000 > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > index 682307f5fe4..072c8d76acf 100644 > > --- a/sys/amd64/amd64/machdep.c > > +++ b/sys/amd64/amd64/machdep.c > > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first) > > */ > > *(int *)ptr = tmp; > > > > +if (page_bad) printf("pb 0x%lx\n", pa); > > skip_memtest: > > /* > > * Adjust array of valid/good pages. > > PS: memtest86 hung at test 128-130G (server have 128G installed). Well, the physical memory is 128G, but it is not mapped contiguously into the address space accessible to the processors. E.g. in the SMAPs you posted above, there are several holes (type 2) used for PCIe config window, PCI BARs, APICs, and other i/o register pages. Intel chipsets allow to remap the RAM hidden by the io pages, which is probably not done correctly by BIOS. The SMAP clearly reports segment 0x100000000-0x2080000000 as populated by RAM, this is 4G-130G. Very primitive memory test in kernel does not like all pages starting at 129G. Possibly important detail is that kernel memory test only touches first 4 bytes on each page. So if BIOS erronously mapped any io registers into that range, memory test might luckily avoid touching anything critical, but still noting that the page does not behave as RAM. Update BIOS, and if the issue persists, contact supermicro. This interesting detail adds even more evidence that BIOS is problematic. From owner-freebsd-current@freebsd.org Thu Dec 15 17:56:56 2016 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 81008C81AFE for ; Thu, 15 Dec 2016 17:56:56 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7983C16E0; Thu, 15 Dec 2016 17:56:55 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id 5F0982E3C; Fri, 16 Dec 2016 01:56:46 +0800 (CST) Date: Fri, 16 Dec 2016 01:56:46 +0800 From: Li-Wen Hsu To: Dimitry Andric Cc: jenkins-admin@freebsd.org, freebsd-current@FreeBSD.org, Baptiste Daroussin Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing Message-ID: <20161215175646.GA64982@FreeBSD.cs.nctu.edu.tw> References: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 15 Dec 2016 17:56:56 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote: > On 15 Dec 2016, at 12:03, jenkins-admin@freebsd.org wrote: > >=20 > > FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: > >=20 > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_g= cc/1733/ > > Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc= /1733/changes > > Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/= 1733/console > ... > > building shared library libprivatedevdctl.so.0 > > /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBSD_= HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -st= d=3Dc++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/Fr= eeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/b= uilds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc/o= bj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HE= AD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-free= bsd/bin/ -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,= --warn-shared-textrel -o libprivatedevdctl.so.0.full -Wl,-soname,libprivat= edevdctl.so.0 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder= consumer.pico event.pico event_factory.pico exception.pico guid.pico | ts= ort -q` > > /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ >=20 > Dear Jenkins admins, can you please install a more recent version of > amd64-xtoolchain-gcc on the slave? This is required to avoid the above > error about not being able to find libstdc++. Also from the console log: + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The most recent version of packages are already installed The build script install/update the latest devel/amd64-xtoolchain-gcc package. I think the problem is we did not upgrade the dependencies. I cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's dependencies, so I added a line to build script to upgrade everything before build. Let see if this works. Best, Li-Wen --=20 Li-Wen Hsu https://lwhsu.org --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJYUtldXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWuEkP/RDcstwAhGmKhu6E2RieQJY4 i3As0RuJhN5baltVpSbsvBszxXpwaqXdOymkp2/LN48GkvSj4a+BIWxtAY9QQERE sXjnvjrU/hb72TPQbqJmvL/YIY1UGKs5SODIOYhb/qQ188PFMmv/qesb1GtoqkE9 Ivykn+Scwf9FiyGxV9Xx2ehSNywb7UWIeBcT/HQxzeFTwpGxLBmcRXLSvMAhO4cF mpigEJsMhSrG7oWolvpUXm21NWPEEYPnCK1aAMvXFLKRAnzmtMBF3FCYRBThc7ew jA+X/7tLThQZ8SrKnOjg24DZG52Rpgghs0RM5FqfHktHmeMPB6J8HAIhKEn61IYi NrBKUNLbmS/TthAKjsvx9+pvaU6l0/JovtGM6fOyCtrqDvKFx8Gu3zXHo5Qj+tj/ Z+agkUxYKCgv0TmqOiFOVdnHYy+mhFhg4F6ky8MYslhb5s2PjBAQ3aOEFUmS5exK 7fwLu4wqZ78nvXTH6nPmuNbUFr80YbPb92cjHor27mNKkf+VkF9b8m5tQ1P69ZF3 tEVaFlA3osIwlOqEQmSpnahUVvlhzRn3pcAUlDed6tteLtJPVQ9/ykd+E6zS7Kzu IX+Ha9qsC8inLimjSfeOhSsZN+xoO61eNq3GvnTmNUtTCb8eLRO/gf9VWs8vgEb/ VVP8KEMMCgnbUG/zjY5g =XY+B -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-current@freebsd.org Thu Dec 15 22:45:10 2016 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 078C2C82D60 for ; Thu, 15 Dec 2016 22:45:10 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 B506A1DE1 for ; Thu, 15 Dec 2016 22:45:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHelo-0000aX-LE; Fri, 16 Dec 2016 01:45:00 +0300 Date: Fri, 16 Dec 2016 01:45:00 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161215224500.GM98176@zxy.spb.ru> References: <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161215105118.GK98176@zxy.spb.ru> <20161215123330.GQ94325@kib.kiev.ua> <20161215131624.GL98176@zxy.spb.ru> <20161215135656.GS94325@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215135656.GS94325@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 15 Dec 2016 22:45:10 -0000 On Thu, Dec 15, 2016 at 03:56:56PM +0200, Konstantin Belousov wrote: > > > Possibly, the dmesg of the boot (with late_console=0) with this and only > > > this patch applied against stock HEAD. This might be long. > > > > Do you need all (262144?) lines? > > > > Testing system > > memory........................................................................................................................pb 0x2040000000 > > pb 0x2040001000 > > pb 0x2040002000 > > pb 0x2040003000 > > pb 0x2040004000 > > pb 0x2040005000 > > pb 0x2040006000 > > [...] > > pb 0x207ffff000 > > > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > > index 682307f5fe4..072c8d76acf 100644 > > > --- a/sys/amd64/amd64/machdep.c > > > +++ b/sys/amd64/amd64/machdep.c > > > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first) > > > */ > > > *(int *)ptr = tmp; > > > > > > +if (page_bad) printf("pb 0x%lx\n", pa); > > > skip_memtest: > > > /* > > > * Adjust array of valid/good pages. > > > > PS: memtest86 hung at test 128-130G (server have 128G installed). > Well, the physical memory is 128G, but it is not mapped contiguously into > the address space accessible to the processors. E.g. in the SMAPs you > posted above, there are several holes (type 2) used for PCIe config > window, PCI BARs, APICs, and other i/o register pages. Intel chipsets > allow to remap the RAM hidden by the io pages, which is probably not > done correctly by BIOS. > > The SMAP clearly reports segment 0x100000000-0x2080000000 as populated > by RAM, this is 4G-130G. Very primitive memory test in kernel does > not like all pages starting at 129G. Possibly important detail is that > kernel memory test only touches first 4 bytes on each page. So if BIOS > erronously mapped any io registers into that range, memory test might > luckily avoid touching anything critical, but still noting that the > page does not behave as RAM. > > Update BIOS, and if the issue persists, contact supermicro. This > interesting detail adds even more evidence that BIOS is problematic. Updated BIOS don't solve this. From owner-freebsd-current@freebsd.org Thu Dec 15 23:58:02 2016 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 4C83AC81217 for ; Thu, 15 Dec 2016 23:58:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (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 D60A71F51 for ; Thu, 15 Dec 2016 23:58:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wj0-x236.google.com with SMTP id tk12so80360395wjb.3 for ; Thu, 15 Dec 2016 15:58:01 -0800 (PST) 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=PQHba36slLvTchqRUSNSAfZeI8w4uCIHGVhysixORbI=; b=I/KlI/Dvsr/Eya8KuD/XHbefPlOYJgtglurgX+TwE3Wzmkr8AO0IrwG7RqMeZzIBQf ZUS4mrezS4PFZ3dHwTZMjjjpv7LwjmjaA338DMljVXgaaVplVmu1F/5JDyIegWn74Ojn RPlL8b1kOdykYH3kRSxt4YdrNo44JV+mdqfiKINm/VDMQ5B/dB2J8E3CuGsihVP2+ktW f6XLH6YMSgLDelko0ZvDZo1QNf2UbGoHMomjiH5xIpeKaKwaCGkYijRvttOeXTQlKE5t +yQuKeGI2XTznUIbanMOtEvp4qdPRrVQF6M/YUNM7Dd5OHukFBoZ7Hb/RzzhryGxMlQW sI5w== 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=PQHba36slLvTchqRUSNSAfZeI8w4uCIHGVhysixORbI=; b=HSdBURqNB8wbumeHJvEybHlnka/knce3kZULz9O0Mdg9S9WMKNTUgvq6P146kRmsCY we2+5Ijuw2h4GxNxqYOBCsncEDsdHe60Jy3r7fa0JMGWK45ma6wgRo7SsemoPZQ1BKfv ejwpOPdC/EHXKeh0M9J3RbDbHuJeL86wotootvTqGZbNMc7U1646srlRp8YRxoj8lRK2 129vx4424JgBzTfd+dX4hx0uukR243ryi7ZAbA8eP2ya0iyLh9RuacM59ZyLHCfEwBtl nHZc64UT+1457oeZkI7pnwx6k+/TtUi1V65opLESEe1O3M5ox0QMnwLxdQxDttUTlbMl SXCQ== X-Gm-Message-State: AIkVDXLleAqmy5lyBxAV+1EGSvSmuPUX+ZUooqUV5mzLy5zLbMigU2U7rpyUxcdjxmvqeNZvtmSMOKfToaIOWg== X-Received: by 10.194.205.34 with SMTP id ld2mr53555wjc.211.1481846280432; Thu, 15 Dec 2016 15:58:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.1 with HTTP; Thu, 15 Dec 2016 15:57:58 -0800 (PST) In-Reply-To: <20161215224500.GM98176@zxy.spb.ru> References: <20161214102711.GF94325@kib.kiev.ua> <20161214105211.GC98176@zxy.spb.ru> <20161214113927.GG94325@kib.kiev.ua> <20161214121336.GD98176@zxy.spb.ru> <20161214152627.GF98176@zxy.spb.ru> <20161214190349.GJ94325@kib.kiev.ua> <20161215105118.GK98176@zxy.spb.ru> <20161215123330.GQ94325@kib.kiev.ua> <20161215131624.GL98176@zxy.spb.ru> <20161215135656.GS94325@kib.kiev.ua> <20161215224500.GM98176@zxy.spb.ru> From: Adrian Chadd Date: Thu, 15 Dec 2016 15:57:58 -0800 Message-ID: Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: Slawa Olhovchenkov Cc: Konstantin Belousov , 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: Thu, 15 Dec 2016 23:58:02 -0000 heh, an updated BIOS that solves the problem will solve the problem. :) I think you have enough information to provide to supermicro. Ie, "SMAP says X, when physical memory pages at addresses X are accessed, they don't behave like memory, maybe something is wrong". All I can think of is some hack to add a blacklist for that region so you can boot the unit. But it makes me wonder what else is going on. -adrian From owner-freebsd-current@freebsd.org Fri Dec 16 01:48:37 2016 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 05CE2C82A6B for ; Fri, 16 Dec 2016 01:48:37 +0000 (UTC) (envelope-from qiz@vmware.com) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0065.outbound.protection.outlook.com [104.47.42.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2FA116D3 for ; Fri, 16 Dec 2016 01:48:36 +0000 (UTC) (envelope-from qiz@vmware.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y4jKwXmgeowT5c8au5LcysePfjXLr+PDD/JGOSsDOVw=; b=pS+sQRGzWihj4NLEpVPJ5lSnO34VNn31JSDQ64CYXjwTTKhBQqZEnfOWFna1Hh5sKnnFPd3gPwOP8pExMLZ1oh3One7gawvFO618GFn6TgTEmDSbDj17EUGpFtI/YSDb9LOzezV1fNSIKRNalyTVWAxdR0V4b9JZOQohhTd762A= Received: from CY1PR05MB2748.namprd05.prod.outlook.com (10.167.18.18) by CY1PR05MB2746.namprd05.prod.outlook.com (10.167.18.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Fri, 16 Dec 2016 01:48:29 +0000 Received: from CY1PR05MB2748.namprd05.prod.outlook.com ([10.167.18.18]) by CY1PR05MB2748.namprd05.prod.outlook.com ([10.167.18.18]) with mapi id 15.01.0803.005; Fri, 16 Dec 2016 01:48:29 +0000 From: Qi Zhang To: "freebsd-current@freebsd.org" Subject: Questions about FreeBSD support for NVDIMM Thread-Topic: Questions about FreeBSD support for NVDIMM Thread-Index: AdJVpZua7gSunwiCSd+6kLj6ZuNj9wBl/czA Date: Fri, 16 Dec 2016 01:48:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=qiz@vmware.com; x-originating-ip: [208.91.1.34] x-ms-office365-filtering-correlation-id: 4fcab5ea-26b8-4dcd-80aa-08d42555a250 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2746; x-microsoft-exchange-diagnostics: 1; CY1PR05MB2746; 7:Qx1d2q49uZrlls7FFIDfiAHO8Tm/XJgBitiIX+Qv4tumwg25RdmeTEnBvuyE9NzYaebExjKwW9MyeZEYo4M0zL1DDDnqkiYUL8GnozFw5J1uMu3ltGANgtSWMqVGeCU6yS/CJ29ytIMoAe5069Go2w0H9KbxpCcoZmq7SfVqrbUdKQd/ieD3+8D4JSERmAyjMRBGktuVlRt8/ZbGa9wzib1Up0azYcyXOt+YXamMZR+Ddz7d8E8afk1jbNuObX7+7N+dNFN7mneVmzzq6Tmje9owSwHqiBGt/BADs5d+ELdaPFxUDschsqAa65tZOVhruWGY2oxBYolvzCVTIQ59ZUBl29pddC7z0IuDXnzZgRdjepzhTvs+hSGupKjYP4c86qsbuUTJccq+8jgL03DyueGE9cUyVY7BnLBN/jiTsz4oRSJF7cheKsdKDVgT1ZDxmryBlYGFW9IGFAPSiuyvJg==; 20:v9sqefSHRkagi/PBkU1mTC4bnZTTM8u+p0cjLZLADQBV/ri65BBUkkpQG+yLtxAxFjx6Mn2XPTV6XhEWX/fCHcUpTMJl2kXb2c9NC9yjOu2jnJJ1ZUH8PssUdbdkXrayVkMN/8EQMOMYPMdudfaaWd+BoG70bZj/GnC4JHzuA98= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR05MB2746; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2746; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(377424004)(97736004)(9686002)(110136003)(2906002)(81156014)(3846002)(8936002)(5660300001)(81166006)(189998001)(7696004)(6116002)(76576001)(102836003)(50986999)(76176999)(6916009)(5640700003)(8676002)(101416001)(54356999)(305945005)(2950100002)(66066001)(6506006)(92566002)(2900100001)(74316002)(3280700002)(33656002)(122556002)(3660700001)(7736002)(6436002)(106356001)(107886002)(2501003)(2351001)(450100001)(99286002)(38730400001)(105586002)(86362001)(68736007)(77096006)(25786008); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR05MB2746; H:CY1PR05MB2748.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 01:48:29.0113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2746 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: Fri, 16 Dec 2016 01:48:37 -0000 Dear All, Does anybody know NVDIMM support status and plan in current FreeBSD? I not= iced this message "Have "Traditional" NVDIMM support (rpokala@)" on https:/= /wiki.freebsd.org/VendorDevSummit/201611/HaveNeedWant. If anyone knows abou= t the details, please share with me and I will appreciate that. Thanks Best Regards - Qi (Keira) GOSV | 18F, Raycom, Beijing | +86-10-599 34604 From owner-freebsd-current@freebsd.org Fri Dec 16 02:11:55 2016 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 E9632C77473 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) 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 DB4D81D3B for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id DA63EC77472; Fri, 16 Dec 2016 02:11:55 +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 DA0ACC77471 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A80951D39 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EC7837300A; Fri, 16 Dec 2016 03:17:19 +0100 (CET) Date: Fri, 16 Dec 2016 03:17:19 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: best approximation of getcpu() ? Message-ID: <20161216021719.GA63374@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 16 Dec 2016 02:11:56 -0000 TL;DR; is there any way a userspace thread in FreeBSD can tell on which CPU it is (was) running ? I know the thread can migrate at any time but as long as the event is rare I can live with the occasionally wrong information. Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), but the linuxulator in FreeBSD only has a dummy (uniplemented) function for that syscall. FULL DESCRIPTION It is common practice, when building scalable systems, to use per-cpu resources that can be accessed without contention by just protecting them with a CLI; STI; pair. Multiqueue NICs typically do this to build a lock-free transmit path. In [1] we show an in-kernel scheduler that maps a large number of clients to a (much smaller) number of lock-free mailboxes, one per core. In the kernel we can do CLI and STI and access curcpu. In userspace a suitably privileged process can indeed open /dev/io to acquire the right to use CLI and STI, though I am not sure wether curcpu is available in some way. Of course running userspace code with interrupts disabled is risky, but we can use the per-cpu trick with a small tweak, namely, protect each resouce with a lock. If the thread does not migrate imediately after getcpu(), we will access the lock (and the resource) almost always from the same cpu hence very efficiently. Occasional migration may cause contention but should not alter too much the good performance of this scheme. So, any idea before I add a syscall/ioctl (or extend one) to export this information ? thanks luigi [1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf From owner-freebsd-current@freebsd.org Fri Dec 16 03:10:08 2016 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 AB10EC82148 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8B854A06 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8AE56C82147; Fri, 16 Dec 2016 03:10: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 8A891C82146 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 5871AA05 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id n204so9847669qke.2 for ; Thu, 15 Dec 2016 19:10:08 -0800 (PST) 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; bh=a1lIm9LSxI0OjAtRg8uGFsgDuSy6XuLjXFPYHFBnzSg=; b=L0dVmjM6xcZ6S0/WaDrNx6s9AYUpgakm2JorRYCnbsFEtgTYfMAaTw9d5aBUuLxgcp 9yV7ph8tPiBC3ZfP/4AiWw/VJ5DItY2XEa5eonU1XBmbqHpb3DYtPDF/QfCpfn8OE4uO Y42CtAz8Nwj507y+jU3LqMmYvfNzIPCnHrUti66+3a8e2gn66IvC10cnjlVKFDJdk/sy 9kbznEFwKXBsTju/9I0c8sr4+Vi7bfzuB+6UdS0egdg2pAdp4PGDeUIudV0mlu5otr13 YgWCUfZz/Rh1X3ut42aG04qAzGzVKGngo4CrBb0OXCfRXChV9j58e5QX8P+Bj6mQP8oe 4iMQ== 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; bh=a1lIm9LSxI0OjAtRg8uGFsgDuSy6XuLjXFPYHFBnzSg=; b=DyCb321TwEYrix5wntXOGeyr0tUDzzP+Y9Ul9Tp+f8w3cATCsT1bIXMLEOqMULFkMe ZulIDzQYXvBZz4oA8PiA/8QNMc+XRN78U7Welsd/NEeeiLC1lvT8JrYjk3sYv8DpHOlK gSUXjgXaUKY5l5XRKINbYG7L3Gb+bdV8KK92eIDuGOn0q8TIcehlw+PcAHsbaQzb1dVZ Y9Obh/zE1vbe2qi9fYmbX5wYRzeLyqvq/Al8YnmLMoVLgyKJv3IQukD6AZyDrVZouJZD YDXmTIisyZjMaoiMWxi8Nle65uVhO5AF31MgccIyy4N65zzCnzou/mPlVqiFapmDqRrX t0+w== X-Gm-Message-State: AIkVDXL+MrOd5iqvDTJDxg1DspL2qrIc7zfH4wetZu9/GlEHGYtDCs+PEzt8ctLIOax3QxkIpW6KeH+hQKm2nw== X-Received: by 10.55.12.19 with SMTP id 19mr819670qkm.100.1481857807267; Thu, 15 Dec 2016 19:10:07 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.181.208 with HTTP; Thu, 15 Dec 2016 19:10:06 -0800 (PST) In-Reply-To: <20161216021719.GA63374@onelab2.iet.unipi.it> References: <20161216021719.GA63374@onelab2.iet.unipi.it> From: Alan Somers Date: Thu, 15 Dec 2016 20:10:06 -0700 X-Google-Sender-Auth: stjWywJT2FvaAhoL_ANm1gcJhB4 Message-ID: Subject: Re: best approximation of getcpu() ? To: Luigi Rizzo Cc: "current@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: Fri, 16 Dec 2016 03:10:08 -0000 On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo wrote: > TL;DR; is there any way a userspace thread in FreeBSD can tell > on which CPU it is (was) running ? I know the thread can migrate > at any time but as long as the event is rare I can live with > the occasionally wrong information. > Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), > but the linuxulator in FreeBSD only has a dummy (uniplemented) > function for that syscall. > > FULL DESCRIPTION > It is common practice, when building scalable systems, to use per-cpu > resources that can be accessed without contention by just protecting > them with a CLI; STI; pair. Multiqueue NICs typically do this to > build a lock-free transmit path. In [1] we show an in-kernel > scheduler that maps a large number of clients to a (much smaller) > number of lock-free mailboxes, one per core. > > In the kernel we can do CLI and STI and access curcpu. > In userspace a suitably privileged process can indeed open /dev/io > to acquire the right to use CLI and STI, though I am not sure > wether curcpu is available in some way. > > Of course running userspace code with interrupts disabled is risky, > but we can use the per-cpu trick with a small tweak, namely, > protect each resouce with a lock. If the thread does not migrate > imediately after getcpu(), we will access the lock (and the resource) > almost always from the same cpu hence very efficiently. > Occasional migration may cause contention but should not > alter too much the good performance of this scheme. > > So, any idea before I add a syscall/ioctl (or extend one) > to export this information ? > > thanks > luigi > > > [1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf What about pthread_setaffinity(3) and friends? You can use it to pin a thread to a single CPU, and know that it will never migrate. -Alan From owner-freebsd-current@freebsd.org Fri Dec 16 03:57:24 2016 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 0B9CEC82DBD for ; Fri, 16 Dec 2016 03:57:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9BC81E99; Fri, 16 Dec 2016 03:57:23 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1481860636; bh=WzVJczh4L hjII/HlrU7qKAg1NXptC25Lbl2aYtw6mYM=; b=fIxvCphpaGjlZwBKXZaYuCc1u ffSVEOn85AXRp5OyLpasQaFXp2xzaTF9TfyUGQeV+b0kDNrrZjh/mE1lDN0q8YZG MOu/4fyMtucaLQ3neRzwD/yXymPHQEH1p7FqZfrdYYhYdHR89ZpQ2ABhZHdl0hs+ eCuo5OcoOBTTkuleCM= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 11AE91BC72; Thu, 15 Dec 2016 22:57:16 -0500 (EST) To: freebsd-current , hrs@freebsd.org From: Michael Butler Subject: syslogd no longer listens (or sends) on a network socket Message-ID: Date: Thu, 15 Dec 2016 22:57:15 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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, 16 Dec 2016 03:57:24 -0000 It appears that SVN r309925 and onward no longer opens a network socket unless the command-line explicitly contains "-b :syslog" :-( This also stops one syslog daemon forwarding to another (which is why I noticed). Was this an intentional behaviour change? Michael From owner-freebsd-current@freebsd.org Fri Dec 16 09:31:11 2016 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 CCDB2C77108 for ; Fri, 16 Dec 2016 09:31:11 +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 6128E1308 for ; Fri, 16 Dec 2016 09:31:11 +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 uBG9V1Lk008546 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Dec 2016 10:31:01 +0100 (CET) (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 uBG9V1sr008543 for ; Fri, 16 Dec 2016 10:31:01 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 16 Dec 2016 10:31:01 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: /usr/share/man/man4/cc.4.gz obsolete? Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) 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: Fri, 16 Dec 2016 09:31:11 -0000 /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run make -C /usr/src check-old. make -C /usr/src delete-old removes the file, but make -C /usr/src installworld adds it. System is base/head r309889. Please make up your mind. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik 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 Fri Dec 16 13:28:41 2016 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 E3AA6C8337F for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 D1CE1F67 for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id CE118C8337E; Fri, 16 Dec 2016 13:28: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 CDBA7C8337D for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 91AC3F66 for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHsYu-0005kF-QS; Fri, 16 Dec 2016 16:28:36 +0300 Date: Fri, 16 Dec 2016 16:28:36 +0300 From: Slawa Olhovchenkov To: Luigi Rizzo Cc: current@freebsd.org Subject: Re: best approximation of getcpu() ? Message-ID: <20161216132836.GB90401@zxy.spb.ru> References: <20161216021719.GA63374@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161216021719.GA63374@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 16 Dec 2016 13:28:42 -0000 On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo wrote: > TL;DR; is there any way a userspace thread in FreeBSD can tell > on which CPU it is (was) running ? I know the thread can migrate > at any time but as long as the event is rare I can live with > the occasionally wrong information. > Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), > but the linuxulator in FreeBSD only has a dummy (uniplemented) > function for that syscall. > > FULL DESCRIPTION > It is common practice, when building scalable systems, to use per-cpu > resources that can be accessed without contention by just protecting > them with a CLI; STI; pair. Multiqueue NICs typically do this to > build a lock-free transmit path. In [1] we show an in-kernel > scheduler that maps a large number of clients to a (much smaller) > number of lock-free mailboxes, one per core. > > In the kernel we can do CLI and STI and access curcpu. > In userspace a suitably privileged process can indeed open /dev/io > to acquire the right to use CLI and STI, though I am not sure > wether curcpu is available in some way. > > Of course running userspace code with interrupts disabled is risky, > but we can use the per-cpu trick with a small tweak, namely, > protect each resouce with a lock. If the thread does not migrate > imediately after getcpu(), we will access the lock (and the resource) > almost always from the same cpu hence very efficiently. > Occasional migration may cause contention but should not > alter too much the good performance of this scheme. > > So, any idea before I add a syscall/ioctl (or extend one) > to export this information ? Most hard task is discover what irq handle specific NIC tx/rx queue (assume irq already have affinity). After this discover (by some magic shit) no problem to start pthread and execute some like CPU_ZERO(&mask); CPU_SET(i, &mask); pthread_attr_init(&attr); pthread_attr_setaffinity_np(&attr, sizeof(mask), &mask); pthread_create(&balancer[i].tid, &attr, balancer_thread, &balancer[i]); pthread_set_name_np(balancer[i].tid, name); From owner-freebsd-current@freebsd.org Fri Dec 16 14:03:34 2016 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 3DA18C83BC0 for ; Fri, 16 Dec 2016 14:03:34 +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 26648635 for ; Fri, 16 Dec 2016 14:03:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 25B3BC83BBF; Fri, 16 Dec 2016 14:03:34 +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 25540C83BBE for ; Fri, 16 Dec 2016 14:03:34 +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 CE02C634 for ; Fri, 16 Dec 2016 14:03:33 +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 uBGE3Plu076025 for ; Fri, 16 Dec 2016 14:03:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id uBGE3Pe0076024 for current@freebsd.org; Fri, 16 Dec 2016 06:03:25 -0800 (PST) (envelope-from david) Date: Fri, 16 Dec 2016 06:03:25 -0800 From: David Wolfskill To: current@freebsd.org Subject: Install tools in src/Makefile.inc1 might need to be augmented Message-ID: <20161216140325.GC1273@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="J0Hdqn9B/gTAA2yl" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) 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, 16 Dec 2016 14:03:34 -0000 --J0Hdqn9B/gTAA2yl Content-Type: multipart/mixed; boundary="JqY+AWET127RXf8r" Content-Disposition: inline --JqY+AWET127RXf8r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I found the attached patch (which augments ITOOLS in src/Makefile.inc1 with "env" and "mktemp") necessary to complete "make installworkd" when updtaing from: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #197 r3= 10104M/310111:1200018: Thu Dec 15 04:20:23 PST 2016 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 to: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #198 r3= 10154M/310154:1200019: Fri Dec 16 05:31:10 PST 2016 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 Peace, david --=20 David H. Wolfskill david@catwhisker.org Epistemology for post-truthers: How do we select parts of reality to ignore? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --JqY+AWET127RXf8r Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="Makefile.inc1.diff" Content-Transfer-Encoding: quoted-printable Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 310154) +++ Makefile.inc1 (working copy) @@ -915,8 +915,8 @@ .endif =20 ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ - date echo egrep find grep id install ${_install-info} \ - ln make mkdir mtree mv pwd_mkdb \ + date echo egrep env find grep id install ${_install-info} \ + ln make mkdir mktemp mtree mv pwd_mkdb \ rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} \ ${LOCAL_ITOOLS} =20 --JqY+AWET127RXf8r-- --J0Hdqn9B/gTAA2yl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYU/QtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XdvYIAJLUAZxNq4M4rx13d6hWH08Y K0BYpVxS99XOwBkK03pQUlIzSCZLQXQg+w53bI1DEoih6PyI0NP3NYhSIxaUw2eB XIQMQuO5ioDG3JKRaXjg9r/Keq1oJjfnz780yJ8hmYJaTzTn7t7EetuOP78mOudG BkURTXJfui7mmMcnhXAE7pTuin2D4Ig2x5stp8XeypqvYCjMihn8CPOrPjmfaZkw AWUM3XLhr9trATaDWm1OvyNMwuh5w+38SBhNEwUfttilb5DgJe7PxrmCDaicgSry Ud4R3PrIR3GEZ/EwUd6gxWBr8awvBiE5XB0OosLqdtatupG9s/ioZbbTzfB/chM= =lMdc -----END PGP SIGNATURE----- --J0Hdqn9B/gTAA2yl-- From owner-freebsd-current@freebsd.org Fri Dec 16 15:41:36 2016 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 DAC4CC83C54 for ; Fri, 16 Dec 2016 15:41:36 +0000 (UTC) (envelope-from lifanov@FreeBSD.org) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 C39661D01 for ; Fri, 16 Dec 2016 15:41:36 +0000 (UTC) (envelope-from lifanov@FreeBSD.org) Received: from [10.11.0.110] (unknown [198.85.229.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id A5985239C62 for ; Fri, 16 Dec 2016 10:41:29 -0500 (EST) Subject: Re: /usr/share/man/man4/cc.4.gz obsolete? To: freebsd-current@freebsd.org References: From: Nikolai Lifanov Message-ID: <6a42b833-3bf0-aae9-fb3b-e4c3358a3f1c@FreeBSD.org> Date: Fri, 16 Dec 2016 10:41:27 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UdTt5mAltOVDWl7q8ia6tdirQBMGAfMar" 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, 16 Dec 2016 15:41:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UdTt5mAltOVDWl7q8ia6tdirQBMGAfMar Content-Type: multipart/mixed; boundary="GN2G3kwmtk15s75JPWI7i0xNroVVG8rTp"; protected-headers="v1" From: Nikolai Lifanov To: freebsd-current@freebsd.org Message-ID: <6a42b833-3bf0-aae9-fb3b-e4c3358a3f1c@FreeBSD.org> Subject: Re: /usr/share/man/man4/cc.4.gz obsolete? References: In-Reply-To: --GN2G3kwmtk15s75JPWI7i0xNroVVG8rTp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/16/2016 04:31, Trond Endrest=F8l wrote: > /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run=20 > make -C /usr/src check-old. >=20 > make -C /usr/src delete-old removes the file, but=20 > make -C /usr/src installworld adds it. >=20 > System is base/head r309889. >=20 > Please make up your mind. >=20 This is installed by cxgbe module directory for if_cc (T6 cards) and previously removed as an old congestion control page. I put up a review to fix this: https://reviews.freebsd.org/D8816 - Nikolai --GN2G3kwmtk15s75JPWI7i0xNroVVG8rTp-- --UdTt5mAltOVDWl7q8ia6tdirQBMGAfMar Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKoBAEBCgCSFiEE5oT6TcuaWvG5gtjzZ6sv56ecR0UFAlhUCydfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU2 ODRGQTREQ0I5QTVBRjFCOTgyRDhGMzY3QUIyRkU3QTc5QzQ3NDUUHGxpZmFub3ZA ZnJlZWJzZC5vcmcACgkQZ6sv56ecR0WEdw//aEziSTDO5TjE0K013M98jXF+T9mB ALFkaBj2N37g9mNVWYe0XLSvLME7moS0ZKwuVvW/1c6lw+/C1na+DINi8ZPENe4y MfTSqCz/inLNGqH0oa9VD4E4O3kXVMdvuldnEj6LIcVyZprBECkTz8Hbv/sJUwar gbZNBOIotQfouiLe6whNMCR6L1ca2LJ9NVpXvwsiJDHo5CGhr6YYDBvTA4I5VcTA /lXztntOmcRr2moZSoWTN1WluisTgDigFFVVP72E5xkgTmu3ub/rilscleEIdN7/ K6OiZfQJABCMuGF3Vj/wtsweCz8gYPF1/nU7fgRmynxIQm8DibUXYCPogQjrsXO3 VZAXgQtrwRbY38IBZrGOqhH6qAenMgBcqHfz3AeR6AbUqmgiCulaS2T/sujPdWtU U0+0JNRmPFU3XEOV6T657xfB3p0t/hLPV9EEwUkQmPr251b1toHzkIMrH3wnO+A+ RJZelXDJtZKWW6iVZUYeisHbKtdBLVg9h/ABFa5oa0QqX1i+0CgeMfRvJljKGtEi LBWUNt/2HkDhRDiBAx8aldPdWybDDwwUi0+0fpzOo1M2xoeOZWy3o6oi9PMF4+1b bNJwTiorHddAiHbKarc+jAKHG2BOexgXBZiYqGlREjQQ1gML0RjYIXD3FB7eQbH8 uv2V/kxtwhTdgcI= =j34P -----END PGP SIGNATURE----- --UdTt5mAltOVDWl7q8ia6tdirQBMGAfMar-- From owner-freebsd-current@freebsd.org Fri Dec 16 19:31:50 2016 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 D95A2C83E9E for ; Fri, 16 Dec 2016 19:31:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) 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 C7DC0819 for ; Fri, 16 Dec 2016 19:31:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id C73E4C83E9D; Fri, 16 Dec 2016 19:31: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 C6EA3C83E9C for ; Fri, 16 Dec 2016 19:31:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 92BB4815; Fri, 16 Dec 2016 19:31:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B553C7300A; Fri, 16 Dec 2016 20:45:19 +0100 (CET) Date: Fri, 16 Dec 2016 20:45:19 +0100 From: Luigi Rizzo To: David Chisnall Cc: Alan Somers , "current@freebsd.org" Subject: Re: best approximation of getcpu() ? Message-ID: <20161216194519.GA71398@onelab2.iet.unipi.it> References: <20161216021719.GA63374@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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, 16 Dec 2016 19:31:50 -0000 On Fri, Dec 16, 2016 at 09:29:15AM +0000, David Chisnall wrote: > On 16 Dec 2016, at 03:10, Alan Somers wrote: > > > > What about pthread_setaffinity(3) and friends? You can use it to pin > > a thread to a single CPU, and know that it will never migrate. > > This is not a useable solution for anything that needs to live in a library and also doesn???t solve the problem. > > The Linux get_cpu call() is used for caches that are somewhere between global and thread-local. Accessing them still requires a lock, but it???s very likely to be uncontended (contention only happens when you???re context switched at exactly the wrong time, or if a thread is migrated between cores in between the get_cpu() call and usage) and so you can use the userspace fast path for the lock and not suffer from cache contention effects. > > One x86, you can use cpuid from userspace and get the current core ID. I have some code that does this and re-checks every few hundred accesses, storing the current CPU ID in a thread-local variable. Using the per-CPU caches is a lot faster than using the global cache (and reduces contention on the global cache). It would be great if we could have a syscall to do this on FreeBSD (it would be even better if we could have specify a TLS variable that the kernel automatically updates for the userspace thread when the scheduler migrates the thread between cores). indeed the following line seems to do the job for x86 asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp) : "a"(0xb) ); (there must be a better way to tell the compiler that eax, ebx, ecx, edx are all clobbered). 0xb is the CPUID function that returns the current APIC id for the core (not necessarily matching the OS core-id) The only problem is that this instruction is serialising and slow, seems to take some 70-100ns on several of my machines so you cannot afford to call it at all times but need the value cached somewhere. Exposing it as thread local storage, or a VDSO syscall, would be nicer because the kernel knows when it is actually changing value. cheers luigi From owner-freebsd-current@freebsd.org Fri Dec 16 20:10:04 2016 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 5FE96C8383C for ; Fri, 16 Dec 2016 20:10:04 +0000 (UTC) (envelope-from adrian.chadd@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 3DD57109 for ; Fri, 16 Dec 2016 20:10:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3A47AC8383B; Fri, 16 Dec 2016 20:10:04 +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 39E75C8383A for ; Fri, 16 Dec 2016 20:10:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::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 C25E4108; Fri, 16 Dec 2016 20:10:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wj0-x232.google.com with SMTP id v7so100677615wjy.2; Fri, 16 Dec 2016 12:10:03 -0800 (PST) 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:content-transfer-encoding; bh=aKLIczVWhuvI5tLGk683G7SzCAPzeQL2CB2jdD0SNBw=; b=KjpJQhgEoNWJIKoOC9656wa4RFkfGEEsTKlb/jxRF0dV6kDoSpB0iIey/ogPjyG5Mc XyW5bljUz275WbxDS4se7ZifRNvnwPFGLxb1lYrruQUhoxobuaFNOocZHe4N7vNeczgJ l6xbBiB4A7WQRnIB5wS2jzlqA+9QM+gQNNOef5j793jJyRt8nSEFQxPr+1Bft2TnNdI0 sK2Q9CGcSE0AOgCiViepD2ZAYQCAq5ySNME36QJDMV2YztT1q/+O1q++KF1xU8N9/WTs /O6C6SleX3+73iM+Xvw/oJ7rJGAi9mS+GMQyJ4tFEAQClV36gDOoUoT+eaqcyQMAOeJK a9fQ== 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:content-transfer-encoding; bh=aKLIczVWhuvI5tLGk683G7SzCAPzeQL2CB2jdD0SNBw=; b=GF02ja0q/EFVtADhzwmd0l4ASTSt716jxYDt+eJA49b1HpDv/m5kwss/yznIbdPDcp 748iUNHuI2nLBvFO94W9qzbX24M2mzV6RqzOfAtZZCXdVUEx9G7Yh/nOs6Zd4a5f1o7F 04UMTgANaQIC54f/mMQ5abDXM7oKd8Wuwe4T+yd8J5lDVwElnQFm/mj+3W+gled3C15B 13P7nhLiq62o2f1moOnCTf8US9gl1oxQuKOiyNysejuYWQ4p3KEuXeRt7xP8UtPqEeDe LZz0PrrsLX49UOn8PMlN2ThTwzcKc/Rkbu/qKTbJygLCS5eG+odSe5GTpV//ylcROmmh Anww== X-Gm-Message-State: AIkVDXIIboe5UZZKRweZJSJmCMTfSCMJDqb1FVIDAqDH1McD/bxzkFGmolttzWr8bVbeFLaSzgWDhuKoDnD4bw== X-Received: by 10.194.187.103 with SMTP id fr7mr4114198wjc.99.1481919001904; Fri, 16 Dec 2016 12:10:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.1 with HTTP; Fri, 16 Dec 2016 12:10:01 -0800 (PST) In-Reply-To: <20161216194519.GA71398@onelab2.iet.unipi.it> References: <20161216021719.GA63374@onelab2.iet.unipi.it> <20161216194519.GA71398@onelab2.iet.unipi.it> From: Adrian Chadd Date: Fri, 16 Dec 2016 12:10:01 -0800 Message-ID: Subject: Re: best approximation of getcpu() ? To: Luigi Rizzo Cc: David Chisnall , Alan Somers , "current@freebsd.org" 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: Fri, 16 Dec 2016 20:10:04 -0000 On 16 December 2016 at 11:45, Luigi Rizzo wrote: > On Fri, Dec 16, 2016 at 09:29:15AM +0000, David Chisnall wrote: >> On 16 Dec 2016, at 03:10, Alan Somers wrote: >> > >> > What about pthread_setaffinity(3) and friends? You can use it to pin >> > a thread to a single CPU, and know that it will never migrate. >> >> This is not a useable solution for anything that needs to live in a libr= ary and also doesn???t solve the problem. >> >> The Linux get_cpu call() is used for caches that are somewhere between g= lobal and thread-local. Accessing them still requires a lock, but it???s v= ery likely to be uncontended (contention only happens when you???re context= switched at exactly the wrong time, or if a thread is migrated between cor= es in between the get_cpu() call and usage) and so you can use the userspac= e fast path for the lock and not suffer from cache contention effects. >> >> One x86, you can use cpuid from userspace and get the current core ID. = I have some code that does this and re-checks every few hundred accesses, s= toring the current CPU ID in a thread-local variable. Using the per-CPU ca= ches is a lot faster than using the global cache (and reduces contention on= the global cache). It would be great if we could have a syscall to do thi= s on FreeBSD (it would be even better if we could have specify a TLS variab= le that the kernel automatically updates for the userspace thread when the = scheduler migrates the thread between cores). > > indeed the following line seems to do the job for x86 > asm volatile("cpuid" : "=3Dd"(curcpu), "=3Da"(tmp), "=3Db"(tmp), = "=3Dc"(tmp) : "a"(0xb) ); > (there must be a better way to tell the compiler that eax, ebx, ecx, edx = are > all clobbered). > > 0xb is the CPUID function that returns the current APIC id for the > core (not necessarily matching the OS core-id) > > The only problem is that this instruction is serialising and slow, > seems to take some 70-100ns on several of my machines so you > cannot afford to call it at all times but need the value cached > somewhere. Exposing it as thread local storage, or a VDSO syscall, > would be nicer because the kernel knows when it is actually changing > value. The problem is your CPU ID can change in the middle of packet handling. So if you want it to be accurate, you need to bind your worker thread to a = CPU. -adrian From owner-freebsd-current@freebsd.org Fri Dec 16 21:31:01 2016 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 5800FC832A6 for ; Fri, 16 Dec 2016 21:31:01 +0000 (UTC) (envelope-from jhb@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 422F114C9 for ; Fri, 16 Dec 2016 21:31:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3E6C4C832A3; Fri, 16 Dec 2016 21:31:01 +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 3DE95C832A2; Fri, 16 Dec 2016 21:31:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19D7114C8; Fri, 16 Dec 2016 21:31:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0F8EE10AA2C; Fri, 16 Dec 2016 16:31:00 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Adrian Chadd , Luigi Rizzo , David Chisnall , Alan Somers , "current@freebsd.org" Subject: Re: best approximation of getcpu() ? Date: Fri, 16 Dec 2016 13:27:21 -0800 Message-ID: <2302507.pYqCovi93S@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20161216021719.GA63374@onelab2.iet.unipi.it> <20161216194519.GA71398@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 16 Dec 2016 16:31:00 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 16 Dec 2016 21:31:01 -0000 On Friday, December 16, 2016 12:10:01 PM Adrian Chadd wrote: > On 16 December 2016 at 11:45, Luigi Rizzo wrote: > > On Fri, Dec 16, 2016 at 09:29:15AM +0000, David Chisnall wrote: > >> On 16 Dec 2016, at 03:10, Alan Somers wrote: > >> > > >> > What about pthread_setaffinity(3) and friends? You can use it to pin > >> > a thread to a single CPU, and know that it will never migrate. > >> > >> This is not a useable solution for anything that needs to live in a library and also doesn???t solve the problem. > >> > >> The Linux get_cpu call() is used for caches that are somewhere between global and thread-local. Accessing them still requires a lock, but it???s very likely to be uncontended (contention only happens when you???re context switched at exactly the wrong time, or if a thread is migrated between cores in between the get_cpu() call and usage) and so you can use the userspace fast path for the lock and not suffer from cache contention effects. > >> > >> One x86, you can use cpuid from userspace and get the current core ID. I have some code that does this and re-checks every few hundred accesses, storing the current CPU ID in a thread-local variable. Using the per-CPU caches is a lot faster than using the global cache (and reduces contention on the global cache). It would be great if we could have a syscall to do this on FreeBSD (it would be even better if we could have specify a TLS variable that the kernel automatically updates for the userspace thread when the scheduler migrates the thread between cores). > > > > indeed the following line seems to do the job for x86 > > asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp) : "a"(0xb) ); > > (there must be a better way to tell the compiler that eax, ebx, ecx, edx are > > all clobbered). > > > > 0xb is the CPUID function that returns the current APIC id for the > > core (not necessarily matching the OS core-id) > > > > The only problem is that this instruction is serialising and slow, > > seems to take some 70-100ns on several of my machines so you > > cannot afford to call it at all times but need the value cached > > somewhere. Exposing it as thread local storage, or a VDSO syscall, > > would be nicer because the kernel knows when it is actually changing > > value. > > The problem is your CPU ID can change in the middle of packet handling. > > So if you want it to be accurate, you need to bind your worker thread to a CPU. Well, it seems the goal is to have something much lighter weight akin to critical_enter/exit or sched_pin/unpin in the kernel. It's not that you care about a specific CPU, you just want to not migrate. (UMA uses critical sections when accessing the per-CPU buckets for the same reasons.) The problem with using cli/sti in userland is that you might page fault and context switch during the fault handler (or get preempted in the fault handler which will run with interrupts enabled) and migrate. You could prevent this if you are able to mlock() all of the pages holding any code you will execute or data you will access to prevent faults, but you have to ensure you can do this for every potential page. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Dec 16 21:31:03 2016 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 7FE82C832BA for ; Fri, 16 Dec 2016 21:31:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E37614D0 for ; Fri, 16 Dec 2016 21:31:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8637310AA5E; Fri, 16 Dec 2016 16:31:01 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Adrian Chadd , Slawa Olhovchenkov , Konstantin Belousov Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Date: Fri, 16 Dec 2016 13:20:55 -0800 Message-ID: <1995191.rPAPaoHxgb@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20161214102711.GF94325@kib.kiev.ua> <20161215224500.GM98176@zxy.spb.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 16 Dec 2016 16:31:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 16 Dec 2016 21:31:03 -0000 On Thursday, December 15, 2016 03:57:58 PM Adrian Chadd wrote: > heh, an updated BIOS that solves the problem will solve the problem. :) > > I think you have enough information to provide to supermicro. Ie, > "SMAP says X, when physical memory pages at addresses X are accessed, > they don't behave like memory, maybe something is wrong". > > All I can think of is some hack to add a blacklist for that region so > you can boot the unit. But it makes me wonder what else is going on. We have the blacklist: it is the memory test. That is the way to workaround this type of BIOS breakage. This is just the first time in over a decade that test has been relevant. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Dec 16 22:52:42 2016 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 4A863C83792 for ; Fri, 16 Dec 2016 22:52:42 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cdptpa-oedge", Issuer "cdptpa-oedge" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E31962F for ; Fri, 16 Dec 2016 22:52:41 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from [76.181.114.47] ([76.181.114.47:43354] helo=raspberrypi.bildanet.com) by cdptpa-omsmta01 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 02/56-30010-63074585; Fri, 16 Dec 2016 22:52:38 +0000 Received: from [192.168.1.40] (helo=desktop.example.org) by raspberrypi.bildanet.com with esmtp (Exim 4.84) (envelope-from ) id 1cI1Mk-0003zW-Ai for freebsd-current@freebsd.org; Fri, 16 Dec 2016 17:52:38 -0500 Subject: Re: Help To: freebsd-current@freebsd.org References: From: scrat Message-ID: <610a23f4-e62b-0b9a-9997-803125001e0f@columbus.rr.com> Date: Fri, 16 Dec 2016 17:52:38 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.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: Fri, 16 Dec 2016 22:52:42 -0000 On 12/12/16 23:08, Lewis ingraham wrote: > Hi FreeBSD Current Team, I need help with a few things: > > > 1. I tried getting help from all kinds of irc chats but still no dice. > 2. I cannot get my soundcard to work on FreeBSD. It is the Soundblaster > Z(SB1500, SB1502) with the CA0132 codec. > > I really LOVE FreeBSD i use it for workstation applications and > professional use as well. Is there any way i could be referred to someone > to can code the drivers needed to work with my hardware?? And possibly > someone who could help me with my software problems. https://www.freebsd.org/releases/11.0R/hardware.html#sound Looks like it is not supported From owner-freebsd-current@freebsd.org Fri Dec 16 23:19:13 2016 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 48577C83FB7 for ; Fri, 16 Dec 2016 23:19:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25FDD18AB; Fri, 16 Dec 2016 23:19:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id ADCF010AA2B; Fri, 16 Dec 2016 18:19:11 -0500 (EST) From: John Baldwin To: Mark Johnston Cc: kargl@uw.edu, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Date: Fri, 16 Dec 2016 15:19:09 -0800 Message-ID: <1848178.kLUBJlL36D@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214234804.GA26443@troutmask.apl.washington.edu> <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 16 Dec 2016 18:19:11 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 16 Dec 2016 23:19:13 -0000 On Wednesday, December 14, 2016 04:50:21 PM Mark Johnston wrote: > On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote: > > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > > > Well, after 3 days of bisection, I finally found the commit > > > > > that renders my system unbootable. The system does not panic. > > > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > > > so can't break into debugger. No serial console available. > > > > > The verbose dmesg.boot for a working kernel from revision > > > > > 309656 is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > > > > > The kernel config file is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > > > can create a boat anchor by upgrading to 309657. If compiling > > > > > a kernel with 'options DDB' is no longer supported, this should > > > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > > > to the right thing and pull in whatever 'option STACK' does. > > > > > > > > It is supported though - the point of that change was to fix a problem > > > > that occurred when DDB is configured but STACK isn't. While testing I > > > > tried every combination of the two options, and I just tried and > > > > successfully booted a kernel with DDB and !STACK. > > > > > > > > Does the kernel boot successfully if STACK is added to your > > > > configuration? > > > > > > I tried your config (plus virtio drivers) and was able to reproduce the > > > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > > > my change to re-add dead code into the kernel. My VM was always hanging > > > after printing > > > > > > 000.000050 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 > > > > > > Sure enough, removing "device netmap" from your config also fixes the > > > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > > > we're stuck in DELAY(), but I can't get a stack at that point. I think > > > my change is an innocent bystander - it just happened to expose a latent > > > issue elsewhere. > > > > > > I don't have much more time to look at this right now, but I'll look > > > into it more tonight. > > > > Yes, adding STACK got me to a booting kernel. I can't remember > > why I added netmap to my config file. Re-adding dead code seems to > > point to some memory corruption issue or a rogue pointer. :( > > It's not quite that bad, as it turns out. The key is that > adding/removing the dead code changes the ordering of the items in the > sysinit linker set. I discovered that if the ctl(4) module is > initialized before the vtnet driver attaches, the hang occurs, and > reverting my commit results in a sysinit order where vtnet comes > _before_ ctl(4). So my change triggers the problem just because it > happens to perturb something in the compile-time linker. > > > > > BTW, I think it would be prudent to add something like > > > > 20161206: > > At revision 309657, 'options STACK' was introduced into > > sys/x86/x86/mstack_machdep.c. Old kernel configuration files > > that included 'options DDB' are now required to include also > > 'options STACK'. > > > > to UPDATING or some such wording. I was jumping from circ Oct 10th world > > to top of tree, and got caught by ~3000 commits. > > The issue actually seems to be in 4BSD, and more specifically in r308564 > and r308565. Switching to ULE or reverting either of those two commits > fixes the hang. Here's what happens: > > 1. ctl_init() runs and creates ctl_thresh_thread. This thread's main > loop cause pause(9) when it has no work to do. During boot, pause(9) > just calls DELAY() and does not yield the CPU. > 2. thread0 attaches the vtnet driver. As part of this, it creates and > starts some high-priority taskqueue threads in > _taskqueue_thread_start(). They're added to the scheduler with: > > thread_lock(); > sched_pri(...); > sched_add(...); > thread_unlock(); > > 4BSD's sched_add() will call maybe_preempt() in this case, which as > of r308564 will unconditionally set td_owepreempt in the current > thread. > 3. thread_unlock() will release the critical section held by the current > thread and because td_owepreempt is set, we'll yield the CPU. The > taskqueue threads have nothing to do, but ctl_thresh_thread runs > and ends up busy-waiting in pause() forever. > > r308565 removes a check in maybe_preempt() that would have stopped > td_owepreempt from being set. Before r308564, maybe_preempt() would have > switched directly to the new thread and apparently always switched back > immediately. > > I'm not sure what the correct fix is - jhb might have an idea. I wonder > if pause() should try to yield periodically when called during boot. So the hack in pause() is probably not as necessary now. In particular, I think we only need it for thread0, not for other threads. The patch below worked for me with SPEW's config: Index: kern_synch.c =================================================================== --- kern_synch.c (revision 310128) +++ kern_synch.c (working copy) @@ -321,7 +321,8 @@ pause_sbt(const char *wmesg, sbintime_t sbt, sbint if (sbt == 0) sbt = tick_sbt; - if (cold || kdb_active || SCHEDULER_STOPPED()) { + if ((cold && curthread == &thread0) || kdb_active || + SCHEDULER_STOPPED()) { /* * We delay one second at a time to avoid overflowing the * system specific DELAY() function(s): -- John Baldwin From owner-freebsd-current@freebsd.org Fri Dec 16 23:27:03 2016 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 97644C832C4 for ; Fri, 16 Dec 2016 23:27:03 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B77B1E47; Fri, 16 Dec 2016 23:27:03 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id uBGNQt9j014585 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Dec 2016 15:26:55 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id uBGNQtSM014584; Fri, 16 Dec 2016 15:26:55 -0800 (PST) (envelope-from kargl) Date: Fri, 16 Dec 2016 15:26:55 -0800 From: "Steven G. Kargl" To: John Baldwin Cc: Mark Johnston , kargl@uw.edu, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: Revision 309657 to stack_machdep.c renders unbootable system Message-ID: <20161216232655.GA12842@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20161214194848.GA881@troutmask.apl.washington.edu> <20161214234804.GA26443@troutmask.apl.washington.edu> <20161215005012.GA84222@wkstn-mjohnston.west.isilon.com> <1848178.kLUBJlL36D@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1848178.kLUBJlL36D@ralph.baldwin.cx> User-Agent: Mutt/1.7.2 (2016-11-26) X-Mailman-Approved-At: Sat, 17 Dec 2016 00:02:21 +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, 16 Dec 2016 23:27:03 -0000 On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote: > > So the hack in pause() is probably not as necessary now. In particular, I > think we only need it for thread0, not for other threads. The patch below > worked for me with SPEW's config: > > Index: kern_synch.c > =================================================================== > --- kern_synch.c (revision 310128) > +++ kern_synch.c (working copy) > @@ -321,7 +321,8 @@ pause_sbt(const char *wmesg, sbintime_t sbt, sbint > if (sbt == 0) > sbt = tick_sbt; > > - if (cold || kdb_active || SCHEDULER_STOPPED()) { > + if ((cold && curthread == &thread0) || kdb_active || > + SCHEDULER_STOPPED()) { > /* > * We delay one second at a time to avoid overflowing the > * system specific DELAY() function(s): > I'll give your patch a try on Monday. I'm heading out the door for the weekend, and the system that has problems sits in my office. System is currently rebuilding firefox-50, which seems to have a penchant for becoming wedged. An unkillable program consuming ~1 GB of memory. :( -- Steve http://troutmask.apl.washington.edu/~kargl/ 2. https://www.youtube.com/watch?v=Py6d6o2jbaE 1. https://www.youtube.com/watch?v=6hwgPfCcpyQ From owner-freebsd-current@freebsd.org Sat Dec 17 03:34:19 2016 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 9BD23C8405B for ; Sat, 17 Dec 2016 03:34:19 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0075.outbound.protection.outlook.com [104.47.38.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 209BC1551 for ; Sat, 17 Dec 2016 03:34:18 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ySmBjMj8olaABYv+VYjkJXjvZ7VOcoxc+Yimt9gDsYg=; b=YkJfUaicQNV/Df46ahAHZsaqYpV5kFrEEwdnG/XzCUiqO148lt3wfgGi4NjECw7zLi2iGSpoRcOdugX6KLJx9g602jgkcuV9OgldQFHuSya12ymNxEMRp2R32fnrnX14peBimzj5hp2ZUlM7s0sVMeq63BHlNPiW/uATY9eGKXE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=kevans91@ksu.edu; Received: from mail-wm0-f49.google.com (74.125.82.49) by BN3PR0501MB1315.namprd05.prod.outlook.com (10.160.183.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.13; Sat, 17 Dec 2016 03:00:58 +0000 Received: by mail-wm0-f49.google.com with SMTP id c184so17853411wmd.0 for ; Fri, 16 Dec 2016 19:00:58 -0800 (PST) X-Gm-Message-State: AIkVDXLQaK3M6Im4HgkTvmSFSEwKhREpvjBfCOthhUy3VZAVXAVOmIx9PYEqngIAn9yB06N+kBUpKohwzPHhnQ== X-Received: by 10.28.133.144 with SMTP id h138mr5809132wmd.12.1481943639372; Fri, 16 Dec 2016 19:00:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.44.8 with HTTP; Fri, 16 Dec 2016 19:00:18 -0800 (PST) From: Kyle Evans Date: Fri, 16 Dec 2016 21:00:18 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: vt(4) odd scrolling behavior To: Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [74.125.82.49] X-ClientProxiedBy: VI1PR06CA0072.eurprd06.prod.outlook.com (10.163.160.40) To BN3PR0501MB1315.namprd05.prod.outlook.com (10.160.183.16) X-MS-Office365-Filtering-Correlation-Id: d46a66a7-bf05-461b-0e06-08d42628ed5c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1315; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1315; 3:3dpRpaSXWU9MsTaWXs3t5ZijA+dC8x7l3weIYVs0RR/8GH4uNwDPbAyoqRtA6TdIb58jVOVgvCxrxel4vF0LMoPwSf0Zv5wa4q8+r8blDY5h6Pk4nHwGJGiajI+QOv7vQla6DPfVoJp9i3hvVAYN0Hy3jcpXg6L4RdvL50jxDYtVnyIBnjPBoCjJScQGukKbjWy2OV74GmVEjVPwJ1mbRA69Rm0fYMHfjgWTUhWZLQNMVl4S9LlJDzUdQWeM6AlLIWb1RgDnTUvCrYFyM8UlYg==; 25:sQ8fJBeEO5TS88gximuManusKLHH6rqDzECpcnRHEM+LeJtupblhFDXaabQjukKzDeLTCY8b6dSleuIyvNGAEEa0YO3/Zajch+wlu4GNFzQcmvldO7c4/pJ2B/35Lu6K+5MoZ7wELabeGrFYDOv3l3Vmi4nv3YVdXNcDVzDcKzh2EFScCykO6DMaczjRD428qCjoopRWdyUvmRO/ETN5vZ20gWRcRiohJYxqK+YDuQvIkdU7cj1oN9QG/jnKcnr40s2+76Hn1q8kd/8mj0XetBWxQTckuMcJrbtRTOvO5ulEXq3uHTld8N5VWdfh8er8S27YVvj78o1leQwfncAmknjoQcxnhuW6vST21/FO9cywM/4ujnti0GxyDA9xt2u3XCH1q4H5YWrFhofApkdUQYsKZqPCKfecjqaYjy3Hj6By+IUJdzkJ/+mSPDwNjSAY46KJFVu45yjUnjzP/8sZMA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1315; 31:VqB8qx/dUDR89Sa6KgoIV/Li+NOnskm0kNmDmQoK9sCi4un0ATDvEidJ+swyi+F6vTbMo38PjWk7fiFgrFM5LSxGaQN76uieZEqO63X1e1pl0u86M38UsapF/EJV7ZTBpjHWWEaPFp8odDO4zAV1u0cBaHEtVpmCu91UCIm9BGLYYro2apfEL8te/HakZtBFrdg40YF8JIyXls8rc5GpYtiszU//TSL3VaqJ0xhIv/hmhGCOSo4ulIlcsPOWJn9zbWeI/7KikmrdqErfsA7ybVZ29wpmLIA1CRKXBC+ZJ4M=; 20:xcsO56lHltNVDhehN2ZdYpPIfZ1GhcXqWJxRna2Q9wMeVlXz5Nw0SFgVn4Mli3TYiPbq/eBFHcgElEg/DkSUovVQdmUHuFlMnSWF6oT6jcR/QHODVZFwXMijKTmXqdtoJ0AYuG9lOlEo+jQj3RNzApbDUA4JOcynii3xqCPLrctr0eMl38yBgarTlE5ZdPjFzFc/DjUldRiVjg5a6PDySZVnu0WS3rOIfK0eQm4x7HLoNP6oqGriVjH7YEtyoZb/Xuvg1GCICN+7DFgTGGffT/+hU8CpHb/JJFJOcDbt25NP85aQ4YXeX4AET4c30BKAynUSiENY+Gv7GHuIksnmcsRg7oPiDO3+WoWJKIir9PVMwr8ymiUCvY7+oC/jfJguPXVnrZIX5YDXUDxC2JLap9m2Q5BRLldx+aHP57V1KYanMqvmPZAbNkXU6XMUoXYOuofkeNanXJK0bZ490l0Vbp96yTPuzXHSQVXlIkTUcwE0VeMkE7jusgjdN8g19jTx X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1315; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1315; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1315; 4:CM3f4ZgAfbW9B90XGpdLQbXT/FoqLojPQ9Bl+icbdjeupYCJJhlg+upukmdgJPAiZwM3rpgGsTgSpeo4zdfUCc+r1dYmgZ9Ib7ZQFoMqZnwsJCVodtsYITdo8diaznf/WYSYXKsBl1F9kAqJT1yaEHQlXbwtHVoqcnjkY9rgu6vKiHDzgFmhODHiR/7DUgfK+m6iuu3lInZSciQzfFJupf6OVRl8lk8/6YdGlTMYeDokLrJXPkPNnsYsg7kvAm8Z6tfRyCXFlNckScXHDqrDYO4ezFUU1OhsmskJNcD8Tg7GSH4oJMH21+enQeEKVShgZ+lKvfWEeRceGHeYzXa5RtC1wR93XrWxkRtBGGCxIvBqyE22mlDEG/KMiWV8BnrkwAXpOjoHvZMO2iZidaM113wgCRNU06CkIlPktOz+M0QtDsgEPluzKe7VL7p3Roz4xklFtOOoNYgGhnzMSKNeqvXw//+LLumBTzZJPpaKOMl34AjaXHZB2lXMgDwWfz2tBcBb+kUKNYMThYQTq7YPXjDvbYb3SRhPe0a3rtdNVwdyFC2r2mjATUkP/i7Ui9U/QqeSlSWgMFESxLbr9b/ZcUbTFAmF9yhSh8Ph6xIQDLY= X-Forefront-PRVS: 0159AC2B97 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(39450400003)(189002)(199003)(50466002)(47776003)(2351001)(8676002)(9896002)(450100001)(90282001)(42186005)(5820100001)(23676002)(105586002)(122856001)(81166006)(7736002)(498394004)(88552002)(2906002)(305945005)(3846002)(69596002)(81156014)(6116002)(68736007)(9686002)(6916009)(93516999)(101416001)(98316002)(92566002)(106356001)(55446002)(54356999)(38730400001)(63696999)(61726006)(189998001)(50986999)(97736004)(75432002)(110136003)(89122001)(5660300001)(107886002)(86362001)(61266001)(66066001)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0501MB1315; H:mail-wm0-f49.google.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ksu.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzMTU7MjM6OWhGY1RmNHVSY3IvbHcraFFYV0ZzSm94?= =?utf-8?B?YVNjQjZDaGJSRVBRZmJqZ2cyRHlzNWV6VGhFekxTYlNESnI3b0Yzb1JyOSsr?= =?utf-8?B?ak5OS29oNFBVSk5tNWU4eEpWVitWR3JXcHlBZFhnQzBmWWtjaXdPbHJqdEZR?= =?utf-8?B?c1Zhcm5FMEpTWFJwV0c3MmN4ZlR0TlBrY0FhNnVHcC9RUXYxTzRNdFYvZ1BO?= =?utf-8?B?M09jUEIxVnhaNG1qL1FKaGh4cCtteEpibkN4NVNtd2hnRzI2b01OWHkzUDM5?= =?utf-8?B?UmdOVlZPbWJJb1NQUm1ab3pucGhnT1VTMkZkMXJ3bDBCMU91S0Z5T3htazRY?= =?utf-8?B?SWdhS1lOd3dLTVpFQ2JoYjVFK3B0eDJGL1FjajhNT1VPRG9NV21rdW5IaTV4?= =?utf-8?B?SmpreUhDN2krM2ZzQkwzQ3RwaE1HQ3NuWFJkRHFYSWVTLy95TkZLNjg5ZW93?= =?utf-8?B?VlZQdHF2d1BibUVRQXlUQ2JtWXhTMVVTNUxzY3J3NjNOaTFkdzdCazlibFgy?= =?utf-8?B?U09oT3g3Nk4zUHVGVmJnT2pFREdoQ21vYjFIZEcvUm5saWEva0RHTTRCMHdz?= =?utf-8?B?WVduNUFQME0xemwyS2w4VE1va1cxdktNTERBcUhjSExXU2g1T3owVXBNUzZp?= =?utf-8?B?NGRISEtjdzJGQlEybElyMEtwM3Z4eWR3R1FBWkcyNWYxTitVRFZyQkU4S1pr?= =?utf-8?B?QkhHeVNTQWRpYnhyTjBNbTluTlZ3Nkh1ZlJwU2NCem90cXNxTDZVZFA1ZkFS?= =?utf-8?B?MGwxL3lRdG5KQUhRTWVIVW4vOE9ZSWxyWndDdzVhMHJXZ0hyRENoZlNFU09t?= =?utf-8?B?Wk8xMU5kRzJNbDJmWXUzZWJ5OEs0aklTVm9DVGdBaFVKZU1TeEI4VjZtQm4y?= =?utf-8?B?VEpoU0Vja0pMUi9jSUh2QzZPSEJ4aTJoeC9LSkdmbVZsS0xoc2h5MXhMbmRD?= =?utf-8?B?SlVobDNJL0tJdStUak5xVkVvMnJJSVRsdGt5WmtRbWV2T1JxWFpqY0NKK0Nr?= =?utf-8?B?cmpVZ0craU4zc0hXeUV2TzNYQXNrZzRJY0drQTRUMGl4VzBxcnh2WXdUWlEy?= =?utf-8?B?N3UyNytkYU1WM1JKQkRvWlh2ZlBtY2pDUkROZ1hDbk9YMVVQQ2VMeTk2VkdE?= =?utf-8?B?N0xXYWRVM2dlUVJtdGw1QlZvR1d5QjdxZVpxdHZMQWtZdm9jOVBPN29sS2VS?= =?utf-8?B?YW4ydklIS3VzV2NpTEQrdHEvbElBVXRmanhUMCtmWGw5YlIzL0oyVEppRkJa?= =?utf-8?B?MmhWbDgwOUt3alZhZzZuODk5WS8rS0pVa0djaHhpZEJoMWZVY090bFd2d3Vt?= =?utf-8?B?ZHdwUGJURW5zMHRpc0ZVSkRRdjFEVzliS2dOMm16SWlVWVV3Z0lDNHlUb1p2?= =?utf-8?B?ckZzWmVhU05qeGkyd2htb0RnTWxEdVhCNTFqR3NsQlA0S290dUYzUVNxUm5Y?= =?utf-8?B?TFdraHhlL0J2a1MweDBJM2tlZFFveEtER0l6N1k4VElhL1JCN0NHUkttdU1S?= =?utf-8?B?eDVMVzdNaHRkOUgvdGpWbzBJa0JON3FWN1J2Y1BmYjMvcVRGYzFNZit2V2Vv?= =?utf-8?B?N1RUa2dUUXl5SUxqNHZsRXd3TVpTc1ppc3d6bXZmNitMS29iRFAwVVFSUTk3?= =?utf-8?B?aGpDa29LV01Bdzk2Z01aMnZIWjJuMHJldkNyengzL2s4ZW5ieEg0NFNCaThv?= =?utf-8?Q?WjvES+XUgGHQeZA5Kz5sL7C5U1Wbd4AwuXT0NUEdi?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1315; 6:h/k1qIY8op8rJ147e//LLHAuL6Dqoh3LWSMQvhKisbPYyUSkOmUMQwPevCFoGr1aDiaWuSnOy5nrLwM98KqaU5M2ZIRR753QkDLfU4R8lhxe2i4vf7K9jeiNzNL1Rc+Q8DU3QsxWv+R5lDRta/BEtw9LZ37jZ4xWlsQXfDPDn1qxygg9SlHhWRv64fc4oHdMTgv6aoSjoQ9dkqf6fkqDsIdfY5sByc3+IUqU+9znbjlgiXqWvy5xQ5eO6FmselC7lXuvGpicznuzcAzbOFqe2S0Re9uvXzTrWiuJX4SQs3pUVwNAAziP7g+Z8OBfLiyIp14bKuKhk3jsRsNuGRsjGNdpYAIahsAgLDl0Y+OgsQtRB6dG6sGotsBrBBCLhkHb8sM//yTFpdce7YNJ26SXlH6ByVYVSNPysw96NZgVgbc=; 5:X44ZMZYVDG7ZnjOPzP9rDERJ9ylAq1yGMBDFXq1JvPjc1DZw0q9TGEfYsKtQsmV7SlQICRuyupztixSLPUMm45vHHZxR6vIra1Oc9o4JlBFi9b0mqF1stkFw8+dUHIFxo5h5hYin0yAWqVT584pUrw==; 24:gs6J6l0jf9Qa1/1z8+QRey0IMwV9DyKj0h2gusJCRE98bs2xtEQkHtQHo6mjLm/0DhlecurOB4NGq+PZjA693PQbF/tV9W8P6iv7FiP+B04= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1315; 7:S3Z8W3zUJjtnFJ1v9+KNrRN5c0KSE+Fbnt3STnG+yeJFE6UFg/D12vnNPh6/yMKSA6DjzXBrbMe194oWgEbxpBRkVumW0tgLapX2qyv8aragmeZnUgLT3iuV1SNtEgRk+GTfxLmmnYifn/7wcDOxkgKFyL3bvMppnlMIsMYHX9IaGUZUuAAn7ItOYoXGO9RGlJikjf4ixuBY7/H/RWRcHIiRZD1BxQfqnkPT+Y8ZMf/dSwFJ6DVla0JU7WiB/QMl0mt7DPbvwQBBLh5Q1U6Wi6mxAWny87mlNGb5bwP66yThhgHxvY5GeEZTwgzyJ+AU85/V0tfWhWGWaCWYK8EVi4Gm9MJIhSNXT0SLMj4LLPFYLUYxWoO2zUJWwHiJup2qwfol4tiaoz9/rygpt7H+K8qhFmRbv6QwSMl88FeZ95UcWDUGZZ7ROoo2Ztdkw3AWoGgD8S6jBBFu8oIp8kZTfQ==; 20:cC6ss28aI+lh7F9E9XS+TySA80yk3VPxfzTVJBzsQExQzpc0Iq3EvQwqWyXAItHcvgbQgOioCVrCJURHxWw+eCFBJf/9lz1YNkSM7wchiOmYCYbwF9igvN7zlC7hlhHlg0DlThMUJolsH7hrnv8/FI8YDbdUYhbwxIoDXbsMMYc= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2016 03:00:58.8852 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1315 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, 17 Dec 2016 03:34:19 -0000 Hello! I've had this odd behavior [1] on one of my machines with vt(4) misbehaving in graphics mode following the beastie loader's screen. Any ideas what might cause something like this, or if it's just something unsupported? I have a PR open at [2] with pciconf -lv output. Thanks, Kyle Evans [1] http://files.kyle-evans.net/vt_scrolling.mp4 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211876 From owner-freebsd-current@freebsd.org Sat Dec 17 07:34:49 2016 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 8EA61C84369 for ; Sat, 17 Dec 2016 07:34:49 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5943B1C59 for ; Sat, 17 Dec 2016 07:34:49 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id A4711273DA; Sat, 17 Dec 2016 07:34:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id uBH7YdXS084818; Sat, 17 Dec 2016 07:34:40 GMT (envelope-from phk@phk.freebsd.dk) To: Kyle Evans cc: freebsd-current@freebsd.org Subject: Re: vt(4) odd scrolling behavior In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84816.1481960079.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Dec 2016 07:34:39 +0000 Message-ID: <84817.1481960079@critter.freebsd.dk> 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, 17 Dec 2016 07:34:49 -0000 -------- In message , Kyle Evans writes: >I've had this odd behavior [1] on one of my machines with vt(4) >misbehaving in graphics mode following the beastie loader's screen. > >Any ideas what might cause something like this, = I've seen it too. I think beastie sets a scrolling region and doesn't clear it. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sat Dec 17 08:06:52 2016 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 8EFE9C81042 for ; Sat, 17 Dec 2016 08:06:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EB53D54 for ; Sat, 17 Dec 2016 08:06:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-230-194.lns20.per1.internode.on.net [121.45.230.194]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uBH86kJQ060345 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 17 Dec 2016 00:06:50 -0800 (PST) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: FreeBSD system profiling and tuning for 10, 11 and 12 Message-ID: Date: Sat, 17 Dec 2016 16:06:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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: Sat, 17 Dec 2016 08:06:52 -0000 Hi I'm looking for recent information regarding profiling and tuning in FreeBSD. Google has turned up some links but I think that the best leads are still hiding.. for example I only found https://wiki.freebsd.org/NetworkPerformanceTuning recently. (BTW Anyone who has a moment is encouraged to check if they have anything to add to it.) I am sure there is better information around for profiling the kernel and modules, but I am not seeing "the definitive profiler's guide" out there. I do know several people have blogs that cover this sort of thing. If you have one or know of good profiling resources we should gather them.. send them to me and I'll try make sure everything is up to date, and put them together in a wiki page. there is already some stuff there, (see https://wiki.freebsd.org/NetworkPerformanceTuning?action=fullsearch&context=180&value=profiling&fullsearch=Text ) but it could do with gathering together. Julian From owner-freebsd-current@freebsd.org Sat Dec 17 09:20:02 2016 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 DFA6AC811F5 for ; Sat, 17 Dec 2016 09:20:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 A3B2A125F; Sat, 17 Dec 2016 09:20:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cIB9m-000BMx-Fx; Sat, 17 Dec 2016 12:19:54 +0300 Date: Sat, 17 Dec 2016 12:19:54 +0300 From: Slawa Olhovchenkov To: Julian Elischer Cc: freebsd-current Subject: Re: FreeBSD system profiling and tuning for 10, 11 and 12 Message-ID: <20161217091954.GE90401@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 17 Dec 2016 09:20:03 -0000 On Sat, Dec 17, 2016 at 04:06:40PM +0800, Julian Elischer wrote: > Hi > > I'm looking for recent information regarding profiling and tuning in > FreeBSD. > > Google has turned up some links but I think that the best leads are > still hiding.. > for example I only found > https://wiki.freebsd.org/NetworkPerformanceTuning recently. > > (BTW Anyone who has a moment is encouraged to check if they have > anything to add to it.) === Ensure BPF is OFF. No tcpdump, cdpd, lldpd, dhcpd, dhcp-relay. Patches are coming. Check netstat -B. === Don't see any problem with tcpdump up to 40G. tcpdump used for capture selected stream. === On FreeBSD older than 11.0, use more compact ip_fastfoward routine. It processes most packets falling back to 'normal' forward routine for fragments, packets with options, etc. Can save you up to 20% speed (but will break IPSec). net.inet.ip.fastforwarding=1 === I am not found in 11/12 this sysctl/tunable. === Skip feeding /dev/random from network by adding harvest_mask="351" to /etc/rc.conf or theses line to /etc/sysctl.conf: kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 === On 11: # sysctl kern.random.sys.harvest sysctl: unknown oid 'kern.random.sys.harvest' > I am sure there is better information around for profiling the kernel > and modules, > but I am not seeing "the definitive profiler's guide" out there. I do > know several people > have blogs that cover this sort of thing. If you have one or know of good > profiling resources we should gather them.. send them to me and I'll > try make > sure everything is up to date, and put them together in a wiki page. > > there is already some stuff there, > (see > https://wiki.freebsd.org/NetworkPerformanceTuning?action=fullsearch&context=180&value=profiling&fullsearch=Text > ) > but it could do with gathering together. You might surprised, but various options in BIOS can gain up to 10-20%% every, 50% total. Also, be careful about using internal architectures detials. I am already overloaded: a) bandwidtch of DMI2 link b) bandwidtch of 8x PCIe3 Not all cores equals for IRQ handling and cost of PCIe access. From owner-freebsd-current@freebsd.org Sat Dec 17 09:44:14 2016 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 69DD6C81899 for ; Sat, 17 Dec 2016 09:44:14 +0000 (UTC) (envelope-from cochard@gmail.com) 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 24A501E07; Sat, 17 Dec 2016 09:44:14 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id w33so108010684qtc.3; Sat, 17 Dec 2016 01:44:14 -0800 (PST) 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; bh=vvDSV1gCqVFGSfyQ5rA5pbpqOIDRJSIsZosZBMM5xEg=; b=FubGZnLSyvuF/jvVx6YT4wNMn6tnWx7pckORXZu6NcNGWGmI6OsbZjjPfYxXsWXnKY r3cLh2qTaJ0Rb7Evic1ukXMxJje1mpW3c5jNdp616cpjhr6+J79g5qYKeZbIJXOxTP2W ef88O6nby99Ozi6Q3EHBa6Hxg+7nzPjhxvQiMupWpvwnaepuwk2mFCLUjIbB20Lpdnjq d0O0b70L8/SjC4b+bt9ScwE1ZVYQPl9DxD8+caSL/jZmqBOxtJqRQwzlpa4EZCOtzuQ3 o7kGXTR3eoMw+guHyX9T64aBJpz1407aMJxtDG+MFplckB5HrMglU0Ot6O2YkgCp/u9U /UBQ== 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; bh=vvDSV1gCqVFGSfyQ5rA5pbpqOIDRJSIsZosZBMM5xEg=; b=YCa6ZUcg6sYTrBSVDPROXn4RhuPBiT5Ff2HJsRyPoB2qLxI2m/RII3TaH2Cg7KU6Ve DFHx3I2jSY2W/dgt7b1dNS7dfl3E42F2Y8dc53hnk2VcrrehtGlHijOZ/Zu3OK+FnHOu Jyq+dgBj2hcYtTa6h0gUo+sQYvFWRO7pC53xwWaBiTrvT81zvWPTVfCl7p56Ufqnquf3 /G0s9f6/dAAPkmvq8vMk4qcnwq15O/t/ddQT9pDX+kArcGfw0RnqPOWl6F+LEUwUsizL y32rnN8AFFr7kwQKraKNZ7BSPhCZl38dAkxw5KTlZAN19tSpTrX72BVgbYZdZvLuZ0tL Q7Kg== X-Gm-Message-State: AIkVDXIVAP5tu5TpNCtRnq7bgAlpLgHHJN0fhNn1PS4uLXB5182EIZP2aMZEdQnoEQG31warZwVDDX1ogH53jA== X-Received: by 10.200.54.157 with SMTP id a29mr6678216qtc.172.1481967853335; Sat, 17 Dec 2016 01:44:13 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.237.34.248 with HTTP; Sat, 17 Dec 2016 01:43:52 -0800 (PST) In-Reply-To: <20161217091954.GE90401@zxy.spb.ru> References: <20161217091954.GE90401@zxy.spb.ru> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Sat, 17 Dec 2016 10:43:52 +0100 X-Google-Sender-Auth: wfqPiIQwg_7UGmmHr4h25dv_vQg Message-ID: Subject: Re: FreeBSD system profiling and tuning for 10, 11 and 12 To: Slawa Olhovchenkov Cc: Julian Elischer , 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, 17 Dec 2016 09:44:14 -0000 On Sat, Dec 17, 2016 at 10:19 AM, Slawa Olhovchenkov wrote= : > > =3D=3D=3D > On FreeBSD older than 11.0, use more compact ip_fastfoward routine. It > processes most packets falling back to 'normal' forward routine for > fragments, packets with options, etc. Can save you up to 20% speed > (but will break IPSec). > > net.inet.ip.fastforwarding=3D1 > =3D=3D=3D > > I am not found in 11/12 this sysctl/tunable. > =E2=80=8BYes, this sysctl is available "on FreeBSD =E2=80=8Bolder than 11.0= ". It's was improved, renamed tryforward, and it's the default method since 11.0. > =3D=3D=3D > Skip feeding /dev/random from network by adding harvest_mask=3D"351" to > /etc/rc.conf or theses line to /etc/sysctl.conf: > > kern.random.sys.harvest.ethernet=3D0 > kern.random.sys.harvest.point_to_point=3D0 > kern.random.sys.harvest.interrupt=3D0 > =3D=3D=3D > > On 11: > # sysctl kern.random.sys.harvest > sysctl: unknown oid 'kern.random.sys.harvest' > =E2=80=8BOops, I've updated the wiki here: thanks. From owner-freebsd-current@freebsd.org Sat Dec 17 09:51:44 2016 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 1DA12C81E9A for ; Sat, 17 Dec 2016 09:51:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 D4DCC836; Sat, 17 Dec 2016 09:51:43 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cIBeX-000CGA-QF; Sat, 17 Dec 2016 12:51:41 +0300 Date: Sat, 17 Dec 2016 12:51:41 +0300 From: Slawa Olhovchenkov To: Olivier =?utf-8?Q?Cochard-Labb=C3=A9?= Cc: Julian Elischer , freebsd-current Subject: Re: FreeBSD system profiling and tuning for 10, 11 and 12 Message-ID: <20161217095141.GO98176@zxy.spb.ru> References: <20161217091954.GE90401@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 17 Dec 2016 09:51:44 -0000 On Sat, Dec 17, 2016 at 10:43:52AM +0100, Olivier Cochard-Labbé wrote: > On Sat, Dec 17, 2016 at 10:19 AM, Slawa Olhovchenkov wrote: > > > > > === > > On FreeBSD older than 11.0, use more compact ip_fastfoward routine. It > > processes most packets falling back to 'normal' forward routine for > > fragments, packets with options, etc. Can save you up to 20% speed > > (but will break IPSec). > > > > net.inet.ip.fastforwarding=1 > > === > > > > I am not found in 11/12 this sysctl/tunable. > > > > ​Yes, this sysctl is available "on FreeBSD ​older than 11.0". It's was > improved, renamed tryforward, and it's the default method since 11.0. Sorry, missreading. From owner-freebsd-current@freebsd.org Sat Dec 17 11:46:49 2016 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 EB127C84D2B for ; Sat, 17 Dec 2016 11:46:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 521FF3C8 for ; Sat, 17 Dec 2016 11:46:48 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([78.52.132.125]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MKprU-1cIDRo2SyO-00022J for ; Sat, 17 Dec 2016 12:46:40 +0100 Date: Sat, 17 Dec 2016 12:46:34 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r310188: kernel build failure due to mlx4_ib_sysfs.c:90:22: error: format specifies type 'unsigned long long Message-ID: <20161217124634.131a97b4@thor.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/1WlrzIBAG0x/Pfw02ak73VF"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:ENtEWeYgga2nYthd9bPz7t37o7KutmoArIecOPvftbNKHdEBQ9k AR1/KRBPiqnhTHMIVr9iJY9b5Gps7Ul/Pel/guIhI3MXzAqK82KK/DMifBO5bK8xLlhFuZW aRSRSJgfj9Gq1qDMWkr7Oc3ItUUEXckjvpcIDgSjqZIccsOEOjgO8sj80lFuzaMWeFyPvAd uOwe+UowkpgLxI+C7+SaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:HPRB9KpSgHw=:ZVb5zWHDpb42cnDLDtKfFn pCHesPVN9+x91IP0mVl7RCtdJeaXaS+AE5nDVCjc76u6CJcsg27UTGJm22ujtyTql/clBT8CL wZYKIDNfIiSpyTkSvmFIA/HQBnA0OIjJvz4l014FKXkW62ItXkYwr3rgrlUGJtBwQy4hhp8y6 kG362z55aLNqbZyEZbjFIYSXItuERfY2BMIAmvJxulyHixDP/s5/BWSbYUPtOgb8XtVq5lp8Q kqhO1wA5yfT5kKKNUj/t5cPbQbB5HLKPOJY0ICZXV56ehks/Jz8ynUawDwy/qUfbXSV7yodT6 CKQfj4wK0uwjLxxd2h2U2nkoEVT82rYP36NZmAgPmfUU37/ZSGLLRl1CXFV/mjnhSH0SjkmZL YDf63myT0gQwg7UoAl23YMj9wx8vcIl6+opUzOY06tqLL+zTDIvEj8zxmHlcwWhtSz+dxoPNp 2XJ0LtwVrnnfXAtjpDGn3riGf5sX6YVVni/XxIhiHKqf6RNBbf8Y1EXxvFzj1MR1z8+Ur532q QxOSBJUHpBmyE6GnwA1Ij4zJP7aC9h2iFhEJayX6kyvgMOrPvIeNfh35hzMit5t/oGGaJ4Qx7 FydtPFKq3M3Hr+oLZnXofPwhnUaNXsUjIy92+pk10vD3r/9SkEUKMteHycoa8Rgfr3HFZtd4H TM8e1U9hTrL5nz4Ae+Iz/0vs9+q868YtXHTM7H8sZy6U55vE2ipegr9o+OkAFS69iJgSF3gCt pcs1b4up+gFSYREIQiJfmKMhz7jPpYsBdAAKKmbOKev0G69lBzH05Wulae8= 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, 17 Dec 2016 11:46:50 -0000 --Sig_/1WlrzIBAG0x/Pfw02ak73VF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Recent kernel source reject to build: [...] --- all_subdir_mlx4ib --- --- mlx4_ib_sysfs.o --- /usr/src/sys/modules/mlx4ib/../../dev/mlx4/mlx4_ib/mlx4_ib_sysfs.c:90:22: e= rror: format specifies type 'unsigned long long *' but the argument has type 'u64 *' (ak= a 'unsigned long *') [-Werror,-Wformat] sscanf(buf, "%llx", &sysadmin_ag_val); ~~~~ ^= ~~~~~~~~~~~~~~~ %lx 1 error generated. *** [mlx4_ib_sysfs.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/mlx4ib --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/1WlrzIBAG0x/Pfw02ak73VF Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWFUlmgAKCRDS528fyFhY lJ+PAf9Xl+QtV7cGKJRC4paFe4c4VcpLEJ6Nj13ZVP9tFeGUcZk++hLnycAeHNsi mIaMYjnxuzJTcn//8JxwhIPh+1xDAf9dlzia/ImVc/Q/+o1+UQpzn72V7++qwl4b 06hQAk58p9gr6BThn4ftzMoGlro44nXRX67DPMHHaPO85yXGrW3Z =/89V -----END PGP SIGNATURE----- --Sig_/1WlrzIBAG0x/Pfw02ak73VF-- From owner-freebsd-current@freebsd.org Sat Dec 17 10:55:26 2016 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 1C13FC83EDB for ; Sat, 17 Dec 2016 10:55:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id F16DD7F7; Sat, 17 Dec 2016 10:55:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E3D8D31F; Sat, 17 Dec 2016 10:55:25 +0000 (UTC) Date: Sat, 17 Dec 2016 10:55:25 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: lifanov@FreeBSD.org, cperciva@FreeBSD.org, manu@FreeBSD.org, ngie@FreeBSD.org, kib@FreeBSD.org, gnn@FreeBSD.org, matthew@FreeBSD.org, asomers@FreeBSD.org, jmcneill@FreeBSD.org, mm@FreeBSD.org, jhb@FreeBSD.org, dim@FreeBSD.org, gonzo@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <253721999.104.1481972125952.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <573376856.102.1481890114888.JavaMail.jenkins@jenkins-9.freebsd.org> References: <573376856.102.1481890114888.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1735 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Sat, 17 Dec 2016 12:25:15 +0000 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 10:55:26 -0000 FreeBSD_HEAD_amd64_gcc - Build #1735 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1= 735/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/173= 5/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1735= /console Change summaries: 310187 by ngie: Remove lib/libelf's manpages if MK_TOOLCHAIN =3D=3D no Add a comment to help figure out which set is lib/libelf's and which set is lib/libelftc's MFC after:=091 week 310186 by ngie: Install the lib/libelftc manpages Some other manpages, e.g. c++filt reference these MFC after:=091 week 310185 by mm: MFV r310115,310184: Sync libarchive with vendor. Vendor bugfixes (relevant to FreeBSD): PR 830, 831, 833: Spelling fixes OSS-Fuzz 227, 230, 239: Fix possible memory leak in archive_read_free() OSS-Fuzz 237: Fix heap buffer overflow when reading invalid ar archives MFC after:=091 week 310182 by kib: In swp_pager_meta_free_all(), fix type of the index variable. Style. Noted and reviewed by:=09alc (previous version) Sponsored by:=09The FreeBSD Foundation MFC after:=091 week 310181 by matthew: Revert r309339, thus re-instating r309314 The original problem with conflicting definitions of ${PKG_CMD} was solved by r427523 in ports (see https://reviews.freebsd.org/D8677), so this should be safe now. Reviewed by:=09gjb Approved by:=09gjb Differential Revision:=09https://reviews.freebsd.org/D8120 310180 by asomers: Fix panic during lagg destruction with simultaneous status check If you run "ifconfig lagg0 destroy" and "ifconfig lagg0" at the same time a page fault may result. The first process will destroy ifp->if_lagg in lagg_clone_destroy (called by if_clone_destroy). Then the second process will observe that ifp->if_lagg is NULL at the top of lagg_port_ioctl and goto fallback: where it will promptly dereference ifp->if_lagg anyway. The solution is to repeat the NULL check for ifp->if_lagg MFC after:=094 weeks Sponsored by:=09Spectra Logic Corp Differential Revision:=09https://reviews.freebsd.org/D8512 310179 by cperciva: Avoid division by zero in the rare case that portsnap needs to fetch zero patches. (This avoids two "dc: divide by zero" warnings.) MFC after:=093 days 310178 by manu: Honor the CLK_SET_DRYRUN for the *set_freq function for allwinner clocks. Reviewed by:=09jmcneill MFC after:=091 month Differential Revision:=09https://reviews.freebsd.org/D8821 310177 by jhb: Enable EARLY_AP_STARTUP on amd64 and i386 kernels by default. PR:=09=09199321, 203682 MFC after:=092 months Sponsored by:=09Netflix 310175 by gnn: Remove extra DOF_SEC_XLIMPORT from the DOF_SEC_ISLOADABLE macro MFC after:=092 weeks Sponsored by:=09DARPA, AFRL 310172 by jmcneill: Add support for Ingenic JZ4780 SMBus controller. Reviewed by:=09=09kan Relnotes:=09=09yes Differential Revision:=09https://reviews.freebsd.org/D8793 310171 by dim: Add __scanflike attributes to the kernel's sscanf() and vsscanf() declarations. This should help to catch future mismatches between format strings and arguments. MFC after:=091 week 310170 by gonzo: [spigen] Make "data" part of spigen_transfer optional Make st_data part of spigen_transfer optional by letting pass zero length and NULL pointer. SPI controller drivers handle this case fine. MFC after:=091 week 310160 by lifanov: retain cc.4.gz man page for Chelsio T6 NICs This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 With reintroduction of cc.4 "make installworld; make delete-old" was no longer convergent. Reported by:=09Trond Endrest=C3=B8l Reviewed by:=09np, matthew Approved by:=09np, matthew (mentor) Differential Revision:=09https://reviews.freebsd.org/D8816 310159 by kib: Switch from stdatomic.h to atomic.h for kernel. Apparently stdatomic.h implementation for gcc 4.2 on sparc64 does not work properly. This effectively reverts r251803. Reported and tested by:=09lidl Discussed with:=09ed Sponsored by:=09The FreeBSD Foundation MFC after:=091 week 310155 by kib: Fix typo. MFC after:=093 days The end of the build log: [...truncated 53 lines...] U sys/vm/swap_pager.c U sys/net/if_lagg.c U sys/arm/allwinner/clk/aw_debeclk.c U sys/arm/allwinner/clk/aw_hdmiclk.c U sys/arm/allwinner/clk/aw_lcdclk.c U sys/arm/allwinner/clk/aw_mmcclk.c U sys/arm/allwinner/clk/aw_modclk.c U sys/arm/allwinner/clk/aw_pll.c U sys/arm/allwinner/clk/aw_thsclk.c U sys/amd64/conf/GENERIC U sys/amd64/conf/MINIMAL U sys/i386/conf/GENERIC U sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h U sys/mips/conf/JZ4780 U sys/mips/ingenic/files.jz4780 AU sys/mips/ingenic/jz4780_smb.c AU sys/mips/ingenic/jz4780_smb.h U sys/sys/systm.h U sys/dev/spibus/spigen.c U sys/kern/kern_event.c U Makefile.inc1 U release/scripts/make-pkg-package.sh U share/mk/bsd.own.mk U usr.sbin/portsnap/portsnap/portsnap.sh U ObsoleteFiles.inc U libexec/rtld-elf/rtld.c At revision 310188 No emails were triggered. [FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson2758775147218540760.sh + cat + svn revert Makefile.inc1 + svn revert sys/boot/i386/Makefile Reverted 'sys/boot/i386/Makefile' + patch -f Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/boot/i386/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 |--- sys/boot/i386/Makefile=09(revision 280912) |+++ sys/boot/i386/Makefile=09(working copy) -------------------------- Patching file sys/boot/i386/Makefile using Plan A... Hunk #1 succeeded at 16 (offset 4 lines). Hmm... Ignoring the trailing garbage. done + /vm/freebsd-ci/scripts/build/cross-build.sh + [ -z /builds/FreeBSD_HEAD_amd64_gcc ] + [ -z amd64 ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD_amd64_gcc/obj + mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj + echo -e 'NO_WERROR=3Dyes WERROR=3D WITH_FAST_DEPEND=3Dyes' + cat + set +x -------------------------------------------------------------- >>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains: + cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf # Put make.conf entries here NO_WERROR=3Dyes WERROR=3D WITH_FAST_DEPEND=3Dyes + set +x -------------------------------------------------------------- + sudo pkg upgrade -y Updating FreeBSD repository catalogue... Fetching meta.txz: . done Fetching packagesite.txz: .......... done Processing entries: .......... done FreeBSD repository update completed. 25735 packages processed. Checking for upgrades (26 candidates): .......... done Processing candidates (26 candidates): ........ done The following 19 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: =09zsh: 5.2_4 -> 5.3 =09rsync: 3.1.2_5 -> 3.1.2_6 =09py27-docutils: 0.12_1 -> 0.13.1 =09py27-botocore: 1.4.82 -> 1.4.86 =09pinentry-tty: 0.9.7 -> 1.0.0 =09pinentry: 0.9.7_1 -> 1.0.0 =09php56-xml: 5.6.28 -> 5.6.29 =09php56-simplexml: 5.6.28 -> 5.6.29 =09php56-mbstring: 5.6.28 -> 5.6.29 =09php56-json: 5.6.28 -> 5.6.29 =09php56-dom: 5.6.28 -> 5.6.29 =09php56-curl: 5.6.28 -> 5.6.29 =09php56: 5.6.28 -> 5.6.29 =09mutt: 1.7.1_2 -> 1.7.2 =09jenkins: 2.35 -> 2.36 =09harfbuzz: 1.3.3_1 -> 1.3.4 =09gsfonts: 8.11_7 -> 8.11_8 =09curl: 7.51.0_2 -> 7.51.0_3 =09amd64-gcc: 5.3.0_1 -> 6.2.0 Number of packages to be upgraded: 19 The process will require 10 MiB more space. 99 MiB to be downloaded. Fetching zsh-5.3.txz: .......... done Fetching rsync-3.1.2_6.txz: .......... done Fetching py27-docutils-0.13.1.txz: .......... done Fetching py27-botocore-1.4.86.txz: .......... done Fetching pinentry-tty-1.0.0.txz: ... done Fetching pinentry-1.0.0.txz: .. done Fetching php56-xml-5.6.29.txz: .. done Fetching php56-simplexml-5.6.29.txz: ... done Fetching php56-mbstring-5.6.29.txz: .......... done Fetching php56-json-5.6.29.txz: .. done Fetching php56-dom-5.6.29.txz: ...... done Fetching php56-curl-5.6.29.txz: ... done Fetching php56-5.6.29.txz: .......... done Fetching mutt-1.7.2.txz: .......... done Fetching jenkins-2.36.txz: .......... done Fetching harfbuzz-1.3.4.txz: .......... done Fetching gsfonts-8.11_8.txz: .......... done Fetching curl-7.51.0_3.txz: .......... done Fetching amd64-gcc-6.2.0.txz: .......... done Checking integrity... done (0 conflicting) [1/19] Upgrading pinentry-tty from 0.9.7 to 1.0.0... [1/19] Extracting pinentry-tty-1.0.0: .... done [2/19] Upgrading pinentry from 0.9.7_1 to 1.0.0... [2/19] Extracting pinentry-1.0.0: ..... done [3/19] Upgrading py27-docutils from 0.12_1 to 0.13.1... [3/19] Extracting py27-docutils-0.13.1: .......... done [4/19] Upgrading php56 from 5.6.28 to 5.6.29... [4/19] Extracting php56-5.6.29: .......... done [5/19] Upgrading curl from 7.51.0_2 to 7.51.0_3... [5/19] Extracting curl-7.51.0_3: .......... done [6/19] Upgrading zsh from 5.2_4 to 5.3... [6/19] Extracting zsh-5.3: .......... done [7/19] Upgrading rsync from 3.1.2_5 to 3.1.2_6... [7/19] Extracting rsync-3.1.2_6: .......... done [8/19] Upgrading py27-botocore from 1.4.82 to 1.4.86... [8/19] Extracting py27-botocore-1.4.86: .......... done [9/19] Upgrading php56-xml from 5.6.28 to 5.6.29... [9/19] Extracting php56-xml-5.6.29: ........ done [10/19] Upgrading php56-simplexml from 5.6.28 to 5.6.29... [10/19] Extracting php56-simplexml-5.6.29: ......... done [11/19] Upgrading php56-mbstring from 5.6.28 to 5.6.29... [11/19] Extracting php56-mbstring-5.6.29: .......... done [12/19] Upgrading php56-json from 5.6.28 to 5.6.29... [12/19] Extracting php56-json-5.6.29: ........ done [13/19] Upgrading php56-dom from 5.6.28 to 5.6.29... [13/19] Extracting php56-dom-5.6.29: .......... done [14/19] Upgrading php56-curl from 5.6.28 to 5.6.29... [14/19] Extracting php56-curl-5.6.29: ....... done [15/19] Upgrading mutt from 1.7.1_2 to 1.7.2... [15/19] Extracting mutt-1.7.2: .......... done [16/19] Upgrading jenkins from 2.35 to 2.36... =3D=3D=3D> Creating groups. Using existing group 'jenkins'. =3D=3D=3D> Creating users Using existing user 'jenkins'. [16/19] Extracting jenkins-2.36: ...... done [17/19] Upgrading harfbuzz from 1.3.3_1 to 1.3.4... [17/19] Extracting harfbuzz-1.3.4: .......... done [18/19] Upgrading gsfonts from 8.11_7 to 8.11_8... [18/19] Extracting gsfonts-8.11_8: .......... done [19/19] Upgrading amd64-gcc from 5.3.0_1 to 6.2.0... [19/19] Extracting amd64-gcc-6.2.0: .......... done Message from zsh-5.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D By default, zsh looks for system-wide defaults in /usr/local/etc. If you previously set up /etc/zprofile, /etc/zshenv, etc., either move them to /usr/local/etc or rebuild zsh with the ETCDIR option enabled. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Message from php56-xml-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-xml.ini configuration file to automatically load the installed extension: extension=3Dxml.so ***************************************************************************= * Message from php56-simplexml-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-simplex= ml.ini configuration file to automatically load the installed extension: extension=3Dsimplexml.so ***************************************************************************= * Message from php56-mbstring-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-mbstrin= g.ini configuration file to automatically load the installed extension: extension=3Dmbstring.so ***************************************************************************= * Message from php56-json-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-json.in= i configuration file to automatically load the installed extension: extension=3Djson.so ***************************************************************************= * Message from php56-dom-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-dom.ini configuration file to automatically load the installed extension: extension=3Ddom.so ***************************************************************************= * Message from php56-curl-5.6.29: ***************************************************************************= * The following line has been added to your /usr/local/etc/php/ext-20-curl.in= i configuration file to automatically load the installed extension: extension=3Dcurl.so ***************************************************************************= * Message from jenkins-2.36: ************************************************************************ Please login to the Jenkins web interface and secure with a password, when installing for the first time. More information: https://wiki.jenkins-ci.org/display/JENKINS/Quick+and+Simple+Security https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup ************************************************************************ + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. pkg: No packages available to install matching 'devel/amd64-xtoolchain-gcc'= have been found in the repositories Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sat Dec 17 17:27:28 2016 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 E5845C85B61 for ; Sat, 17 Dec 2016 17:27:28 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (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 AE7581399 for ; Sat, 17 Dec 2016 17:27:28 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::e9b4:ef6:9a02:eea4] (unknown [IPv6:2001:7b8:3a7:0:e9b4:ef6:9a02:eea4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9EF7E3F42F; Sat, 17 Dec 2016 18:27:25 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E589B05B-AC3C-48A4-84A4-D4322E7CA5FE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: r310188: kernel build failure due to mlx4_ib_sysfs.c:90:22: error: format specifies type 'unsigned long long From: Dimitry Andric In-Reply-To: <20161217124634.131a97b4@thor.walstatt.dynvpn.de> Date: Sat, 17 Dec 2016 18:27:18 +0100 Cc: FreeBSD CURRENT Message-Id: References: <20161217124634.131a97b4@thor.walstatt.dynvpn.de> To: "O. Hartmann" 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: Sat, 17 Dec 2016 17:27:29 -0000 --Apple-Mail=_E589B05B-AC3C-48A4-84A4-D4322E7CA5FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Dec 2016, at 12:46, O. Hartmann wrote: >=20 > Recent kernel source reject to build: >=20 > [...] > --- all_subdir_mlx4ib --- > --- mlx4_ib_sysfs.o --- > = /usr/src/sys/modules/mlx4ib/../../dev/mlx4/mlx4_ib/mlx4_ib_sysfs.c:90:22: = error: format > specifies type 'unsigned long long *' but the argument has type 'u64 = *' (aka 'unsigned > long *') [-Werror,-Wformat] sscanf(buf, "%llx", &sysadmin_ag_val); = ~~~~ ^~~~~~~~~~~~~~~~ > %lx > 1 error generated. Ha, my r310171, which enabled sscanf() format checking, is already working, it seems! I built kernels for both i386 and amd64 without problems, but you may be using some non-default module or settings which trigger this warning. For which arch are you building here, and do you have any particular build settings which might influence this? -Dimitry --Apple-Mail=_E589B05B-AC3C-48A4-84A4-D4322E7CA5FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhVdX0ACgkQsF6jCi4glqPNswCgt0g8Wo9EWSxsElw2ocreTbRt v54AoPW/pAC+DlpaJW79Nj1/bKleU/xv =P04h -----END PGP SIGNATURE----- --Apple-Mail=_E589B05B-AC3C-48A4-84A4-D4322E7CA5FE-- From owner-freebsd-current@freebsd.org Sat Dec 17 17:29:12 2016 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 A6615C85C1F for ; Sat, 17 Dec 2016 17:29:12 +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 02FE71569; Sat, 17 Dec 2016 17:29:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::e9b4:ef6:9a02:eea4] (unknown [IPv6:2001:7b8:3a7:0:e9b4:ef6:9a02:eea4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BB56A3F430; Sat, 17 Dec 2016 18:29:09 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_56EC630C-23AE-41F1-971A-6F22FD2FF6B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing From: Dimitry Andric In-Reply-To: <20161215175646.GA64982@FreeBSD.cs.nctu.edu.tw> Date: Sat, 17 Dec 2016 18:29:09 +0100 Cc: jenkins-admin@freebsd.org, freebsd-current@FreeBSD.org, Baptiste Daroussin Message-Id: <6E1E7D83-ED31-4C50-B7FE-B121AF4584A9@FreeBSD.org> References: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> <20161215175646.GA64982@FreeBSD.cs.nctu.edu.tw> To: Li-Wen Hsu 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: Sat, 17 Dec 2016 17:29:12 -0000 --Apple-Mail=_56EC630C-23AE-41F1-971A-6F22FD2FF6B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Dec 2016, at 18:56, Li-Wen Hsu wrote: >=20 > On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote: >> On 15 Dec 2016, at 12:03, jenkins-admin@freebsd.org wrote: >>>=20 >>> FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: >>>=20 >>> Build information: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/ >>> Full change log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes >>> Full build log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/console >> ... >>> building shared library libprivatedevdctl.so.0 >>> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem = /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/i= nclude/c++/v1 -std=3Dc++11 -nostdinc++ -isystem = /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/i= nclude = -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr= /lib = -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr= /lib = --sysroot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_g= cc/tmp -B/usr/local/x86_64-freebsd/bin/ -fstack-protector-strong -shared = -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o = libprivatedevdctl.so.0.full -Wl,-soname,libprivatedevdctl.so.0 = `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorder = consumer.pico event.pico event_factory.pico exception.pico guid.pico | = tsort -q` >>> /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ >>=20 >> Dear Jenkins admins, can you please install a more recent version of >> amd64-xtoolchain-gcc on the slave? This is required to avoid the = above >> error about not being able to find libstdc++. >=20 > Also from the console log: >=20 > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Checking integrity... done (0 conflicting) > The most recent version of packages are already installed >=20 > The build script install/update the latest devel/amd64-xtoolchain-gcc > package. I think the problem is we did not upgrade the dependencies. = I > cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's > dependencies, so I added a line to build script to upgrade everything > before build. >=20 > Let see if this works. See https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1735/, it doesn't seem to be able to find the correct package: + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. pkg: No packages available to install matching = 'devel/amd64-xtoolchain-gcc' have been found in the repositories -Dimitry --Apple-Mail=_56EC630C-23AE-41F1-971A-6F22FD2FF6B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhVdeUACgkQsF6jCi4glqPynQCePQTgKh0uve6bD5YdQkYmONQX t6wAn3q8ZMwQcXEMhION34xdMTGyy4KR =paL6 -----END PGP SIGNATURE----- --Apple-Mail=_56EC630C-23AE-41F1-971A-6F22FD2FF6B7-- From owner-freebsd-current@freebsd.org Sat Dec 17 17:36:08 2016 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 903ECC85F9F for ; Sat, 17 Dec 2016 17:36:08 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (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 206F61D6E; Sat, 17 Dec 2016 17:36:08 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wj0-x242.google.com with SMTP id j10so18387120wjb.3; Sat, 17 Dec 2016 09:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KyeNq/ldK7AjNqk5zkt4B0XSaaMPeprmWJvVeMg4aGU=; b=AYCz2ylnQ2HqaWgThL7Gxc7rY2ATMZ+vcrFtZGWfy0AW6dbCIW2HuDkfUfMoOBtpQO 2igVGp0Y1JgLSlEWkl93bIwuIONUS5BczhrBJFnaszarKvQUGVrLBOLnoYtXwCicAKKO AcFmNuFapPstf2aeF9CJut+Qwk38fbP2AmZ9eu493pL1eN5lxhBFecZ44APsM0T9BDTv gD70R0vaB7Oztw5QAKFGaaB7v37geaO+r23Vf04TxTE7m3aO8Ig2KNcmJW0DNJjxvwyl cSCexmZamkmMAxWm8BXX6OK0K/uH4O+pygcrQsId9tAbBzqQViVrZPwYYtVLCzQ6F2eg QGSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=KyeNq/ldK7AjNqk5zkt4B0XSaaMPeprmWJvVeMg4aGU=; b=MJNuUyWj6jCqWs02iJH3ddzNxbT7WPKCxNtQqGyEilYYRnngcx5x+ECOvHB12Zk2a4 39sMSPWb44sUtJRMoeQfofqyshzZ7qQQ+12VerT4PEeyXAd35CkQHQsDQMpaamPbb575 HVKvT0kojUVfzd70EQdNZtbwcibTGYfdYn9f9woQbsvGonixRbRUmyoQPo3TmD/Sm4DI 6X+BJSlYWwUukmp1ftyDd9l4Fy1hXOoKXgZLnmGxnysc6UIGD8u2QWHAT/ab9/Ocsnem x78v+/yaK+Tqpb0qpugmJBSRkxZWPjgn+Tm0rJ3VOXSh3ldDdiGznm7NAXk17hvLkqn9 ieUQ== X-Gm-Message-State: AIkVDXKAsUeROjngmff7+WE7y6pT232EG0puYl8BvDAt8KDTsMIG2YSTbBuhzT8WQKEfoA== X-Received: by 10.194.82.163 with SMTP id j3mr8692830wjy.232.1481996166229; Sat, 17 Dec 2016 09:36:06 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id v8sm4776870wjy.34.2016.12.17.09.36.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Dec 2016 09:36:05 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 17 Dec 2016 18:36:04 +0100 From: Baptiste Daroussin To: Dimitry Andric Cc: Li-Wen Hsu , jenkins-admin@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing Message-ID: <20161217173604.j6vdwgre7aqikzb5@ivaldir.etoilebsd.net> References: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> <20161215175646.GA64982@FreeBSD.cs.nctu.edu.tw> <6E1E7D83-ED31-4C50-B7FE-B121AF4584A9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ulfvh6qteti67fgd" Content-Disposition: inline In-Reply-To: <6E1E7D83-ED31-4C50-B7FE-B121AF4584A9@FreeBSD.org> User-Agent: NeoMutt/20161126 (1.7.1) 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, 17 Dec 2016 17:36:08 -0000 --ulfvh6qteti67fgd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2016 at 06:29:09PM +0100, Dimitry Andric wrote: > On 15 Dec 2016, at 18:56, Li-Wen Hsu wrote: > >=20 > > On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote: > >> On 15 Dec 2016, at 12:03, jenkins-admin@freebsd.org wrote: > >>>=20 > >>> FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: > >>>=20 > >>> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64= _gcc/1733/ > >>> Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_g= cc/1733/changes > >>> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gc= c/1733/console > >> ... > >>> building shared library libprivatedevdctl.so.0 > >>> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBS= D_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -= std=3Dc++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/= FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj= /builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc= /obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_= HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-fr= eebsd/bin/ -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl= ,--warn-shared-textrel -o libprivatedevdctl.so.0.full -Wl,-soname,libpriva= tedevdctl.so.0 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorde= r consumer.pico event.pico event_factory.pico exception.pico guid.pico | t= sort -q` > >>> /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ > >>=20 > >> Dear Jenkins admins, can you please install a more recent version of > >> amd64-xtoolchain-gcc on the slave? This is required to avoid the above > >> error about not being able to find libstdc++. > >=20 > > Also from the console log: > >=20 > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > Checking integrity... done (0 conflicting) > > The most recent version of packages are already installed > >=20 > > The build script install/update the latest devel/amd64-xtoolchain-gcc > > package. I think the problem is we did not upgrade the dependencies. I > > cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's > > dependencies, so I added a line to build script to upgrade everything > > before build. > >=20 > > Let see if this works. >=20 > See https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1735/, it > doesn't seem to be able to find the correct package: >=20 > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > pkg: No packages available to install matching 'devel/amd64-xtoolchain-gc= c' have been found in the repositories >=20 yes it was broken, I have fixed it since, so would be in the next update of= the reposirory Best regards, Bapt --ulfvh6qteti67fgd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlhVd4AACgkQY4mL3PG3 PloyMg//STlLmNtD0BGJlVs2fBkd2i+QKuk3qX7dsOwXTRTjtC7VDzd4qUEhOdh9 CBCjnJXR4Ae1xAtH++ly5iWdTH4PU9ldMDm8MtZ44cmZGrkxeUu69EK9aOZWvK9m oO4+KT0vj+z6/VP/4C8yh/SOqIigetptz2rratQEBv2Fb5hY3P7v/2VDl+yOJ7NY KBwv3Rv0oe/cKuu+dzk9TRZvnP6JcBCWnV9g+K0Ec6Wf5bAmuIPbxBfeB1PMT3CS 6vQKILWu9+DgRdx41K4Vp1gJVhCxMFymwZTZ/ZqelNZQ4P+aPfiPSwTdhrpXQfYZ eFsb8+ySKcvq0XiY3kS+vMA9kMqhsxYSosQQMJftU3Jzs8SYfDCWCQTaP1tax+qZ Dh52HfOIULsU3iAYe5xS+8Acs+DPjVzW1leJ38s/W0KiwAN5SFv9lZAT3cZRIgbx 8pGUXmzKCE42W7NkpyJKxf8CuWOAqlTmJIwOTHUdcZMhlLtNQYb7VFDX+3CPS0dP pf6+Mh9wztYUn+RkU0mK7OLtoi8bBmq0YmIQywuacIab6wqRFBSdwVRhnCUnJwhk dG2KIl968WrrRGEQ3d1q62Omz9mTrM4dD9WFdesd2wkWd06HW7/39bj3QVAd8w1I vfWGnpK1StnUZcIyfNB9jTutvPq8Dh7Om73gPHm5guzIeN+n8/g= =mHOG -----END PGP SIGNATURE----- --ulfvh6qteti67fgd-- From owner-freebsd-current@freebsd.org Sat Dec 17 17:48:13 2016 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 DF667C8537F for ; Sat, 17 Dec 2016 17:48:13 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B06A8C1; Sat, 17 Dec 2016 17:48:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([78.52.69.192]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVZuV-1c6MBJ1KXv-00Z1sM; Sat, 17 Dec 2016 18:48:10 +0100 Date: Sat, 17 Dec 2016 18:48:04 +0100 From: "O. Hartmann" To: Dimitry Andric Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: r310188: kernel build failure due to mlx4_ib_sysfs.c:90:22: error: format specifies type 'unsigned long long Message-ID: <20161217184804.67c54193@thor.walstatt.dynvpn.de> In-Reply-To: References: <20161217124634.131a97b4@thor.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/5BgTymoGxJ7wYuGAX3U/7ft"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:RJ91vhh0RqIpFykW8lIR/OG1OGGqqVOuMh1v+iVOtbeB2EsClvD FvPsHYt8XrNVfiUqKy3sYDX1zFNjgA05oC2WkjffYfBDqGgp504M/O3CI+B0YUR1gw9UYqD uDT3nn5J3GdNm7yh26KvJZKmZpcpFAQrwVcbDswjFXGQIIdNwI+FbB/N5Pc0bh1EgVXx9gD 96spEQx82wOka3pQIxhmA== X-UI-Out-Filterresults: notjunk:1;V01:K0:aukqo96oT9E=:+lWdGfjVblK4b+BkzIpAwq WtslSTQXaPcttQosXfxtKaVPibOl7JVGej6cZUfOYeyU09YiPSpw/nSlCiADfE7tGEKo2hwFu suVLODauDCMbcg0IaTP7SIS46dFINDFyBDEFM1rqRQ6jlLB3Hyy5oj89+dmvquBqLmHgsXDCj pDTwD9+pqE2Py+ynmF/0fwIadzCMvCegcNf1n3aG0Cinmf0DIBfgNaAf3ltLDg410non3SOcS dgCeDhhWNHDuRu6PWDSPbfCMIrsX/NWJNq04Yka4ACTa2URBVBzZceCdoCLyqVyjNln1XPCCB 8Ui5wTR7cAsgQc1Bn+GOcgLRCG74BFGaZQc9So80EguBHdzQUc6Y/K3mgiK+Ng+Ni4MH8fA2v +mAb9RlQS6C6MD7A/sotsikcy3ngMnC9hjDB4TKiCJIlzzXZl1V+1Xe9e1w7Ov1QvGIHRn2CB 2aiiaykFE8Fkh3Bj+Dys78kVB8tvc2O6/zyOODLbJtoUQjJI7nTqon35GE2IdiaBq0MaehrX0 Vjr1qe7FtU6/KrS19Fi2r7phTfTLOzQqDlHSCcUnnWYiFi/Wn8Npw/T5LhkN9pikTMMsNIdSA t58A/fdbC5IbDXIyd3qhQUTA4oc3oYtaOCDHaxb4NzSxhB0A34jwI9k2Al1hVjHwwSjWIHisn ATFmwJBSZhvF8Jer4sowU966ZMe8iWBjfg+lm/saDv9KffOWWHQGkNtLW7hcB9ZTMM4o51RSd A1h0st22UppDioakSJmO4dtBhdvHwN623BFRZYGuqSdQsE0p9l4hbtJZfsQ= 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, 17 Dec 2016 17:48:14 -0000 --Sig_/5BgTymoGxJ7wYuGAX3U/7ft Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 17 Dec 2016 18:27:18 +0100 Dimitry Andric schrieb: > On 17 Dec 2016, at 12:46, O. Hartmann wrote: > >=20 > > Recent kernel source reject to build: > >=20 > > [...] > > --- all_subdir_mlx4ib --- > > --- mlx4_ib_sysfs.o --- > > /usr/src/sys/modules/mlx4ib/../../dev/mlx4/mlx4_ib/mlx4_ib_sysfs.c:90:2= 2: error: > > format specifies type 'unsigned long long *' but the argument has type = 'u64 *' (aka > > 'unsigned long *') [-Werror,-Wformat] sscanf(buf, "%llx", &sysadmin_ag_= val); ~~~~ > > ^~~~~~~~~~~~~~~~ %lx > > 1 error generated. =20 >=20 > Ha, my r310171, which enabled sscanf() format checking, is already > working, it seems! I built kernels for both i386 and amd64 without > problems, but you may be using some non-default module or settings which > trigger this warning. >=20 > For which arch are you building here, and do you have any particular > build settings which might influence this? >=20 > -Dimitry >=20 Building system is: FreeBSD 12.0-CURRENT #74 r310129: Fri Dec 16 00:33:09 CET 2016 /etc/rc.conf is: # CPUTYPE?=3D native # CFLAGS+=3D -O3 COPTFLAGS+=3D -O3 # #CXXFLAGS+=3D -std=3Dc++11 # WITH_CLANG_FULL=3D YES WITH_CLANG_EXTRAS=3D YES WITH_LLDB=3D YES # WITH_IDEA=3D YES # #WITH_BSD_GREP=3D YES # WITH_OFED=3D YES WITH_NAND=3D YES # #WITH_CTF=3D YES # WITH_SVN=3D YES # #WITH_META_MODE=3D YES # #WITH_SORT_THREADS=3D YES # MALLOC_PRODUCTION=3D YES # WITHOUT_ASSERT_DEBUG=3D YES # WITHOUT_DEBUG_FILES=3D YES --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/5BgTymoGxJ7wYuGAX3U/7ft Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWFV6VAAKCRDS528fyFhY lPERAgCktqcjYcTNMtKJObdeTG7IITeTyH4OofZvsm///6gmSzMNrCU6JXKPRmeI GfWwM7VIC+D8afQqDmtLQeMWKctlAf9Wy33S0N3OCjW6sFVWc70dmhKGqYv/nBr1 iDIi+Itglav8zdjz4YxxKiQKoTLFPENJz3voQZ5m1mJ71sXtP7I9 =J4vx -----END PGP SIGNATURE----- --Sig_/5BgTymoGxJ7wYuGAX3U/7ft-- From owner-freebsd-current@freebsd.org Sat Dec 17 17:51:17 2016 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 D1803C85581 for ; Sat, 17 Dec 2016 17:51:17 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50418AF2; Sat, 17 Dec 2016 17:51:17 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id 47C122695; Sun, 18 Dec 2016 01:51:14 +0800 (CST) Date: Sun, 18 Dec 2016 01:51:14 +0800 From: Li-Wen Hsu To: Dimitry Andric Cc: jenkins-admin@freebsd.org, freebsd-current@FreeBSD.org, Baptiste Daroussin Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing Message-ID: <20161217175114.GA91973@FreeBSD.cs.nctu.edu.tw> References: <1585371352.86.1481713396874.JavaMail.jenkins@jenkins-9.freebsd.org> <972921313.96.1481799792487.JavaMail.jenkins@jenkins-9.freebsd.org> <153A5C4A-09F0-41AD-B53A-661171C888EB@FreeBSD.org> <20161215175646.GA64982@FreeBSD.cs.nctu.edu.tw> <6E1E7D83-ED31-4C50-B7FE-B121AF4584A9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <6E1E7D83-ED31-4C50-B7FE-B121AF4584A9@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 17 Dec 2016 17:51:17 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2016 at 18:29:09 +0100, Dimitry Andric wrote: > On 15 Dec 2016, at 18:56, Li-Wen Hsu wrote: > >=20 > > On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote: > >> On 15 Dec 2016, at 12:03, jenkins-admin@freebsd.org wrote: > >>>=20 > >>> FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: > >>>=20 > >>> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64= _gcc/1733/ > >>> Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_g= cc/1733/changes > >>> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gc= c/1733/console > >> ... > >>> building shared library libprivatedevdctl.so.0 > >>> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem /builds/FreeBS= D_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1 -= std=3Dc++11 -nostdinc++ -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/= FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj= /builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib -B/builds/FreeBSD_HEAD_amd64_gcc= /obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_= HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-fr= eebsd/bin/ -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl= ,--warn-shared-textrel -o libprivatedevdctl.so.0.full -Wl,-soname,libpriva= tedevdctl.so.0 `NM=3D'/usr/local/x86_64-freebsd/bin/nm' NMFLAGS=3D'' lorde= r consumer.pico event.pico event_factory.pico exception.pico guid.pico | t= sort -q` > >>> /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++ > >>=20 > >> Dear Jenkins admins, can you please install a more recent version of > >> amd64-xtoolchain-gcc on the slave? This is required to avoid the above > >> error about not being able to find libstdc++. > >=20 > > Also from the console log: > >=20 > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > Checking integrity... done (0 conflicting) > > The most recent version of packages are already installed > >=20 > > The build script install/update the latest devel/amd64-xtoolchain-gcc > > package. I think the problem is we did not upgrade the dependencies. I > > cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's > > dependencies, so I added a line to build script to upgrade everything > > before build. > >=20 > > Let see if this works. >=20 > See https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1735/, it > doesn't seem to be able to find the correct package: >=20 > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > pkg: No packages available to install matching 'devel/amd64-xtoolchain-gc= c' have been found in the repositories >=20 I think this is another problem, the latest package set doesn't have devel/amd64-xtoolchain-gcc due to it faild in build: https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-2016121= 2/378894.html =46rom https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1734/ : + sudo pkg upgrade -y Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (7 candidates): ....... done Processing candidates (7 candidates): . done Checking integrity... done (0 conflicting) Your packages are up to date. + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The most recent version of packages are already installed + pkg info + grep ^amd64 amd64-binutils-2.27_5,1 GNU binutils for amd64 cross-development amd64-gcc-5.3.0_1 Cross GNU Compiler Collection for amd64 amd64-xtoolchain-gcc-0.1 Pre seeded toolchain to cross build FreeBSD = base Although this build also failed, are these packages what you want? I'll update the build script to make it doesn't fail when searching latest package failed. Thanks, Li-Wen --=20 Li-Wen Hsu https://lwhsu.org --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJYVXsRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZW+3cP/3EQhmG4qsFzdnQf2RrupkIK d8NAzv8fjQFgFpM+x5/YVK1cDYfQYbsFqctafdx/DWwM4G+g3vGu4i1Ks1fnDA/Y UWBhNyQDzvHWf5de7IBIpDP2SzcZSd2kgPu931Qq6m5t4p4susp5yxAbjILRGD/4 OfBlBYwtXl0vTKKSCZWfmUAE3igGh5hEV+Eo+CaqLOSeOmfTpzd+NaDNy1zyi06X cASuLqY7mKUMRa76vq0SnYGOZDpc86C2qTaVLcxm3hHTLATSQAnn3HLNB/axOjtM vQowgGSifB97KAs7bpHUeZSEfMf9lnaQeXeETqFed8Ymdt3aefB6WO3iCpzrr8bn FGADxW32EB32gu4z0FVUWAU77tXUYRCLYFSXWCjT4cNfamJnTJzOW/2riOEUroxs V/WNzClDBPReMuQrfgNlsfQmqjaVl3zur/xiU3f1F+VM6le00vfktqNo1hC19DMY Imar0ENA4cMW7ksAeRDFDKCRL5PffyDKiIuZKZxQAE3/lGc9xPCk7BQR86ItKhfz qSlYPVFcN5gp3dKE3BL5fnWvur4p+gRuhUZIA2QsOqpAy/1z+x6wCLliGSE/2EGd I2PkO8qb0KNuipINvC5tmlreRh+5y4c7nnpqEIhhaDZ+I4VpvP6iU4m3avPX3aJw s9R1ZNVW8ExmWt0OLcm3 =y7GJ -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--