From owner-freebsd-current@freebsd.org Sun Mar 25 04:15:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03790F6B687 for ; Sun, 25 Mar 2018 04:15:09 +0000 (UTC) (envelope-from areilly@bigpond.net.au) 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 92D7B72145 for ; Sun, 25 Mar 2018 04:15:08 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: by mailman.ysv.freebsd.org (Postfix) id 52565F6B686; Sun, 25 Mar 2018 04:15:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EA43F6B685 for ; Sun, 25 Mar 2018 04:15:08 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta23p.bpe.bigpond.com (nsstlmta23p.bpe.bigpond.com [203.38.21.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB9F77213C; Sun, 25 Mar 2018 04:15:04 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep20p-svc.bpe.nexus.telstra.com.au with ESMTP id <20180325032116.LRKI32504.nsstlfep20p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sun, 25 Mar 2018 14:21:16 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtgedrvdeggddviecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheptehnughrvgifucftvghilhhlhicuoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqnecukfhppeduvdegrdduledtrdegtddrudekvdenucfrrghrrghmpehhvghlohepkggvnhdrrggtqdhrrdhnuhdpihhnvghtpeduvdegrdduledtrdegtddrudekvddpmhgrihhlfhhrohhmpeeorghrvghilhhlhiessghighhpohhnugdrnhgvthdr X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from Zen.ac-r.nu (124.190.40.182) by smtp.telstra.com (9.0.019.22-1) (authenticated as areilly@bigpond.net.au) id 5A4EB5561CC223CD; Sun, 25 Mar 2018 14:21:16 +1100 Date: Sun, 25 Mar 2018 14:21:10 +1100 From: Andrew Reilly To: Warner Losh Cc: FreeBSD Current , jtl@freebsd.org Subject: Re: 12-Current panics on boot (didn't a week ago.) Message-ID: <20180325032110.GA10881@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> <20180324232206.GA2457@Zen.ac-r.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 04:15:09 -0000 OK, I've completed the search: r331346 works, r331347 panics somewhere in the initialization of random. In the 331347 change (Add the "TCP Blackbox Recorder") I can't see anything obvious to tweak, unfortunately. It's a fair chunk of new code but it's all network-stack related, and my kernel is panicking long before any network activity happens. Any suggestions? Cheers, Andrew On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote: > Thanks Andrew... I can't recreate this on my VM nor my real hardware. > > Warner > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly > wrote: > > > So, r331464 crashes in the same place, on my system. r331064 still boots > > OK. I'll keep searching. > > > > One week ago there was a change to randomdev to poll for signals every so > > often, as a defence against very large reads. That wouldn't have > > introduced a race somewhere, > > or left things in an unexpected state, perhaps? That change (r331070) by > > cem@ is just a few revisions after the one that is working for me. I'll > > start looking there... > > > > Cheers, > > > > Andrew > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > > > Hi Warner, > > > > > > The breakage was in 331470, and at least one version earlier, that I > > updated past when it panicked. > > > > > > I'm guessing that kdb's inability to dump would be down to it not having > > found any disk devices yet, right? So yes, bisecting to narrow down the > > issue is probably the best bet. I'll try your r331464: if that works that > > leaves only four or five revisions. Of course the breakage could be > > hardware specific. > > > > > > Cheers, > > > -- > > > Andrew > > From owner-freebsd-current@freebsd.org Sun Mar 25 03:52:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1EFEF6A02F for ; Sun, 25 Mar 2018 03:52:58 +0000 (UTC) (envelope-from yuri@rawbw.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 4718C7147D for ; Sun, 25 Mar 2018 03:52:58 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: by mailman.ysv.freebsd.org (Postfix) id ECE8DF6A02E; Sun, 25 Mar 2018 03:52:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D76D0F6A02D for ; Sun, 25 Mar 2018 03:52:57 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 491337147C for ; Sun, 25 Mar 2018 03:52:56 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w2P3qtx8029189 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 24 Mar 2018 20:52:55 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me To: current From: Yuri Subject: Current fails to install in virtualbox: Distribution extract failed Message-ID: <49076176-3daf-7061-7772-320dfae44f75@rawbw.com> Date: Sat, 24 Mar 2018 20:52:54 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 03:52:58 -0000 This ISO image: FreeBSD-12.0-CURRENT-amd64-20180322-r331345-disc1.iso Differences with default: I chose ZFS root fs and only left "ports" checked in "Distribution Select". Yuri From owner-freebsd-current@freebsd.org Sun Mar 25 04:15:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FBEDF6B694 for ; Sun, 25 Mar 2018 04:15:11 +0000 (UTC) (envelope-from areilly@bigpond.net.au) 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 506197214F for ; Sun, 25 Mar 2018 04:15:11 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: by mailman.ysv.freebsd.org (Postfix) id 11964F6B691; Sun, 25 Mar 2018 04:15:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E144DF6B68E for ; Sun, 25 Mar 2018 04:15:10 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta23p.bpe.bigpond.com (nsstlmta23p.bpe.bigpond.com [203.38.21.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0DBC72148 for ; Sun, 25 Mar 2018 04:15:08 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep38p-svc.bpe.nexus.telstra.com.au with ESMTP id <20180325035010.LDAI16963.nsstlfep38p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sun, 25 Mar 2018 14:50:10 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtgedrvdeggdefvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheptehnughrvgifucftvghilhhlhicuoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgpdgrtgdqrhdrnhhunecukfhppeduvdegrdduledtrdegtddrudekvdenucfrrghrrghmpehhvghlohepkggvnhdrrggtqdhrrdhnuhdpihhnvghtpeduvdegrdduledtrdegtddrudekvddpmhgr X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from Zen.ac-r.nu (124.190.40.182) by smtp.telstra.com (9.0.019.22-1) (authenticated as areilly@bigpond.net.au) id 5A204A9628731CF6; Sun, 25 Mar 2018 14:50:10 +1100 Date: Sun, 25 Mar 2018 14:50:05 +1100 From: Andrew Reilly To: Warner Losh Cc: FreeBSD Current Subject: Re: 12-Current-r331347 panics on boot (r331346 and earlier didn't.) Message-ID: <20180325035005.GA2551@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 04:15:11 -0000 OK, I've completed the search: r331346 works, r331347 panics somewhere in the initialization of random. In the 331347 change (Add the "TCP Blackbox Recorder") I can't see anything obvious to tweak, unfortunately. It's a fair chunk of new code but it's all network-stack related, and my kernel is panicking long before any network activity happens. Any suggestions? Cheers, Andrew On Sat, Mar 24, 2018 at 08:14:40AM -0600, Warner Losh wrote: > Also, what rev failed? I booted r331464 last night w/o issue. > > Warner > > On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly > wrote: > > > Hi all, > > > > For reasons that still escape me, I haven't been able to get a kernel dump > > to debug, sorry. > > > > Just thought that I'd generate a fairly low-quality report, to see if > > anyone has some ideas. > > > > The last kernel that I have that booted OK (and I'm now running) is: > > FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r331064M: Sat > > Mar 17 07:54:51 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > amd64 > > > > The machine is a: > > CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz K8-class > > CPU) > > Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 > > Features=0x178bfbff > APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > Kernels built from head as of a couple of hours ago get through launching > > the other CPUs and then stops somewhere in random, apparently: > > > > SMP: AP CPU #2 Launched! > > Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 > > random: entpanic: mtx_lock() of spin mutex (null) @ > > /usr/src/sys/kern/subr_bus.c:617 > > cpuid = 0 > > time = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe00004507a0 > > vpanic() at vpanic+0x18d/frame 0xfffffe0000450800 > > doadump () at doadump/frame 0xfffffe0000450880 > > __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfffffe00004508d0 > > devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 0xfffffe0000450900 > > g_dev_taste() at g_dev_taste+0x370/frame 0xfffffe0000450a10 > > g_new_provider_event() at g_new_provider_event+0xfa/frame > > 0xfffffe0000450a30 > > g_run_events() at g_run_events+0x151/frame 0xfffffe0000450a70 > > fork_exit() at fork_exit+0x84/frame 0xfffffe0000450ab0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000450ab0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > [ thread pid 14 tid 100052 ] > > Stopped at kdb_enter+0x3b: movq $0,kdb_why > > db> dump > > Cannot dump: no dump device specified. > > db> > > > > Now dumping worked fine the last time the kernel panicked: I have > > dumpdev=AUTO in rc.conf and I have swap on nvd0p3 (first) and > > /dev/zvol/root/swap > > (second, larger than the first.) > > > > Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user > > directories and what-not on them, and another ZFS on an external USB drive > > that I use > > for backups, unmounted. > > > > In the new kernels, we clearly aren't even getting as far as finding the > > hubs and controllers, let alone the drives. > > > > I've attached dmesg.boot from the last boot from last week's good kernel. > > (While briefly in yoyo mode I turned the SMT back on, so now there are 16 > > cores > > instead of the eight mentioned in the crash dump. Didn't help, but I > > haven't turned it back off yet.) > > > > Cheers, > > > > Andrew > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Mar 25 09:55:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46E72F5D4A1 for ; Sun, 25 Mar 2018 09:55:42 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 D0F0D7DD13; Sun, 25 Mar 2018 09:55:41 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 408CM86st4zDhKF; Sun, 25 Mar 2018 09:55:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=daemonic.se; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=20151023; t=1521971732; bh=dgGG2ptgp7C1WAOgc5hPLC5D qzNsVZmbOGKc/eNN7c0=; b=oI84QZjpnBEI5VIcCzEbhEiXdv6WkorhqAw5YP8K VnF61vjd23FawKZaPoFfhZ/XcU8P8CA7z58YIHZyPYkklPM04WRKDeFcu0kkgyAh Ytw9SlBrFTDjig5Aag0KL+E0siSaRvGz8t/smNYHNo9jNn0x+97Qe74SclfjDFSg I8A= X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id GuG391MSJ2Kr; Sun, 25 Mar 2018 09:55:32 +0000 (UTC) Received: from celes.daemonic.se (celes.daemonic.se [IPv6:2001:470:dca9:2::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 408CM83b2NzDhK1; Sun, 25 Mar 2018 09:55:32 +0000 (UTC) Subject: Re: Call for Testing: UEFI Changes To: Kyle Evans , FreeBSD Current References: From: Niclas Zeising Message-ID: Date: Sun, 25 Mar 2018 11:54:38 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 09:55:42 -0000 On 03/22/18 01:45, Kyle Evans wrote: > Hello! > > A number of changes have gone in recently pertaining to UEFI booting > and UEFI runtime services. The changes with the most damaging > potential are: > > We now put UEFI runtime services into virtual address mode, fixing > runtime services with U-Boot/UEFI as well as the firmware > implementation in many Lenovos. The previously observed behavior was a > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic > just loading efirt.ko or compiling EFIRT into the kernel. > > Graphics mode selection is now done differently to avoid regression > caused by r327058 while still achieving the same effect. The observed > regression was that the kernel would usually end up drawing > incorrectly at the old resolution on a subset of the screen, due to > incorrect framebuffer information. > > Explicit testing of these changes, the latest of which happened in > r331326, and any feedback from this testing would be greatly > appreciated. Testing should be done with either `options EFIRT` in > your kernel config or efirt.ko loaded along with updated bootloader > bits. > > I otherwise plan to MFC commits involved with the above-mentioned > changes by sometime in the first week of April, likely no earlier than > two (2) weeks from now on April 4th. > Hi! I've tested on two different computers, my ThinkPad x230 and my desktop with a Intel DQ77MK motherboard. I've only done light testing such as loading efirt.ko and running efibootmgr to check the boot settings, but it has worked fine. I also haven't seen any issues with console graphics on either machine. Both computers are running CURRENT from yesterday, the desktop is on r331481 and the laptop probably somewhere around that as well. Please let me know if you want me to test anything else! Regards -- Niclas From owner-freebsd-current@freebsd.org Sun Mar 25 10:42:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E13CBF60D88 for ; Sun, 25 Mar 2018 10:42:07 +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 7D1D07F36B; Sun, 25 Mar 2018 10:42:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1f0366-0008SB-KE; Sun, 25 Mar 2018 13:41:58 +0300 Date: Sun, 25 Mar 2018 13:41:58 +0300 From: Slawa Olhovchenkov To: Bryan Drewery Cc: Peter Jeremy , Jeff Roberson , FreeBSD current , Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT Message-ID: <20180325104158.GB6612@zxy.spb.ru> References: <20180306173455.oacyqlbib4sbafqd@ler-imac.lerctr.org> <201803061816.w26IGaW5050053@pdx.rh.CN85.dnsmgr.net> <20180306193645.vv3ogqrhauivf2tr@ler-imac.lerctr.org> <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> 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.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 10:42:08 -0000 On Fri, Mar 23, 2018 at 04:21:32PM -0700, Bryan Drewery wrote: > On 3/20/2018 12:07 AM, Peter Jeremy wrote: > > > > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: > >> Also, if you could try going back to r328953 or r326346 and let me know if > >> the problem exists in either. That would be very helpful. If anyone is > >> willing to debug this with me contact me directly and I will send some > >> test patches or debugging info after you have done the above steps. > > > > I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). > > I initially got around the problem by reverting that commit but either > > it or something very similar is still present in 11-stable r331053. > > > > I've seen it in my main server (32GB RAM) but haven't managed to reproduce > > it in smaller VBox guests - one difficulty I faced was artificially filling > > ARC. > > > > Looking at the ARC change you referred to from r325851 > https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure > is completely broken. On my 78GB RAM system with ARC limited to 40GB and > doing a poudriere build of all LLVM and GCC packages at once in tmpfs I > can get swap up near 50GB and yet the ARC remains at 40GB through it > all. It's always been slow to give up memory for package builds but it > really seems broken right now. Can you test: revert all 'needfree' related commits and applay https://reviews.freebsd.org/D7538 ? From owner-freebsd-current@freebsd.org Sun Mar 25 04:35:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5364AF6C6B8 for ; Sun, 25 Mar 2018 04:35:45 +0000 (UTC) (envelope-from jonlooney@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 DEBC272DDB for ; Sun, 25 Mar 2018 04:35:44 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9C7F5F6C6B5; Sun, 25 Mar 2018 04:35:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5B8F6C6B4 for ; Sun, 25 Mar 2018 04:35:44 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 0CCA072DD8; Sun, 25 Mar 2018 04:35:43 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id i75so9786601wmf.0; Sat, 24 Mar 2018 21:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GM+zXPklKQmbOSOEKf+cH1cyobR6egMqCEqXz/S7mXU=; b=XQLA9Z+KF58HOOLonQNYsj3WW3MGSTkJo1NvcYqPkWKcDv/R47jOtG3Kn7fUkHVf9p u/vcsaVU+WexsEIgfm0mDN38MPtXA/sms6hgAJNIlw2bMMY7PCHRJE2vaoqP+pMdl+W0 KsbsGQX/GUQg7sMXUZFrUyeTkpBDi6V4xvZphRB7zpOwojSS9IeplD17n+hnmM3FVdvH dff9AfrPU2SfCA0d+SefFN7wI8VpzRPcmZ1OaHIGXM2K2FxXm85nwPSt3l/epRAa8g/2 kk604nv2csn5xjY7JTgsO2bJQraYBB6P9QK/vMlU2aPzAvmd0KpoSM2+5jTKGgmTKAt1 ijwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GM+zXPklKQmbOSOEKf+cH1cyobR6egMqCEqXz/S7mXU=; b=ACMuQccgZGq26lh3ZLXiE52lo8sdo3OpGn2fVY3a5VuaLSJZkDpPH2ZeeJ0KHU3ZDn bv2JTegeO7ACdfBRwXPIu3G943F6d7oimt5XTG9MH7AvDYWnhHxeGVZCJojQPV6VvskF lQtEGg4wPEw6aSo+au6VGh5EvugNQLRhtVWMNJxXb5XBmex9iUqsoenhvAICt70u/8c4 KC/ra6hvEvAIgr2w/UKn7/ERjrmvYRo5CcLw2c+oo/E9eu/kwe7Gks1x7ePOYblP3arc Yxzw6RmqRKuQRfrqUFn/IqDP9queO7t+d0vK+M9qZPOPfvyzInRO6gHv6i4KGrPudsG+ R8jQ== X-Gm-Message-State: AElRT7FsGe7NTb5wdMKWOHLIS/yfZMNUYp3GENhXg3px6lQ7K/KHqX9t W4Wyy2cW37hXPe4TPYobi88X1DXnUbTWXPLkUsazqQ== X-Google-Smtp-Source: AG47ELuygrzc/ML1IR0fo/H3NIC7njRDcM9n8kqaXDtIInUs5XKY7038a6PzwmtQ3Qo8Rffsly91ENtFIWzNLIExsbA= X-Received: by 10.28.125.84 with SMTP id y81mr12055039wmc.66.1521952541633; Sat, 24 Mar 2018 21:35:41 -0700 (PDT) MIME-Version: 1.0 References: <20180324035653.GA3411@Zen.ac-r.nu> <20180324232206.GA2457@Zen.ac-r.nu> <20180325032110.GA10881@Zen.ac-r.nu> In-Reply-To: <20180325032110.GA10881@Zen.ac-r.nu> From: Jonathan Looney Date: Sun, 25 Mar 2018 04:35:31 +0000 Message-ID: Subject: Re: 12-Current panics on boot (didn't a week ago.) To: Andrew Reilly Cc: FreeBSD Current , Warner Losh , jtl@freebsd.org X-Mailman-Approved-At: Sun, 25 Mar 2018 11:18:30 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 04:35:45 -0000 For now, you can update through r331485 and then take TCP_BLACKBOX out of your kernel config file. That won=E2=80=99t really =E2=80=9Cfix=E2=80=9D an= ything, but should at least get you a booting system (assuming the new code from r331347 is really triggering a problem). I=E2=80=99ll take another look to see if I missed something in the commit. = But, at the moment, I=E2=80=99m hard-pressed to see how r331347 would cause the pro= blem you describe. Jonathan On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly wrote: > OK, I've completed the search: r331346 works, r331347 panics > somewhere in the initialization of random. > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > anything obvious to tweak, unfortunately. It's a fair chunk of new > code but it's all network-stack related, and my kernel is panicking > long before any network activity happens. > > Any suggestions? > > Cheers, > > Andrew > > On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote: > > Thanks Andrew... I can't recreate this on my VM nor my real hardware. > > > > Warner > > > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly > > wrote: > > > > > So, r331464 crashes in the same place, on my system. r331064 still > boots > > > OK. I'll keep searching. > > > > > > One week ago there was a change to randomdev to poll for signals ever= y > so > > > often, as a defence against very large reads. That wouldn't have > > > introduced a race somewhere, > > > or left things in an unexpected state, perhaps? That change (r331070= ) > by > > > cem@ is just a few revisions after the one that is working for me. > I'll > > > start looking there... > > > > > > Cheers, > > > > > > Andrew > > > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > > > > Hi Warner, > > > > > > > > The breakage was in 331470, and at least one version earlier, that= I > > > updated past when it panicked. > > > > > > > > I'm guessing that kdb's inability to dump would be down to it not > having > > > found any disk devices yet, right? So yes, bisecting to narrow down > the > > > issue is probably the best bet. I'll try your r331464: if that works > that > > > leaves only four or five revisions. Of course the breakage could be > > > hardware specific. > > > > > > > > Cheers, > > > > -- > > > > Andrew > > > > From owner-freebsd-current@freebsd.org Sun Mar 25 11:53:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93EDDF65FE2 for ; Sun, 25 Mar 2018 11:53:04 +0000 (UTC) (envelope-from herbert@gojira.at) 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 34809813B2 for ; Sun, 25 Mar 2018 11:53:04 +0000 (UTC) (envelope-from herbert@gojira.at) Received: by mailman.ysv.freebsd.org (Postfix) id E969FF65FE1; Sun, 25 Mar 2018 11:53:03 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6E0FF65FE0 for ; Sun, 25 Mar 2018 11:53:03 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [144.76.30.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75404813B1 for ; Sun, 25 Mar 2018 11:53:02 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sun, 25 Mar 2018 13:52:54 +0200 Message-ID: <87605k9xt5.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: current@freebsd.org Subject: Re: 12-Current panics on boot (didn't a week ago.) In-Reply-To: <20180325032110.GA10881@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> <20180324232206.GA2457@Zen.ac-r.nu> <20180325032110.GA10881@Zen.ac-r.nu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/27.0 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 11:53:04 -0000 On Sun, 25 Mar 2018 05:21:10 +0200, Andrew Reilly wrote: > > OK, I've completed the search: r331346 works, r331347 panics > somewhere in the initialization of random. > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > anything obvious to tweak, unfortunately. It's a fair chunk of new > code but it's all network-stack related, and my kernel is panicking > long before any network activity happens. > > Any suggestions? Does your system boot if you upgrade to at least r331485 and remove "options TCP_BLACKBOX" from sys/amd64/conf/GENERIC (if you build and run GENERIC)? -- Herbert From owner-freebsd-current@freebsd.org Sun Mar 25 12:52:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3FF7F6C24D for ; Sun, 25 Mar 2018 12:52:31 +0000 (UTC) (envelope-from shedatc@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 4055F8412B; Sun, 25 Mar 2018 12:52:31 +0000 (UTC) (envelope-from shedatc@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id v21so10771930wmc.1; Sun, 25 Mar 2018 05:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ejOslvOYIWt547RmeNW+xuuc0dGMkgjQBj/91hRAKp8=; b=pu/MmDV6Tz3/4c3HA5+MXI+z0N9H4MPRUPgFLmwWySusL5t1BsO3ILsp5zAq5J/vX4 8KjYVzvdjlgX9vVFAht8tT6vmwxGULkFzMW+stKEs+z6t35a5tMVK2bPBw15yExuLeIY xF2blHZP3kuTHZvMiAM/tFu7n+hLQJh58n4fyYniUNTxsQAva3yRsCDTuqKvdZP4QO2R 32//D9FGBIQlnvEa++/isQtIFY9Z5Mino09NUmdisEQ0p+FWWNFj/1tDXuhYeAAxScrc 4wKAz+3aXNlOQ3tZb6Dqv/CQGvoPxp648FWpohLv+2Y2C2EK82LtrCuzF/MNbmXFbQTJ jHeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ejOslvOYIWt547RmeNW+xuuc0dGMkgjQBj/91hRAKp8=; b=r2uXI2dl8BDD5LMxYGEYvDfKjsfqNEaEDYIYuXwbopD7HIWwOQ/P0bTh9KnAqmRP8o MnjLLcIpMMyvrfsIFEEFWlmSfDf4wVU8jtuyF/Jwq8Wxg/OoqgeFAk/gKDbmoaNTiZfP DuLYyKMUOZmuU1CD7O95vgd4DbyP8EnZ7/WNkosjlU5tIbSXTFUecoPjuw1+oerNa5xT IlocxWh45/0TbWkXXa3C2qhYRil91d+jlqxMM1R0Y34YZSQk2iTfgNH7ikcpYEagUnSm fqq7N7ZNlSIk1m8a0XypwFB4rGjYx8UWlmevT24vqW+ZRQKlZj23PkXhlhmJbpjqQzA9 1W8w== X-Gm-Message-State: AElRT7FPh/jkiQj8WN5QjtlnBspa9AFde0Vyx8u6BuZrMPo5lNOd1Mcz n6f+48Pj3en8pPedy7vayr+2s6nqNZKS/U9oRKjxuA== X-Google-Smtp-Source: AG47ELtFoKN1uvsSxWEs6w34yjhouC+ZlmUC6ECMOxH8yED0khjUkFURwSgDuo2ym4fT0LbgcBlAjYcrbWnMXKDj7kM= X-Received: by 10.80.151.167 with SMTP id e36mr37206899edb.210.1521982350280; Sun, 25 Mar 2018 05:52:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.202.66 with HTTP; Sun, 25 Mar 2018 05:52:29 -0700 (PDT) Reply-To: sheda@fsfe.org In-Reply-To: References: From: Sheda Date: Sun, 25 Mar 2018 14:52:29 +0200 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Niclas Zeising Cc: Kyle Evans , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 12:52:32 -0000 > > I've tested on two different computers, my ThinkPad x230 and my desktop > with a Intel DQ77MK motherboard. I've only done light testing such as > loading efirt.ko and running efibootmgr to check the boot settings, but i= t > has worked fine. > I also haven't seen any issues with console graphics on either machine. > Both computers are running CURRENT from yesterday, the desktop is on > r331481 and the laptop probably somewhere around that as well. > =E2=80=8BHi, I also would like to test the changes on my X230 but looking at =E2=80=8B https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most recent snapshot seems to be r331345. How did you get r331481? Regards, -S From owner-freebsd-current@freebsd.org Sun Mar 25 17:51:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0227F5DD67 for ; Sun, 25 Mar 2018 17:51:54 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CDCA70A07 for ; Sun, 25 Mar 2018 17:51:54 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: cgo82c8VM1lzG9I6Ziesmdtdg6LgIzBAmcsBuwyB.jlGra9BE31jEPEnwNkuoOv HqLXv_WIMSRjzHJD3y3rJESTzYIyh33wWrUUL6u248mV4yMogA180xavVtiGkadFWNS6EjcIzzm5 CH0aJX2h8ad2pQ7L7iixXQg5ti8h3oGKKPBA.MoylXAmg.ytGWGQyM1DomNlSGkZTtszp22qCcxG ADcjrTIul2tKJItwz6qRgXsIVNYT4yX0uFsC.9o3QLOFcVa7bUjnSO3HddALIVSxl6Z_jiLmRFhZ eBlv8Arvjn4dylrWl5v4kTlJci_9kxZcj4TdrFsZQjupms5l8GiRov7FBWfA6JepMZ_gOQSIRzYT 3qSH0qX5BWQXzwvulQO0XQKS9ByoFSWGpOsHrAX7WD41bIEevqAiHegTsGIiPXS2AltyxUKngEBy JQXxJkYyvdzufeVxXyN3vaEnVAqzutjW_ApsMQW.7CaZRCsM8mdqvBy2dxO8XQJ45QoGEhl57fQm FNnKSmwvnJQ.Clzq7_Ty70.eyKoGu1Pn3zQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Mar 2018 17:51:47 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d9a89e232fcac827685f8dd6e5b8e48b; Sun, 25 Mar 2018 17:41:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. Message-Id: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> Date: Sun, 25 Mar 2018 10:41:38 -0700 To: FreeBSD Current , FreeBSD Hackers , freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 17:51:55 -0000 FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" would get the "unnecessary swapping" problem in my UFS-only context, -r331499 (non-debug but with symbols), under Hyper-V. This is a Ryzen Threadripper context, but I've no clue if that is important to the problem. This was after 14 hours or so of building: . . . [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | = p5-Test-HTML-Tidy-1.00_1: Success [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | = ocaml-camlp5-6.16 So I've no clue if or how to repeat this. Unfortunately dump was unsuccessful. So all I have is the backtrace. Hand typed from a screen shot of the console window: cpuid =3D 18 time =3D 1521986594 KDB: stack backtrace: db_trace_self_srapper() at db_trace_self_srapper+0x2b/frame = 0xfffffe00f2e132a0 vpanic() at vpanic+0x18d/frame 0xfffffe00f2e13300 panic() at panic+0c43/frame 0xfffffe00f2e13360 vm_page_free_prep() at vm_page_free_prep+0x174/frame 0xfffffe00f2e13390 vm_page_free_toq() at vm_page_free_toq+0x11/frame 0xfffffe00f2e133b0 unlock_and_deallocate() at unlock_and_deallocate+0xbb/frame = 0xfffffe00f2e133d0 vm_fault_hold() at vm_fault_hold+0x1d04/frame 0xfffffe00f2e13500 proc_rwmem() at proc_rwmem+0x8d/frame 0xfffffe00f2e13570 proc_readmem() at proc_readmem+0x46/frame 0xfffffe00f2e135d0 get_proc_vector() at get_proc_vector+0x16e/frame 0xfffffe00f2e13660 proc_getauxv() at proc_getauxv+0x26/frame 0xfffffe00f2e136a0 elf64_note_procstat_auxv() at elf64_note_procstat_auxv+0x1ee/frame = 0xfffffe00f2e136f0 elf64_coredump() at elf64coredump+0x57c7/frame 0xfffffe00f2e137c0 sigexit() at sigexit+0x76f/frame 0xfffffe00f2e139b0 postsig() at postsig+0x289/frame 0xfffffe00f2e13a70 ast() at ast+0x357/frame 0xfffffe00f2e13ab0 doreti_ast() at doreti_ast+0x1f/frame 0x706d6f6320432041 KBD: enter: panic [ thread pid 61836 tid 101063 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why The Hyper-V/Ryzen-Threadripper context was/is: FreeBSD 12.0-CURRENT r331499M amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on = LLVM 6.0.0) SRAT: Ignoring memory at addr 0x1b28200000 VT(vga): text 80x25 Hyper-V Version: 10.0.16299 [SP0] = Features=3D0x2e7f PM Features=3D0x0 [C2] Features3=3D0xbed7b2 Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.73-MHz = K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1 = Stepping=3D1 = Features=3D0x1783fbff = Features2=3D0xfed83203 AMD Features=3D0x2e500800 AMD Features2=3D0x3f3 Structured Extended = Features=3D0x201c01a9 XSAVE Features=3D0xf AMD Extended Feature Extensions ID EBX=3D0x4 Hypervisor: Origin =3D "Microsoft Hv" real memory =3D 115964116992 (110592 MB) avail memory =3D 112847249408 (107619 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs FreeBSD/SMP: 1 package(s) x 29 core(s) (I leave 3 hardware threads and some of the 128 GiBytes of memory for Windows 10 Pro x64.) FreeBSD and its swap are directly on NVMe SSDs, not in NTFS file(s). The M in -r331499M is for powerpc64/powerpc/arm64/armv7 related experiments, not amd64: # svnlite status /usr/src/ | sort ? /usr/src/nohup.out ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/dts/arm/a83t.dtsi ? /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t.dtsi ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/modules/dtb/allwinner/Makefile M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/usr.bin/top/machine.c That last is because I've modified top to also report for swap: Maximum Observed Used (abbreviated: MaxObsUsed) when it is positive. For example: Swap: 256G Total, 483M Used, 483M MaxObsUsed, 256G Free =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Mar 25 18:34:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93049F61A5B for ; Sun, 25 Mar 2018 18:34:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 2592D72E64 for ; Sun, 25 Mar 2018 18:34:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id z7-v6so10198409iti.1 for ; Sun, 25 Mar 2018 11:34:27 -0700 (PDT) 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=lYFv2VjjBpzdWG4wH/bwmAvtSaFdHcckPR97cR1EMmY=; b=A7+Fihm0W90UeaVB0gklrzAZ57TK/r9PPLiQS34m+ei2phGOp+ow1RRsJsVwgFOQhQ KQZll5/sI9jBPg4tUWz8hefWxOKWMz9IwKty66LSIqeMNMfrgP/VdsYl59ArOxF7IPHc rrVNVSG3dbB5atY0tRyqj0v1NGFDEwwXNfV7MlqID/Z9ZiZsnpWYLt0PHf+S4dJ9flWe 2PG1iabRfaA802IR2tFHvLeWvrE6BDZHFAcHJ+xA4TxnseVXlWxTKCQNwiApjD42jaqR yYNXRZkyLLcYaHhNpfsgnOEogB8nwGFC90tU9gqI93MC/sgnPTyYvgOFAmxLJoxU6YQN GfdA== 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=lYFv2VjjBpzdWG4wH/bwmAvtSaFdHcckPR97cR1EMmY=; b=gnSdIbhFkDuZzlHg1V1PPHSGCxDYYbfNodYLZrv9fVD5Gi3OAwHljReUcl73KeVW4U LCbIgT8jadxXsT9mSKS0ceOkMwbzXujcTnhur8rtBRniCbATLuojNT6n3+RLpmOtj0sV Nng59w5to/w0PJam3e7e2hOKyf0NiShMDZ8APFBdLdx5jgRTgdDXqTmr8vYbvojfZqTt fe+yP7YmPk7/to9fVyu7HLJXFPa45I54baPeln8AaVzR+d+g+S5U0Y8qBFwKOp6E5mSk 9f8FraAuIX6/O1XyahOONyexdcU8/sEaF7xeW29h6iEqyOqhQrEKvuRARcnMK0dAgCkB 0x9Q== X-Gm-Message-State: AElRT7GpRxLmdLPCBFkB+nW9Za3c0bHfNAyRWAkhpwvn/w4Otheygzwu gXSWKpnx5ZRNU/9l4bgxF0F+Pw== X-Google-Smtp-Source: AIpwx4/NLcdbylNwIGAHj0YsQFW3YDVNQDCsD1Mv92XwQBSykUwdle18MNDFMRYHHTzBVlVLHKppmg== X-Received: by 2002:a24:9dd8:: with SMTP id f207-v6mr21453827itd.80.1522002866514; Sun, 25 Mar 2018 11:34:26 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-76-83.dsl.bell.ca. [174.88.76.83]) by smtp.gmail.com with ESMTPSA id m201sm2820376ioe.29.2018.03.25.11.34.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 11:34:25 -0700 (PDT) Sender: Mark Johnston Date: Sun, 25 Mar 2018 14:34:21 -0400 From: Mark Johnston To: Mark Millard Cc: FreeBSD Current Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. Message-ID: <20180325183421.GA74365@raichu> References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 18:34:27 -0000 On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote: > FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" > would get the "unnecessary swapping" problem in my UFS-only context, > -r331499 (non-debug but with symbols), under Hyper-V. This is a > Ryzen Threadripper context, but I've no clue if that is important > to the problem. This was after 14 hours or so of building: > > . . . > [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | p5-Test-HTML-Tidy-1.00_1: Success > [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16 > > So I've no clue if or how to repeat this. > > Unfortunately dump was unsuccessful. What happened? > So all I have is the > backtrace. Hand typed from a screen shot of the console > window: Do you know what the panic message was? There are multiple calls to panic() in vm_page_free_prep(). From owner-freebsd-current@freebsd.org Sun Mar 25 18:36:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3E8CF61D17 for ; Sun, 25 Mar 2018 18:36:31 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [104.225.8.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freebsd-11-64", Issuer "freebsd-11-64" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 769E472FBB; Sun, 25 Mar 2018 18:36:31 +0000 (UTC) (envelope-from andy@neu.net) Received: from neu.net (neu.net [104.225.8.138]) by mail.neu.net (8.15.2/8.15.2) with ESMTPS id w2PIaObX065628 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Mar 2018 14:36:24 -0400 (EDT) (envelope-from andy@neu.net) Date: Sun, 25 Mar 2018 14:36:23 -0400 (EDT) From: AN To: John Baldwin cc: freebsd-current@freebsd.org, "markj@FreeBSD.org" , "" Subject: Re: problem with [intr{swi4: clock (0)}] In-Reply-To: <1901802.BMbLzLVd8F@ralph.baldwin.cx> Message-ID: References: <1901802.BMbLzLVd8F@ralph.baldwin.cx> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 18:36:32 -0000 Hi: On Fri, 23 Mar 2018, John Baldwin wrote: > Date: Fri, 23 Mar 2018 12:11:03 -0700 > From: John Baldwin > To: freebsd-current@freebsd.org > Cc: AN , "markj@FreeBSD.org" , > "" > Subject: Re: problem with [intr{swi4: clock (0)}] > > On Wednesday, March 21, 2018 11:36:48 AM AN wrote: >> Hi: >> >> I would appreciate any help with this issue, this is a new machine built >> in the last week and if it is a hardware issue I want to return it. The >> problem seems to have started in the last 24 hours or so. I am seeing a >> really high cpu utilization for [intr{swi4: clock (0)}]. I have tried a >> couple things to troubleshoot: > > I would try using dtrace to figure out which functions are running in the > callout thread. I've cc'd a couple of folks in case they already have dtrace > scripts to do this. You would probably want a script that watched > callout_execute::callout-start and callout_execute::callout-end events. You > would want to save the start time in callout-start and then report a delta > along with the values of 'c->c_func' (the last argument to these probes is > 'c'). You might be able to just store the time delta in an aggregate that is > keyed on the function. Actually, I've gone ahead and written a little > script: > > ---- > callout_execute:::callout-start > { > self->start = timestamp; > self->func = args[0]->c_func; > @funcs[self->func] = count(); > } > > callout_execute:::callout-end > { > @functimes[self->func] = sum(timestamp - self->start); > } > > END > { > printf("\n\nCallout function counts:\n"); > printa("%@8u %a\n", @funcs); > printf("\nCallout function runtime:\n"); > printa("%@d %a\n", @functimes); > } > ---- > > Store this in a file named 'callout.d' and then run 'dtrace -s callout.d'. > Let it run for a second or two and then use Ctrl-C to stop it. > > The first table it will output is a histogram showing how many times > different functions were invoked. The second table will count how much > total time was spent in each function: > > CPU ID FUNCTION:NAME > 4 2 :END > > Callout function counts: > 2 kernel`kbdmux_kbd_intr_timo > 2 kernel`usb_power_wdog > 2 kernel`ipport_tick > 2 kernel`tcp_timer_delack > 2 kernel`nd6_timer > 2 kernel`key_timehandler > 2 dtrace.ko`dtrace_state_deadman > 4 kernel`newnfs_timer > 4 kernel`pfslowtimo > 10 kernel`logtimeout > 10 kernel`pffasttimo > 18 kernel`lim_cb > 32 kernel`iflib_timer > 84 kernel`sleepq_timeout > 224 dtrace.ko`dtrace_state_clean > > Callout function runtime: > 2080 kernel`logtimeout > 2198 kernel`kbdmux_kbd_intr_timo > 2890 kernel`ipport_tick > 3550 kernel`iflib_timer > 3672 kernel`lim_cb > 3936 kernel`pffasttimo > 4023 dtrace.ko`dtrace_state_clean > 4224 kernel`newnfs_timer > 4751 kernel`key_timehandler > 5286 kernel`nd6_timer > 6700 kernel`usb_power_wdog > 7341 kernel`pfslowtimo > 19607 kernel`tcp_timer_delack > 20273 dtrace.ko`dtrace_state_deadman > 32262 kernel`sleepq_timeout > > You can use this to figure out which timer events are using CPU in the > softclock thread/process. > > To John and others who responded thanks for your time. I have to apologize though for wasting your spare cpu cycles. It turns out the root cause was a malfunctioning USB keyboard with a stuck key. Removed and replaced, now everything is working normally. Thanks again and sorry for the noise. Best regards, Andy From owner-freebsd-current@freebsd.org Sun Mar 25 19:42:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9469CF67621 for ; Sun, 25 Mar 2018 19:42:22 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA4D7591F for ; Sun, 25 Mar 2018 19:42:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: FknwQ0MVM1n7Egl0SPjWl44c5tJFRTL0oQ8neJb9nCfRyjGfW9UNoXW8xR0zNuV TsMMmPjmC3czFia6m42ksG6kvv.xt0BujuP1cfkxgipg2.olr5ieMwC70q3wvVRDUMHa4AH2_EOr QvBBEtb9nrqmjr91gglKXWREMcO1Df6YLCVb.J0ZxRpU9YSPGLNqWDMtiQsjL8FpRB1XDW6JEyQh ebqRYo9wzfFTvQedp52cp1QK15AW7CZU3LeJfpZZKq_fYqPocB_uSjhY4ywIikOU._iB7IW0HmCC HIwvvHHIg_CGe6XLqOp.ECATy2ufhKTjwC1rPyN2owq.Yjse9iaq2bFDTjWTT9H38CE8BbQL2p3F gXiEfaEymBZbm1_PFzM5V25oFtaWiwJHvkUhU5LpFDEomIqf3tDvQAktIchGvTRXDljAk2Oijt0L NwlZUaxJUagwBtLWQ2FHyspm_jaTdl7BgDpM7PGVTmeT7sMosbvwzRPmdQeRaLfhnpXoJvH_m4K6 zNW2eDCCoYiBmVYc8otUssMWCTYf20hV5Qg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Mar 2018 19:42:20 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0ef222827c5f8cc48ba70450601ddce5; Sun, 25 Mar 2018 19:32:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. From: Mark Millard In-Reply-To: <20180325183421.GA74365@raichu> Date: Sun, 25 Mar 2018 12:32:09 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 19:42:22 -0000 On 2018-Mar-25, at 11:34 AM, Mark Johnston wrote: > On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote: >> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" >> would get the "unnecessary swapping" problem in my UFS-only context, >> -r331499 (non-debug but with symbols), under Hyper-V. This is a >> Ryzen Threadripper context, but I've no clue if that is important >> to the problem. This was after 14 hours or so of building: >>=20 >> . . . >> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | = p5-Test-HTML-Tidy-1.00_1: Success >> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | = ocaml-camlp5-6.16 >>=20 >> So I've no clue if or how to repeat this. >>=20 >> Unfortunately dump was unsuccessful.=20 >=20 > What happened? It reported: (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00 (da1:storvsc1:0:0:0) CAM status Command timeout (da1:storvsc1:0:0:0) Error 5, Retries exhausted Aborting dump to to I/O error. ** DUMP FAILED (ERROR 5) ** =3D 0x5 >> So all I have is the >> backtrace. Hand typed from a screen shot of the console >> window: >=20 > Do you know what the panic message was? There are multiple calls to > panic() in vm_page_free_prep(). No. I listed what I could see. The console screen does not have many lines or rows and I was sleeping when the panic happened. I redid a buildworld buildkernel installkernel installworld sequence since then and it looks like the detailed addresses changed (as seen in objdump now vs. what was on the console). But the relative offset in vm_page_free_prep seem to be a match, at least for the instruction after the "callq panic". Looking at the kernel code I see: . . . mov 0xffffffff81843690,%rax mov $0xffffffff81d6d880,%rcx sub %rcx,%rax addq $0x1,%gs:(%rax) mov 0x54(%rbx),%eax and $0x1,%eax jne . . . (several paths reach +0x106) movw $0x0,0x64(%rbx) cmpl $0x0,0x50(%rbx) jne . . . mov $0xffffffff8116628b,%rdi jmp mov $0xffffffff8120ca97,%rdi xor %eax,%eax mov %rbx,%rsi callq nopw %cs:0x0(%rax,%rax,1) No KASSERTS present (a non-debug build). That leaves: if (vm_page_sbusied(m)) panic("vm_page_free: freeing busy page %p", m); and: if (m->wire_count !=3D 0) panic("vm_page_free: freeing wired page %p", m); I do not have anything that lets me differentiate which occurred based on the above detail. Sorry. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Mar 25 20:09:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36E76F692D1 for ; Sun, 25 Mar 2018 20:09:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 BFC987654A for ; Sun, 25 Mar 2018 20:09:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id e79so20761339ioi.7 for ; Sun, 25 Mar 2018 13:09:37 -0700 (PDT) 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=XWJTc5w7gRp2iRQqN8UfSyJw3IcPF9vXpDw3OtYvvhA=; b=VOChhGKWFRxsngoRnrD53Oj97dCIs/XYmK81pRK4eEV8K1SuN+yWV9HtofmrO6lHuq wJWPXsabs4qWFHqrnZ1rDVIezIlqIXGFhIjs6XUWF9Y1MIrVX+LE6BOIldpBNs8R7hKK qBLBz/kRvkEDxOIL1Bt8Dz5guerYJWE5TaNCA/0tCm2d0vjHjbvHVXl7ZMsHrNc4jC0J ZhUEJxUqn02NC0l+8rQIGAUchsxRvPuXbd6lDnWiDZnEgvITZPDw2x0LGO30amGMWfko 4NN004BDzcxoTGGG3OvLGdsge6OdLMGmcTGfmsKf4CG3t4XFvfXmO6CVCsipHk5dCplB hejA== 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=XWJTc5w7gRp2iRQqN8UfSyJw3IcPF9vXpDw3OtYvvhA=; b=pzzkhGEjQTJb4dTL2k3v4jNzBqeI0C+WAc2D/1K59+brYZya/c/cKQIdVkigwAXOEe 5+UqnIR5ZyIkBZc7NLO3Gnyts6P+9wWaeg9HaIHySnDlsKnL6vzb02hmQ5J7PShBmb4Y vD5+MXn9+ayJz3XVUMPzXhpKKdzJKdfdeihZZtbyN3zqi6IP8IZqhn/eLezPE7XOGQ4O QFmsnEbBBAkg3k122L6cSmiMQkYx3xe5dWmYvOOBBJLj/B1be7PdVKzsS4QkRxV4zJ1l 4chyA/PxbQZdEBzJ5rDU1a6pK+WE5SMqxL6xVaQh5Z8S+v5CbQC+SlixLDd+fO0kDUkF 3xSw== X-Gm-Message-State: AElRT7EtX0SoIc2R9cNhZp1K4P9TVOqc9JR0WomHLEm1KrB8SFbYvLoQ u6wf4zMLeJwsvKyxHk0ojfo= X-Google-Smtp-Source: AG47ELthJNnEK/iMJxTN1WqgPODu6+E9C//+9oOzHH30mqm+JTwyMfUkqC3e8p8ZI2d+sKhtVep/DQ== X-Received: by 10.107.178.129 with SMTP id b123mr39995246iof.9.1522008577065; Sun, 25 Mar 2018 13:09:37 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-76-83.dsl.bell.ca. [174.88.76.83]) by smtp.gmail.com with ESMTPSA id z66-v6sm8883758itg.37.2018.03.25.13.09.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 13:09:36 -0700 (PDT) Sender: Mark Johnston Date: Sun, 25 Mar 2018 16:09:34 -0400 From: Mark Johnston To: Mark Millard Cc: FreeBSD Current Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. Message-ID: <20180325200934.GC74365@raichu> References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 20:09:38 -0000 On Sun, Mar 25, 2018 at 12:32:09PM -0700, Mark Millard wrote: > On 2018-Mar-25, at 11:34 AM, Mark Johnston wrote: > > > On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote: > >> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" > >> would get the "unnecessary swapping" problem in my UFS-only context, > >> -r331499 (non-debug but with symbols), under Hyper-V. This is a > >> Ryzen Threadripper context, but I've no clue if that is important > >> to the problem. This was after 14 hours or so of building: > >> > >> . . . > >> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | p5-Test-HTML-Tidy-1.00_1: Success > >> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16 > >> > >> So I've no clue if or how to repeat this. > >> > >> Unfortunately dump was unsuccessful. > > > > What happened? > > It reported: > > (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00 > (da1:storvsc1:0:0:0) CAM status Command timeout > (da1:storvsc1:0:0:0) Error 5, Retries exhausted > Aborting dump to to I/O error. > > ** DUMP FAILED (ERROR 5) ** > = 0x5 Thanks. Do you happen to know if this occurs consistently under Hyper-V? > >> So all I have is the > >> backtrace. Hand typed from a screen shot of the console > >> window: > > > > Do you know what the panic message was? There are multiple calls to > > panic() in vm_page_free_prep(). > > No. I listed what I could see. The console screen does not have many > lines or rows and I was sleeping when the panic happened. For future reference, you should be able to use "show panic" at the DDB prompt to get the panic message. From owner-freebsd-current@freebsd.org Sun Mar 25 20:12:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A7D5F696EA for ; Sun, 25 Mar 2018 20:12:28 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 13FD8768D2; Sun, 25 Mar 2018 20:12:27 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 408T2y0NxkzDhKG; Sun, 25 Mar 2018 20:12:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=daemonic.se; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=20151023; t=1522008745; bh=+tIuh1OTDw1rqXagZyM+AwEw +pJrofLRymfW4kDsJTw=; b=YdD0abWyBRu2g1p6VYIwSAV4ChFvPxMPWIrGK2Nu I0oDGc3lKqpUR74wBjiICSiWNpxUY8mvhaMheuwpF1/5uYFTs60s2yc9MBN+3DxX QQ13mp22pILFaPugYD1QbdtRu7DYm71O+c3JoO19xWR8at2rzb8hGoWYXJihA4nU yXY= X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id 5_i3W8ujvH4p; Sun, 25 Mar 2018 20:12:25 +0000 (UTC) Received: from [IPv6:2001:470:dca9:2:bd78:802f:e87e:7d35] (unknown [IPv6:2001:470:dca9:2:bd78:802f:e87e:7d35]) by mail.daemonic.se (Postfix) with ESMTPSA id 408T2w6r4JzDh2K; Sun, 25 Mar 2018 20:12:24 +0000 (UTC) Subject: Re: Call for Testing: UEFI Changes To: sheda@fsfe.org Cc: Kyle Evans , FreeBSD Current References: From: Niclas Zeising Message-ID: Date: Sun, 25 Mar 2018 22:12:24 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 20:12:28 -0000 On 2018-03-25 14:52, Sheda wrote: >> >> I've tested on two different computers, my ThinkPad x230 and my deskto= p >> with a Intel DQ77MK motherboard. I've only done light testing such as >> loading efirt.ko and running efibootmgr to check the boot settings, bu= t it >> has worked fine. >> I also haven't seen any issues with console graphics on either machine= . >> Both computers are running CURRENT from yesterday, the desktop is on >> r331481 and the laptop probably somewhere around that as well. >> >=20 > =E2=80=8BHi, >=20 > I also would like to test the changes on my X230 but looking at =E2=80=8B > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most > recent snapshot seems to be r331345. How did you get r331481? >=20 Hi! I updated my FreeBSD system from source. There are instructions here https://www.freebsd.org/doc/handbook/current-stable.html and here https://www.freebsd.org/doc/handbook/makeworld.html on how to do it. Regards --=20 Niclas From owner-freebsd-current@freebsd.org Sun Mar 25 20:15:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7743AF69BA9 for ; Sun, 25 Mar 2018 20:15:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic302-22.consmr.mail.ne1.yahoo.com (sonic302-22.consmr.mail.ne1.yahoo.com [66.163.186.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F52176B1C for ; Sun, 25 Mar 2018 20:15:20 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: TdXEHmUVM1mcKjGg7cNUl6EpCmTbCWwfTi8e2qImOUDamJV14j0FiMsFSaGc9w2 Oo2g7o7.0CYsswrGXebKJMxmowg1JM1G82nrZyLy_.08b2iPcnq4ngiNVa5xROOq.P1h3Ee8hxLc KikPPgOpZAUQXoXfi3NeVpGe6Co2S6s0fE03fahHSXagFQahRtaKs70Ofl81TpBZYbCUqHFyP1ub sJy09WKVKJGxsmPWi9xcv3Cr3RVK_SeWX7k.SJzkV1EhL22qAuQQ5uL1Fkb_iTbkx3iMRM6yFzCn kW2Gij13DY3sKFLRkECwp3NwJOVtpPeTANpvxk2dfOdNbsxgDmNNFPUkl_ryZ3RaiZ5qURtmRo6L n7Q9axRm_wWvrmFzPt2bMQthx8M3d8hjD0KbhkeZfRmsK1kt.qM2.5XAyR8q.1KE6wgTrCiaKmZ7 L1IMlojjziBZJOm9q95whirUgsQKzs7Seae9XrlyGTtn8okuLaNw7Nksl_jfm5TTDQUu9jmry9B3 0Uz_R2rfLywQkjqvTxOGnnMB2PSyvv8pyeA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 25 Mar 2018 20:15:14 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1b9ad79fa0ebea0c84e2a9c2e4626a66; Sun, 25 Mar 2018 20:15:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. Date: Sun, 25 Mar 2018 13:15:08 -0700 References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> To: Mark Johnston , FreeBSD Current In-Reply-To: <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> Message-Id: <0612D846-F99F-4C55-AAD2-C2BCE098F069@yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 20:15:21 -0000 [Just an added note about where in the sequence panic messages are sent to the console vs. could potentially be sent to the console.] > On 2018-Mar-25, at 12:32 PM, Mark Millard wrote: >=20 > On 2018-Mar-25, at 11:34 AM, Mark Johnston = wrote: >=20 >> On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote: >>> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" >>> would get the "unnecessary swapping" problem in my UFS-only context, >>> -r331499 (non-debug but with symbols), under Hyper-V. This is a >>> Ryzen Threadripper context, but I've no clue if that is important >>> to the problem. This was after 14 hours or so of building: >>>=20 >>> . . . >>> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | = p5-Test-HTML-Tidy-1.00_1: Success >>> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | = ocaml-camlp5-6.16 >>>=20 >>> So I've no clue if or how to repeat this. >>>=20 >>> Unfortunately dump was unsuccessful.=20 >>=20 >> What happened? >=20 > It reported: >=20 > (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00 > (da1:storvsc1:0:0:0) CAM status Command timeout > (da1:storvsc1:0:0:0) Error 5, Retries exhausted > Aborting dump to to I/O error. >=20 > ** DUMP FAILED (ERROR 5) ** > =3D 0x5 >=20 >>> So all I have is the >>> backtrace. Hand typed from a screen shot of the console >>> window: >>=20 >> Do you know what the panic message was? There are multiple calls to >> panic() in vm_page_free_prep(). >=20 > No. I listed what I could see. The console screen does not have many > lines or rows and I was sleeping when the panic happened. I sometimes wonder if panic should repeat the panic message at the end of the backtrace in order to deal with keeping it visible in row-restricted console contexts. > I redid a buildworld buildkernel installkernel installworld sequence > since then and it looks like the detailed addresses changed (as seen > in objdump now vs. what was on the console). But the relative offset > in vm_page_free_prep seem to be a match, at least for the instruction > after the "callq panic". >=20 > Looking at the kernel code I see: >=20 > . . . > mov 0xffffffff81843690,%rax > mov $0xffffffff81d6d880,%rcx > sub %rcx,%rax > addq $0x1,%gs:(%rax) > mov 0x54(%rbx),%eax > and $0x1,%eax > jne > . . . > (several paths reach +0x106) > movw $0x0,0x64(%rbx) > cmpl $0x0,0x50(%rbx) > jne > . . . > mov $0xffffffff8116628b,%rdi > jmp > mov $0xffffffff8120ca97,%rdi > xor %eax,%eax > mov %rbx,%rsi > callq > nopw %cs:0x0(%rax,%rax,1) >=20 > No KASSERTS present (a non-debug build). That leaves: >=20 > if (vm_page_sbusied(m)) > panic("vm_page_free: freeing busy page %p", m); > and: >=20 > if (m->wire_count !=3D 0) > panic("vm_page_free: freeing wired page %p", m); >=20 > I do not have anything that lets me differentiate which > occurred based on the above detail. Sorry. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Mar 25 21:18:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A13F6F6E23B for ; Sun, 25 Mar 2018 21:18:44 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic305-4.consmr.mail.bf2.yahoo.com (sonic305-4.consmr.mail.bf2.yahoo.com [74.6.133.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48B6678DC2 for ; Sun, 25 Mar 2018 21:18:44 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ERY2SRYVM1lkUSXIKi8XxOup95qduZBlHPuUJHP8rPEUAwbnMMQQfk9PtYVsjxh JeDSIVeAmMYt3Mgm9MK.87C9siNFiBrRDtTZyvoKLBdPLzaGkaCT90docgehKRJ5pfDMmfaBRKfM dxc7JI0X0X2a7BGdEaYp70.CpWCIdeamdN9mntIEjNztbtjI7AnIqEvDPkCOqQrN6pLMPMt_n3q5 Vc2wDR7.Cyfge3esdWftYGf.ZBVWFlyKT7xjG.zaq1ueaHmLRz_DCtdSIxfzaG4vqMIsuzA4LT8w AkpfFjM9gKb9.GeaynLo6.o.t2oQba1OHn4PtdEAzbYQMUdtY.YAQt0hDpwE8xrIF2sqLznnZ4Q9 4tt.jUbmyXh_QHzHruCBZDKO_qjwfF3A4PfSk4YC9PLD4yc2JX.0bU.NrNaHKU_XkgK1fobIfHr7 61MpMbE0gjdbnf2bZyDA9Jf8_spd8x2oKSmmUsUGvJakW5Sl5x9nNsrVLCyVuyc.NJ_Jv0vnOb1p _ZI3jFo5EjGO7rT9JKpR27xc9cX_Urybysg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sun, 25 Mar 2018 21:18:38 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5611ef738cfaf7e683e36130aa553b6f; Sun, 25 Mar 2018 20:48:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. From: Mark Millard In-Reply-To: <20180325200934.GC74365@raichu> Date: Sun, 25 Mar 2018 13:48:14 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <45B4FCDA-C743-4F35-B819-9CB064C20038@yahoo.com> References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> <20180325200934.GC74365@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 21:18:44 -0000 On 2018-Mar-25, at 1:09 PM, Mark Johnston wrote: > On Sun, Mar 25, 2018 at 12:32:09PM -0700, Mark Millard wrote: >> On 2018-Mar-25, at 11:34 AM, Mark Johnston = wrote: >>=20 >>> On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote: >>>> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" >>>> would get the "unnecessary swapping" problem in my UFS-only = context, >>>> -r331499 (non-debug but with symbols), under Hyper-V. This is a >>>> Ryzen Threadripper context, but I've no clue if that is important >>>> to the problem. This was after 14 hours or so of building: >>>>=20 >>>> . . . >>>> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | = p5-Test-HTML-Tidy-1.00_1: Success >>>> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | = ocaml-camlp5-6.16 >>>>=20 >>>> So I've no clue if or how to repeat this. >>>>=20 >>>> Unfortunately dump was unsuccessful.=20 >>>=20 >>> What happened? >>=20 >> It reported: >>=20 >> (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00 >> (da1:storvsc1:0:0:0) CAM status Command timeout >> (da1:storvsc1:0:0:0) Error 5, Retries exhausted >> Aborting dump to to I/O error. >>=20 >> ** DUMP FAILED (ERROR 5) ** >> =3D 0x5 >=20 > Thanks. Do you happen to know if this occurs consistently under = Hyper-V? For both "this" being (A) the panic and (B) the attempt to dump to the Optane SSD that holds the swap/page partition: First ever occurrence of the activity, so nothing to compare with. The system sat at the db> prompt for a notable time while I was sleeping. It kept its "cores" busy while I slept. (Hardware threads being very active is visible from Windows 10 Pro x64's Task Manager.) It is rare that I try such a large bulk build. I do such mostly just to test how well the Ryzen Threadripper context seems to be doing or to otherwise test something about FreeBSD stability. I do buildworld buildkernel for such testing as well. Sometimes both poudriere ports-building and FreeBSD-building in parallel for a time. I have started "poudriere bulk -j -w -a" again, letting it continue from where it left off. >>>> So all I have is the >>>> backtrace. Hand typed from a screen shot of the console >>>> window: >>>=20 >>> Do you know what the panic message was? There are multiple calls to >>> panic() in vm_page_free_prep(). >>=20 >> No. I listed what I could see. The console screen does not have many >> lines or rows and I was sleeping when the panic happened. >=20 > For future reference, you should be able to use "show panic" at the = DDB > prompt to get the panic message. Dahhhh. Too obvious of a thing for me to think of checking for such on my own. At least now I know. (It is not the first time that I could have used that command.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Mar 25 23:20:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC4C6F51435; Sun, 25 Mar 2018 23:20:51 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36E957ECA2; Sun, 25 Mar 2018 23:20:50 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id w2PNBW7a071046 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 01:11:34 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1522019494; bh=CkEcqrfFasXZKWcV1EseexUvBaOvBehCul1rL4PO5Bg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=3k1Rfx4QhznOVRPlD2+qr/knVbash3KH+Fc6DV7ai9vE23qt+qHATkoDF/dohKR9Z hUGmFL2HhO/uvpy93V54Zwk1KOFrM7T21xsb2Wd+TqjYt4xPR72SfKnrRh5U29VnNN jtAep3M4pn7meVjJrksjNPWd9WLfBMtP8yN3ByOA= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id w2PNBTJ2028393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 01:11:29 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id w2PNBTeg016794 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Mar 2018 01:11:29 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id w2PNBS6H016793; Mon, 26 Mar 2018 01:11:28 +0200 (CEST) (envelope-from ticso) Date: Mon, 26 Mar 2018 01:11:28 +0200 From: Bernd Walter To: Hans Petter Selasky Cc: Bernd Walter , freebsd-arm@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: webcamd based touchscreen problem on Pi3 Message-ID: <20180325231128.GA16646@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20180308200849.GC86413@cicely7.cicely.de> <20180308210805.GE86413@cicely7.cicely.de> <20180309004433.GI86413@cicely7.cicely.de> <4765ef04-6fb1-f9dc-315d-c4419d6ba016@selasky.org> <20180309114025.GJ86413@cicely7.cicely.de> <20180309132539.GL86413@cicely7.cicely.de> <20180310000336.GM86413@cicely7.cicely.de> <20180312111246.GA14138@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180312111246.GA14138@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 23:20:51 -0000 On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote: > On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote: > > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote: > > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but > > it always needed some special binary support for Linux, no surprises here. > > The newer Rev 2.1 with the IPS panel claims to be the same and work with > > webcamd, at least I get data via /dev/input/event0, which looks reasonable > > with evdev-dump. > > That's an interesting starting point. > > I've got a new model of the 10" HDMI B. > It behaves differently. > First of all - uep seems to take it, which it didn't for any of > the previous displays I'd tested. > I had to remove the driver from the loader.conf to have webcamd attach to it. > webcamd attaches fine and it delivers touch events: > [29]sa# evdev-dump /dev/input/event0 > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x00000000 > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x000001CF > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x0000025E > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x00000005 > /dev/input/event0 3041705595.425438 EV_KEY BTN_TOUCH 0x00000001 > /dev/input/event0 3041705595.425438 EV_ABS ABS_X 0x000001CF > /dev/input/event0 3041705595.425438 EV_ABS ABS_Y 0x0000025E > /dev/input/event0 3041705595.425438 EV_ABS ABS_PRESSURE 0x00000005 > /dev/input/event0 3041705595.425438 EV_SYN SYN_REPORT 0x00000000 > > Whatever had been the cause for my previous problem, they obviously > have fixed them in firmware. Unfortunately I still have some problems. [63]sa# evdev-dump /dev/input/event1 /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x0000003F /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x000001C9 /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x00000112 /dev/input/event1 3043946310.664423 EV_KEY BTN_TOUCH 0x00000001 /dev/input/event1 3043946310.664423 EV_ABS ABS_X 0x000001C9 /dev/input/event1 3043946310.664423 EV_ABS ABS_Y 0x00000112 /dev/input/event1 3043946310.664423 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF /dev/input/event1 3043946310.784395 EV_KEY BTN_TOUCH 0x00000000 /dev/input/event1 3043946310.784395 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x00000040 /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x000001CE /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x000000FE /dev/input/event1 3043946316.944324 EV_KEY BTN_TOUCH 0x00000001 /dev/input/event1 3043946316.944324 EV_ABS ABS_X 0x000001CE /dev/input/event1 3043946316.944324 EV_ABS ABS_Y 0x000000FE /dev/input/event1 3043946316.944324 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF /dev/input/event1 3043946317.004303 EV_KEY BTN_TOUCH 0x00000000 /dev/input/event1 3043946317.004303 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x00000041 /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x0000020E /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x000000D8 /dev/input/event1 3043946319.744283 EV_KEY BTN_TOUCH 0x00000001 /dev/input/event1 3043946319.744283 EV_ABS ABS_X 0x0000020E /dev/input/event1 3043946319.744283 EV_ABS ABS_Y 0x000000D8 /dev/input/event1 3043946319.744283 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF /dev/input/event1 3043946319.864240 EV_KEY BTN_TOUCH 0x00000000 /dev/input/event1 3043946319.864240 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x00000042 /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x00000209 /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x000000CD /dev/input/event1 3043946322.004229 EV_KEY BTN_TOUCH 0x00000001 /dev/input/event1 3043946322.004229 EV_ABS ABS_X 0x00000209 /dev/input/event1 3043946322.004229 EV_ABS ABS_Y 0x000000CD /dev/input/event1 3043946322.004229 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x0000016A /dev/input/event1 3043946325.454187 EV_ABS ABS_MT_POSITION_Y 0x000000D2 /dev/input/event1 3043946325.454187 EV_ABS ABS_X 0x0000016A /dev/input/event1 3043946325.454187 EV_ABS ABS_Y 0x000000D2 /dev/input/event1 3043946325.454187 EV_SYN SYN_REPORT 0x00000000 /dev/input/event1 3043946325.574174 EV_ABS ABS_MT_POSITION_X 0x0000016B /dev/input/event1 3043946325.574174 EV_ABS ABS_X 0x0000016B /dev/input/event1 3043946325.574174 EV_SYN SYN_REPORT 0x00000000 All 5 blocks are a single touch, which means finger on screen for a short moment. On the first 3 I get position data and BTN_TOUCH 1 as well as BTN_TOUCH 0. But this is not consistent, sometime I get only a 1 and sometime only a 0. In the 5th block I even got neither. The timestamps on the first 3 cases mark it clearly when I removed the finger. I got a 1 on touch-start and a 0 on touch-end. On the 4th case I got a touch-start, but no touch-end. In the 5th case I only got positon updates. This is a 7" display - the 10" also delivers ABS_PRESSURE, but the problem is the same that I don't consistently get the EV_KEY events. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@freebsd.org Sun Mar 25 23:28:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC3DBF51E3A; Sun, 25 Mar 2018 23:28:34 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E1BA7F392; Sun, 25 Mar 2018 23:28:12 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id w2PNS9Sw071354 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 01:28:10 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1522020490; bh=VubS/0LaKOWVIVOL3Am5oA7IKyw1122woxh654WKtfI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=l9peoG7O6Abz76QSXAYJE9hGrnrflZCAP56Y90Babss7Xz+2xcfUVzsFCz3Qaz/TM XxHx98/jQerOIGKDCPxZJ+YN36305L82iW372BFv48kYK+ibdHS5nQhXS1T39Tl//8 XinCckesSOk1BQY2WqYWrsolMdtU4+c2EaoG8M6o= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id w2PNS6Fh028573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 01:28:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id w2PNS6iq016877 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Mar 2018 01:28:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id w2PNS6V1016876; Mon, 26 Mar 2018 01:28:06 +0200 (CEST) (envelope-from ticso) Date: Mon, 26 Mar 2018 01:28:06 +0200 From: Bernd Walter To: Hans Petter Selasky Cc: Bernd Walter , freebsd-arm@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: webcamd based touchscreen problem on Pi3 Message-ID: <20180325232806.GB16646@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20180308210805.GE86413@cicely7.cicely.de> <20180309004433.GI86413@cicely7.cicely.de> <4765ef04-6fb1-f9dc-315d-c4419d6ba016@selasky.org> <20180309114025.GJ86413@cicely7.cicely.de> <20180309132539.GL86413@cicely7.cicely.de> <20180310000336.GM86413@cicely7.cicely.de> <20180312111246.GA14138@cicely7.cicely.de> <20180325231128.GA16646@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180325231128.GA16646@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 23:28:35 -0000 On Mon, Mar 26, 2018 at 01:11:28AM +0200, Bernd Walter wrote: > On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote: > > On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote: > > > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote: > > > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but > > > it always needed some special binary support for Linux, no surprises here. > > > The newer Rev 2.1 with the IPS panel claims to be the same and work with > > > webcamd, at least I get data via /dev/input/event0, which looks reasonable > > > with evdev-dump. > > > That's an interesting starting point. > > > > I've got a new model of the 10" HDMI B. > > It behaves differently. > > First of all - uep seems to take it, which it didn't for any of > > the previous displays I'd tested. > > I had to remove the driver from the loader.conf to have webcamd attach to it. > > webcamd attaches fine and it delivers touch events: > > [29]sa# evdev-dump /dev/input/event0 > > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x00000000 > > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x000001CF > > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x0000025E > > /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x00000005 > > /dev/input/event0 3041705595.425438 EV_KEY BTN_TOUCH 0x00000001 > > /dev/input/event0 3041705595.425438 EV_ABS ABS_X 0x000001CF > > /dev/input/event0 3041705595.425438 EV_ABS ABS_Y 0x0000025E > > /dev/input/event0 3041705595.425438 EV_ABS ABS_PRESSURE 0x00000005 > > /dev/input/event0 3041705595.425438 EV_SYN SYN_REPORT 0x00000000 > > > > Whatever had been the cause for my previous problem, they obviously > > have fixed them in firmware. > > Unfortunately I still have some problems. > [63]sa# evdev-dump /dev/input/event1 > /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x0000003F > /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x000001C9 > /dev/input/event1 3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x00000112 > /dev/input/event1 3043946310.664423 EV_KEY BTN_TOUCH 0x00000001 > /dev/input/event1 3043946310.664423 EV_ABS ABS_X 0x000001C9 > /dev/input/event1 3043946310.664423 EV_ABS ABS_Y 0x00000112 > /dev/input/event1 3043946310.664423 EV_SYN SYN_REPORT 0x00000000 > /dev/input/event1 3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF > /dev/input/event1 3043946310.784395 EV_KEY BTN_TOUCH 0x00000000 > /dev/input/event1 3043946310.784395 EV_SYN SYN_REPORT 0x00000000 > > > > > /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x00000040 > /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x000001CE > /dev/input/event1 3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x000000FE > /dev/input/event1 3043946316.944324 EV_KEY BTN_TOUCH 0x00000001 > /dev/input/event1 3043946316.944324 EV_ABS ABS_X 0x000001CE > /dev/input/event1 3043946316.944324 EV_ABS ABS_Y 0x000000FE > /dev/input/event1 3043946316.944324 EV_SYN SYN_REPORT 0x00000000 > /dev/input/event1 3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF > /dev/input/event1 3043946317.004303 EV_KEY BTN_TOUCH 0x00000000 > /dev/input/event1 3043946317.004303 EV_SYN SYN_REPORT 0x00000000 > > > > /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x00000041 > /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x0000020E > /dev/input/event1 3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x000000D8 > /dev/input/event1 3043946319.744283 EV_KEY BTN_TOUCH 0x00000001 > /dev/input/event1 3043946319.744283 EV_ABS ABS_X 0x0000020E > /dev/input/event1 3043946319.744283 EV_ABS ABS_Y 0x000000D8 > /dev/input/event1 3043946319.744283 EV_SYN SYN_REPORT 0x00000000 > /dev/input/event1 3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0xFFFFFFFF > /dev/input/event1 3043946319.864240 EV_KEY BTN_TOUCH 0x00000000 > /dev/input/event1 3043946319.864240 EV_SYN SYN_REPORT 0x00000000 > > > > /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x00000042 > /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x00000209 > /dev/input/event1 3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x000000CD > /dev/input/event1 3043946322.004229 EV_KEY BTN_TOUCH 0x00000001 > /dev/input/event1 3043946322.004229 EV_ABS ABS_X 0x00000209 > /dev/input/event1 3043946322.004229 EV_ABS ABS_Y 0x000000CD > /dev/input/event1 3043946322.004229 EV_SYN SYN_REPORT 0x00000000 > > > > > /dev/input/event1 3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x0000016A > /dev/input/event1 3043946325.454187 EV_ABS ABS_MT_POSITION_Y 0x000000D2 > /dev/input/event1 3043946325.454187 EV_ABS ABS_X 0x0000016A > /dev/input/event1 3043946325.454187 EV_ABS ABS_Y 0x000000D2 > /dev/input/event1 3043946325.454187 EV_SYN SYN_REPORT 0x00000000 > /dev/input/event1 3043946325.574174 EV_ABS ABS_MT_POSITION_X 0x0000016B > /dev/input/event1 3043946325.574174 EV_ABS ABS_X 0x0000016B > /dev/input/event1 3043946325.574174 EV_SYN SYN_REPORT 0x00000000 > > All 5 blocks are a single touch, which means finger on screen for a short > moment. > On the first 3 I get position data and BTN_TOUCH 1 as well as BTN_TOUCH 0. > But this is not consistent, sometime I get only a 1 and sometime only a 0. > In the 5th block I even got neither. > The timestamps on the first 3 cases mark it clearly when I removed the finger. > I got a 1 on touch-start and a 0 on touch-end. > On the 4th case I got a touch-start, but no touch-end. > In the 5th case I only got positon updates. > This is a 7" display - the 10" also delivers ABS_PRESSURE, but the problem > is the same that I don't consistently get the EV_KEY events. I somehow suspect that the device is dropping data, when the driver isn't retrieving it fast enough. I can't say for sure however, because usbdump has more interupt packets than there is events on the /dev/input , although X and Y coordinates come in the same packet. But I couldn't isolate the button packets yet. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@freebsd.org Mon Mar 26 02:29:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D761FF60DA2 for ; Mon, 26 Mar 2018 02:29:10 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id D6AB185AD5 for ; Mon, 26 Mar 2018 02:29:09 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-25-90.bras1.adl4.internode.on.net (HELO midget.dons.net.au) ([118.210.25.90]) by ipmail07.adl2.internode.on.net with ESMTP; 26 Mar 2018 12:54:03 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w2Q2Ne8v039491 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 26 Mar 2018 12:53:57 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w2Q24cYa025778 for ; Mon, 26 Mar 2018 12:34:38 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [203.31.81.59] ([203.31.81.59]) by ppp118-210-25-90.bras1.adl4.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id w2Q24Wbg025760; Mon, 26 Mar 2018 12:34:38 +1030 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Testing requested: Hybrid ISO/USB boot From: "O'Connor, Daniel" In-Reply-To: <35FF5A67-B8CA-43C8-B39E-6797066CBD7E@FreeBSD.org> Date: Mon, 26 Mar 2018 12:34:31 +1030 Cc: Thomas Schmitt , FreeBSD Hackers , FreeBSD current Message-Id: <2EE00D68-73CA-4832-8057-54D741BCC5BE@dons.net.au> References: <3373772881814803857@scdbackup.webframe.org> <35FF5A67-B8CA-43C8-B39E-6797066CBD7E@FreeBSD.org> To: Benno Rice X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Score: 2.8 (**) No, score=2.8 required=5.0 tests=HELO_MISC_IP, HTML_IMAGE_ONLY_24, HTML_MESSAGE, RDNS_NONE autolearn=no autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 02:29:11 -0000 > On 24 Mar 2018, at 07:31, Benno Rice wrote: > I think I=E2=80=99ve addressed this in this revision: >=20 > https://svnweb.freebsd.org/changeset/base/331463 = >=20 > And I=E2=80=99ve regenerated the image here: >=20 > https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz = Hi Benno, I tried this image on a Supermicro SYS-5019S-M (X11SSH-Fmotherboard) and = it boots both ways (USB was via a USB stick, ISO was via the IPMI CD = emulation with the Java JNLP applet) The USB way booted legacy and the CD emulation booted UEFI (not sure if = that's significant). I also tried renaming it to .img and then telling the JNLP applet it was = a hard disk image but the BIOS didn't detect it. It also has a 'Web ISO' option but I can't figure out how you're = supposed to enter a URL so I couldn't try it. Thanks for the work! -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Mon Mar 26 13:35:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7D9EF6D7B5 for ; Mon, 26 Mar 2018 13:35:38 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic303-22.consmr.mail.gq1.yahoo.com (sonic303-22.consmr.mail.gq1.yahoo.com [98.137.64.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7021A7DFFC for ; Mon, 26 Mar 2018 13:35:38 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 69jbsYAVM1nRbk8wziH146mD6X1kplk_0QegOAYxB.9bFrGyVpb6gb4MW4ZZd78 DUOhDtmW6lg4i9G7csKvAmUHwT_IKkEwBgROaQNn5.TTZVgGKrSgbGpiA3E1oeK06NYil6cuE.zS doOx61qanFLJ_RHMYQGI9pdNlDZ2QxUvPP_ydFN7yko6F4VNGDeptRXlBqKbPvwF8CIg337frGch 0YBMyHxfjM8CZ60cbB9LWN4puP2H84MstGRcdrci16.1D31GefNHxtJ_m5oKpFYVObwXxXwt.z7O mQu2dZEimDyRbFxdWaD6Cux9HiVNc6wjOTyA6LV5wgL.gdzEorOkDQl7u8.M0TsZ7NHJkXiclxDY .rkLO2umpOJsUcd11fyFu_HCmdhB6gUDxzbU.8AGB7J6fsRHJyq2bYOKLECshuOgzrrj6J.EfwYc XLwEaOActVcm8Hv5FV7yq0I6NsJD6n_OsRWsSdR1t8Rgaa_9ndgufxLgf3kGtHsd2H2e.VlZB_ed iar061Z61N_NPjMTedgbrj0x7rK6dDKzB3Hyk Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Mar 2018 13:35:31 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7ba435dd53eb2d74c7e5eb9129344802; Mon, 26 Mar 2018 13:35:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. From: Mark Millard In-Reply-To: <45B4FCDA-C743-4F35-B819-9CB064C20038@yahoo.com> Date: Mon, 26 Mar 2018 06:35:29 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <08B7C130-A38D-473A-8A73-CA79ED1A0044@yahoo.com> References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> <20180325200934.GC74365@raichu> <45B4FCDA-C743-4F35-B819-9CB064C20038@yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 13:35:39 -0000 [Unfortunately, I'd not be able to get back to this for many hours. I do not want to leave the machine at the db> prompt that long. So this is all there will be.] It got a different crash last night, after a little over 12 hours of poudriere bulk -a activity, again while I was sleeping. Hand typed: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 13; apic id = 0d fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b70867 stack pointer = 0x28:0xfffffe00ebab8880 frame pointer = 0x28:0xfffffe00ebab8890 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 44 (dom0) [ thread pid 44 tid 100277 ] Stopped at turnstile_broadcast+0x47: movq 0x20(%rbx,%rax,1),%rcx (So an offset from a null pointer, apparently.) bt shows: Tracing pid 44 tid 100277 td 0xfffff8010f938560 turnstile_broadcast() at turnstile_broadcast+0x47/frame 0xfffffe00ebab8890 __mtx_unlock_sleep() at __mtx_unlock_sleep+0xb9/frame 0xfffffe00ebab88c0 vm_pageout_page_lock() at vm_pageout_page_lock+0x179/frame 0xfffffe00ebab8960 vm_pageout_worker() at vm_pageout_worker+0xd3a/frame 0xfffffe00ebab8a50 vm_pageout() at vm_pageout+0x133/frame 0xfffffe00ebab8a70 fork_exit() at fork_exit+0x83/frame 0xfffffe00ebab8ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00ebab8ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Dump again failed, the same way but with some byte value differences. (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 39 8c c7 00 00 08 00 (da1:storvsc1:0:0:0) CAM status Command timeout (da1:storvsc1:0:0:0) Error 5, Retries exhausted Aborting dump to to I/O error. ** DUMP FAILED (ERROR 5) ** Cannot dump: unknown error (error=5) So this appears to be repeatable (for the Optane swap/page partition?). show reg: cs 0x20 ds 0x3b ll+0x1a es 0x3b ll+0x1a fs 0x13 gs 0x1b ss 0x28 ll+0x7 rax 0 rcx 0xfffff8010f938501 rdx 0xfffff8010f938501 rbx 0xfffffe00ebab8880 rsp 0xfffffe00ebab8800 rsi 0 rdi 0 r8 0 r9 0 r10 0 r11 0 r12 0 r13 0xfffff8010f938560 r14 0 r15 0xffffffff81d67998 vm_dom+0x18 rip 0xffffffff80b70867 turnstile_broadcast+0x47 rflags 0x10056 turnstile_broadcast+0x47: movq 0x20(%rbx,%rax,1),%rcx Around where rbx points: 0xfffffe00ebab8872: ab eb 0 fe ff ff 28 0 0 0 0 0 0 0 0xfffffe00ebab8880: 0 0 0 0 0 0 0 0 80 79 d6 81 ff ff 0xfffffe00ebab888e: ff ff c0 88 ab eb 0 fe ff ff 9 20 af 80 0xfffffe00ebab889c: ff ff ff ff 0 7b 2 d8 f f8 ff ff 98 79 And it looks like we have that null pointer above. And I'm afraid that is it: I need to be off doing other things. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Mar 26 21:50:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 652BAF6E79D; Mon, 26 Mar 2018 21:50:47 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 11DFB75DF8; Mon, 26 Mar 2018 21:50:46 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 664305646B; Mon, 26 Mar 2018 16:44:34 -0500 (CDT) To: freebsd-hackers@freebsd.org, FreeBSD Current From: Eric van Gyzen Subject: Realtek RTS525A SD card reader Message-ID: Date: Mon, 26 Mar 2018 16:44:33 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 21:50:47 -0000 Is anyone working on a FreeBSD driver for the Realtek RTS525A SD card reader?  My new Dell XPS 13 has one: none7@pci0:59:0:0: class=0xff0000 card=0x075b1028 chip=0x525a10ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS525A PCI Express Card Reader' I see that the OpenBSD rtsx driver supports it: https://github.com/openbsd/src/commit/2c295edd2d779a7f5269c2ae901559edbf040016 I don't know anything about SD/MMC devices and standards, and I'm not familiar with FreeBSD's current SD/MMC code, but I think it would be fun to learn.  Does it make sense to try porting this driver, or would someone recommend a different approach? Thanks in advance for any advice. Eric From owner-freebsd-current@freebsd.org Tue Mar 27 02:15:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3235F645B8; Tue, 27 Mar 2018 02:15:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90DDC84F39; Tue, 27 Mar 2018 02:15:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x231.google.com with SMTP id h143-v6so5498929ita.4; Mon, 26 Mar 2018 19:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=vERJlQCInH5avX7G0mt4XuzWHKG2QRQA8VXjgP0l5L8=; b=l/xvyjVgtyZDv6pI6/6Diz3TutpPv7wKoTc0oSN8Oovu2oxOsQz9LureuP2tGiC7la AfsJwy2vgaEnFzNiFHMcnGq4xvtynScYVEVQUKUnVj9tQI0QRtR9a7rqVNNXEvgkqmk/ fUf3+Bw9bxAGOB7M7J5p1V8D8MDjYrLoaWsfciAlU5Ro6wu94erHT7v7LsLeKl2UnXaK jwz8rr3hwC25+SmWHVy1/5X0jIQOKCKbW8hAx35Of3RFMVlr8O+ri+nd2AfT4MQwYpEz vY/4IWgf6a9tMGLM+rWYLy0/Iq+ZjqjCOJt4Yhx7t5xzLQVEHQ+C4DQ5jrkCcH1B5CA1 Nihw== 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:from:date:message-id:subject :to; bh=vERJlQCInH5avX7G0mt4XuzWHKG2QRQA8VXjgP0l5L8=; b=lf+83CSL/wO9pXIMic1LccdWu/XFS9M2GkBd44nnhS76LdPmEUXXpdePLqIYd4xC9z 3VzwqlEUWCBxSHMILV9ZxUGEP07dRz5P7AOYm/b64EU7r16lWBB03GYH6BTcgWrpV7wE K4V8mbqDcI3V2hapv0TITiWM8vNvJq9P81b4zWNA0CzCZHRMSQYAlBkAzZbGmdGRCURE d7W31po/8egzcYr0QqEP35W84fXxiyj8LBf6zUOfF7iNo5B5RrVP6GuzEAthyUQSCBB+ 3WPnBPbFP5Nv2OJ9X8omZqNKHEM5A/j3U7nUzpxTQTA+Ps8Sg4fIzu0ZaYZVVbXvrYAt obvQ== X-Gm-Message-State: AElRT7EfIXG8+ZCdEZpIhaA0SL0kQ3l3iCWJFcRB4DPt/qB8K0zLY9q9 fDn+0wHO8YQul5aWvsaGgjKhi7Fx1swYbqDm6w4F113Q X-Google-Smtp-Source: AIpwx4/mZ4zDrob1gSNupGbUEOb0/iJUVxeUFcHBWXGoQRvQBZK8XfsmWRbJlZw6AI2yZD1CV3udUOcd60OBOyKLDNU= X-Received: by 2002:a24:dfc3:: with SMTP id r186-v6mr137905itg.114.1522116899786; Mon, 26 Mar 2018 19:14:59 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.20.200 with HTTP; Mon, 26 Mar 2018 19:14:33 -0700 (PDT) From: Ed Maste Date: Mon, 26 Mar 2018 22:14:33 -0400 X-Google-Sender-Auth: 30nkv9Im5Z22rzvi_0aqPBa-HJQ Message-ID: Subject: Heads-up: linker (lld) changes for amd64 coming soon To: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 02:15:01 -0000 Some changes related to the amd64 linker are nearly ready to be committed (within a week or three), so I'm sending this notice to request any final comments or concerns before these changes are made. 1. Kostik (kib@) has a patch to start using kernel ifunc, with the first use being Supervisor Mode Access Prevention (SMAP) on amd64. This relies on linker support that is available in the in-tree lld and in contemporary binutils ld.bfd from ports, but not in the in-tree ld.bfd 2.17.50. Right now we use lld as the default bootstrap linker for amd64 in -CURRENT -- that is, the kernel, and userland libraries and binaries are linked with lld. To revert to ld.bfd for amd64 the build-time knob WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work for amd64 kernels (and will be added to BROKEN_OPTIONS). 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, and thus the linker used for linking ports. I plan to switch this to default on. Most ports build just fine when lld is the system linker, but a few encounter trouble: some of the ports rely on options not supported by lld, rely on specific quirks of ld.bfd's implementation, or have a buggy linker invocation that is silently ignored by ld.bfd. The majority of such ports have now been adapted to work with lld or configured to use ld.bfd as the linker, but there are a small number of failing ports that do not provide a way to use other than the default system linker /usr/bin/ld. The outstanding issues can be found in the ports exp-run for lld as /usr/bin/ld, PR214864. Please follow up if you have any concerns or comments about these upcoming changes. From owner-freebsd-current@freebsd.org Tue Mar 27 04:25:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C9DDF71AF2; Tue, 27 Mar 2018 04:25:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1544A6B559; Tue, 27 Mar 2018 04:25:08 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id w2R4Ou6F016830 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Mar 2018 06:24:57 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1522124698; bh=pORY5+hOOIsGZP9JM5tv9jjnMM5nRT39C6AnSNxs9YA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=VH1v3Utz+sx319OCiKMe4YO3/uZNNJtB2Q6qfKrzEw3OM0M7+PcyT5apmSoubZUW6 LrfUoD/AGdjF1Gw73muGUyp3IL6xwmdtTWtDjEQ0S8B7HpYPD1a1mZX4dYReVAGwyV OvhnPavQ5+eSYuZ6SAkEq5phmejjiIePAiwcslAc= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id w2R4OqB1058450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Mar 2018 06:24:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id w2R4Oqas027302 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Mar 2018 06:24:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id w2R4OpUf027301; Tue, 27 Mar 2018 06:24:51 +0200 (CEST) (envelope-from ticso) Date: Tue, 27 Mar 2018 06:24:51 +0200 From: Bernd Walter To: Hans Petter Selasky Cc: Bernd Walter , freebsd-arm@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: webcamd based touchscreen problem on Pi3 Message-ID: <20180327042451.GE16646@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20180309004433.GI86413@cicely7.cicely.de> <4765ef04-6fb1-f9dc-315d-c4419d6ba016@selasky.org> <20180309114025.GJ86413@cicely7.cicely.de> <20180309132539.GL86413@cicely7.cicely.de> <20180310000336.GM86413@cicely7.cicely.de> <20180312111246.GA14138@cicely7.cicely.de> <20180325231128.GA16646@cicely7.cicely.de> <20180325232806.GB16646@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180325232806.GB16646@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 04:25:09 -0000 On Mon, Mar 26, 2018 at 01:28:06AM +0200, Bernd Walter wrote: > I somehow suspect that the device is dropping data, when the driver isn't > retrieving it fast enough. > I can't say for sure however, because usbdump has more interupt packets than > there is events on the /dev/input , although X and Y coordinates come in the > same packet. > But I couldn't isolate the button packets yet. The 10" (not the early model I had before) is working fine now using wmt(4). I'd tested with wmt(4) before, but it failed. Interestingly xf86-input-mouse via usbhidlib did work with mouse emulation on the 7", which the 10" doesn't have, but the emulation of the device was bad and in touch mode X crashed on both displays during device init. uep(4) doesn't work at all, it is for a completely different protocol used on some older eGalax devices - obviously some with resistive touch, but not sure. Similar the egalax_ts.c in webcamd is only for the older eGalax devices. Have to see why wmt(4) doesn't like the older devices, maybe this can be fixed. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@freebsd.org Tue Mar 27 06:20:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63544F52718; Tue, 27 Mar 2018 06:20:26 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 E4FF47011A; Tue, 27 Mar 2018 06:20:25 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id e79so26128554ioi.7; Mon, 26 Mar 2018 23:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nb7Jy7OgVHCe4frKAsG25iTI51e2alPw0lIjwtXa/jk=; b=tvoqwCmXcUmoHWM5y7ayCoCkrvbQWeB8X356po9GbTN7BXEStO2elfV1Ob+50xzmTy bzXQHDkVL43Y1xK4xs0E7saPrFQVDwdIGiT5c+ZFplEgPA2VezJ4glftBP6sHHxrL1M8 8WI3oq8bYXdpcxx6Uq2Medolcd/h2cKlBE+VcA4Tx+WM9IlwAyHPwjQcmzVZhaDAgl8Y 8CyGBXNj4FfpK9XGKgjXohWfWGnplaWQe3kTacJMUOUXs0A1PYam9yVEUw7jLnMQN1A1 vfMgM1TN2ctLp/4SxuPwT5nn0SoOViwXFEM8hFT9i2eBknf0nbpw2yWNhMFZOOknGn0U baog== 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=nb7Jy7OgVHCe4frKAsG25iTI51e2alPw0lIjwtXa/jk=; b=Y+H8o0vsjoSaBGzEZTBEV52oU2dik5CWTK4fqG9GYTDdzq36PBzRJELi4Fd3O+7r0N wSWYchTRTJzRJwihI+0apizVsuaAAvy9U3miP67mWUphqEAxURfUyOEq9oV4YQln+SC+ Z/liBGbCvK6q1b6t/SDiw3kJ25kV5nbqMFxPg6rtGPgp6QSb4hYOeqqTnFzxkcWc9Hoc 1JihfWGedz9WePF/Xu9v127JFNObh9BMp+HHdwc5hA1C5I7HJ5QTjybgCbKcZ1IuLdg1 TjIf+YuF5K63Ao5bBEll2OOg8q2otil8vezRtY/wCQSdWy3XQsgEXUARzX3FZw/d/gqj eQ+A== X-Gm-Message-State: AElRT7EKSpV25rSWeiNKfqBubfuh5Q+NFM/wjnoUGFRw1JcmDdPBnIiR Yh+uEjfiUnvLnXUEXRcXzS5e4FdoRYnsdnjDnMs= X-Google-Smtp-Source: AG47ELtCh6zZpL9YsPRhAdd3ahVB97M7xvU3uGlPI9yuWneQINPvhp9trN+2erWZihzL73vFYfaKA8FwhHJTRLkDPfQ= X-Received: by 10.107.59.8 with SMTP id i8mr42476822ioa.110.1522131625220; Mon, 26 Mar 2018 23:20:25 -0700 (PDT) MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 10.107.184.135 with HTTP; Mon, 26 Mar 2018 23:20:24 -0700 (PDT) In-Reply-To: References: From: Antoine Brodin Date: Tue, 27 Mar 2018 08:20:24 +0200 X-Google-Sender-Auth: GeK0p40amV14kuHzEkoJhRy3g18 Message-ID: Subject: Re: Heads-up: linker (lld) changes for amd64 coming soon To: Ed Maste Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 06:20:26 -0000 On Tue, Mar 27, 2018 at 4:14 AM, Ed Maste wrote: > Some changes related to the amd64 linker are nearly ready to be > committed (within a week or three), so I'm sending this notice to > request any final comments or concerns before these changes are made. > > 1. Kostik (kib@) has a patch to start using kernel ifunc, with the > first use being Supervisor Mode Access Prevention (SMAP) on amd64. > This relies on linker support that is available in the in-tree lld and > in contemporary binutils ld.bfd from ports, but not in the in-tree > ld.bfd 2.17.50. > > Right now we use lld as the default bootstrap linker for amd64 in > -CURRENT -- that is, the kernel, and userland libraries and binaries > are linked with lld. To revert to ld.bfd for amd64 the build-time knob > WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the > ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work > for amd64 kernels (and will be added to BROKEN_OPTIONS). > > 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, > and thus the linker used for linking ports. I plan to switch this to > default on. > > Most ports build just fine when lld is the system linker, but a few > encounter trouble: some of the ports rely on options not supported by > lld, rely on specific quirks of ld.bfd's implementation, or have a > buggy linker invocation that is silently ignored by ld.bfd. > > The majority of such ports have now been adapted to work with lld or > configured to use ld.bfd as the linker, but there are a small number > of failing ports that do not provide a way to use other than the > default system linker /usr/bin/ld. The outstanding issues can be found > in the ports exp-run for lld as /usr/bin/ld, PR214864. > > Please follow up if you have any concerns or comments about these > upcoming changes. Hi, I have no concerns about 1. About 2., I am concerned that changes breaking a large number of ports are committed without portmgr@ approval. If WITH_LLD_IS_LD is committed as is on amd64, packages for head won't be published as it doesn't meet our current criteria for publication. Antoine From owner-freebsd-current@freebsd.org Tue Mar 27 14:00:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE65CF563E2 for ; Tue, 27 Mar 2018 14:00:19 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (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 2AA1D86BF5; Tue, 27 Mar 2018 14:00:19 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f43.google.com with SMTP id a22-v6so33459829lfg.9; Tue, 27 Mar 2018 07:00:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5iovp3NXYFs/relao2u2NrVam2OH7/q3k4klVfkIUw0=; b=bsU6PyhMirhhcJK/JZcoqlYpZ4+v6a3MummtvLVdZcMmuBorBMlVXfFFgqnQgGlqjA Jbxm0UE9GqodrtcHNag+4YbAiaAnPbgytLjX+8uB5Cuvn06zdmT/e7d1jsr6QdLjihyO FU6GxlWfz31BJEhs3+brYKlBDaqTwH3jIe2sjuf01ww3pYWom2o+aowFIn/HjONZMfl3 oD7jh3xrVbQbUuDW8cLOtILjAszN8JjO2BmjK06FrFS8uoTHY1VFRSDfFPLytUwWRvui xdR0/6t9Ir2LxUaU1/wLRQXwmdAMJwz8ijBydCRG8p4yDb2rxp8pcof9FgyPLOXcZhAK ZTPQ== X-Gm-Message-State: AElRT7FLloJNXyf/uStEklM9UvpAvvAknbvqmYlqsZmPoR86WivP0csE FoxhZ4w23/ExdEklRk6/Mf3YQr61 X-Google-Smtp-Source: AG47ELviP4hExqDVmOHof8ILP+0+dNTLlipBL/9kk4qoKxDTU59Kui/rMZARG0+610KZkqn3aVGCCA== X-Received: by 2002:a19:4d46:: with SMTP id a67-v6mr30707962lfb.36.1522159212057; Tue, 27 Mar 2018 07:00:12 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q68-v6sm251667lfd.58.2018.03.27.07.00.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 07:00:11 -0700 (PDT) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Bryan Drewery , Peter Jeremy , Jeff Roberson Cc: FreeBSD current References: <20180306173455.oacyqlbib4sbafqd@ler-imac.lerctr.org> <201803061816.w26IGaW5050053@pdx.rh.CN85.dnsmgr.net> <20180306193645.vv3ogqrhauivf2tr@ler-imac.lerctr.org> <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> From: Andriy Gapon Message-ID: <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> Date: Tue, 27 Mar 2018 17:00:09 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 14:00:20 -0000 On 24/03/2018 01:21, Bryan Drewery wrote: > On 3/20/2018 12:07 AM, Peter Jeremy wrote: >> >> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >>> Also, if you could try going back to r328953 or r326346 and let me know if >>> the problem exists in either. That would be very helpful. If anyone is >>> willing to debug this with me contact me directly and I will send some >>> test patches or debugging info after you have done the above steps. >> >> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). >> I initially got around the problem by reverting that commit but either >> it or something very similar is still present in 11-stable r331053. >> >> I've seen it in my main server (32GB RAM) but haven't managed to reproduce >> it in smaller VBox guests - one difficulty I faced was artificially filling >> ARC. First, it looks like maybe several different issues are being discussed and possibly conflated in this thread. I see reports related to ZFS, I see reports where ZFS is not used at all. Some people report problems that appeared very recently while others chime in with "yes, yes, I've always had this problem". This does not help to differentiate between problems and to analyze them. > Looking at the ARC change you referred to from r325851 > https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure > is completely broken. Does your being convinced come from the code review or from experiments? If the former, could you please share your analysis? > On my 78GB RAM system with ARC limited to 40GB and > doing a poudriere build of all LLVM and GCC packages at once in tmpfs I > can get swap up near 50GB and yet the ARC remains at 40GB through it > all. It's always been slow to give up memory for package builds but it > really seems broken right now. Well, there are multiple angles. Maybe it's ARC that does not react properly, or maybe it's not being asked properly. It would be useful to monitor the system during its transition to the state that you reported. There are some interesting DTrace probes in ARC, specifically arc-available_memory and arc-needfree are first that come to mind. Their parameters and how frequently they are called are of interest. VM parameters could be of interest as well. A rant. Basically, posting some numbers and jumping to conclusions does not help at all. Monitoring, graphing, etc does help. ARC is a complex dynamic system. VM (pagedaemon, UMA caches) is a complex dynamic system. They interact in a complex dynamic ways. Sometimes a change in ARC is incorrect and requires a fix. Sometimes a change in VM is incorrect and requires a fix. Sometimes a change in VM requires a change in ARC. These three kinds of problems can all appear as a "problem with ARC". For instance, when vm.lowmem_period was introduced you wouldn't find any mention of ZFS/ARC. But it does affect period between arc_lowmem() calls. Also, pin-pointing a specific commit requires proper bisecting and proper testing to correctly attribute systemic behavior changes to code changes. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Mar 27 16:06:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D520F653BB for ; Tue, 27 Mar 2018 16:06:49 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD5CB6E7F1 for ; Tue, 27 Mar 2018 16:06:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137]) by mailout10.t-online.de (Postfix) with SMTP id 936DA41FE479 for ; Tue, 27 Mar 2018 18:06:41 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (XL5de2ZLghu68Nkpfy8HePM5PshSxYgkbOX0hRrJeU1fBT1byuUHM1WkuOGMRlNZX4@[87.151.209.250]) by fwd37.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f0r7K-0U3YRc0; Tue, 27 Mar 2018 18:06:34 +0200 To: "" From: Stefan Esser Subject: Boot failure: panic: No heap setup Message-ID: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> Date: Tue, 27 Mar 2018 18:06:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit X-ID: XL5de2ZLghu68Nkpfy8HePM5PshSxYgkbOX0hRrJeU1fBT1byuUHM1WkuOGMRlNZX4 X-TOI-MSGID: 5d7f2276-2b8f-4809-93eb-f0e0bfd04470 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 16:06:49 -0000 A few weeks ago I tried the LUA boot and found, that my kernel did not start (i.e. did not print the initial FreeBSD version line), but instead stopped with: panic: No heap setup I recovered by booting from an alternate boot device and kept my system running until today, where I decided to give the LUA boot another try. The boot failure happened again, with identical message: panic: No heap setup I tried booting a GENERIC kernel, but only rebuilding the boot loader (gptzfsloader in my case) without LUA support fixed the issue for me ... The system is -CURRENT (built today) on amd64 (not converted to UEFI, yet). Further information is available on request. For now, I'm back to booting with the Forth based loader ... STefan From owner-freebsd-current@freebsd.org Tue Mar 27 17:15:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F8CBF6C5AF; Tue, 27 Mar 2018 17:15:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D35DA72D7B; Tue, 27 Mar 2018 17:15:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x231.google.com with SMTP id v13so158338iob.6; Tue, 27 Mar 2018 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KTkmPFAan1r46/P9C+Y7T9LIgNNnZREVZJ8KGHARyz8=; b=C59DSrs0QQd/czQ1PBlIi1Z8EJce/ggSFuMKBKPK+sJ0jVmAGQSnaD3sEOU5fS5KWz Ka7lfjbulyqQSJujaokHnSGD+w74mcQAjnseZGFbMUsa4+lXndfCZpYs3CsDf9pxRuOG HT9IwFyIOR6+mav896PSBGCVa7YjV6pMlV8ttJuKDWeP2NEmBj0vB8jdDnj3+ssq0Prx kUcjLzrUoRuIN/+63JrkzxEqkqm28UfGsFj6kfnEfwxZIUJPh1Ui1cHM2g3uxG2HofBV I5ABS3zC/7cEoOWGDZLpKxpRbZddR8iaT868tbCP9KVMiriN7YvF/ER2sVnXSmUADwpD S0VQ== 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=KTkmPFAan1r46/P9C+Y7T9LIgNNnZREVZJ8KGHARyz8=; b=dVTzTlwRRfVRwXUaWuLQ+PttwhqKgSweZ+DJFNj39PPT5M67br456U9lGuRBbkDwlT eKtsOBegXEPdzYDaOfTMJCrvfeHZvaEYFBc6mFGUq+jWIa/inqImTyBQf/MsYAvr6mkh otz9DyARG8lgHa8qBrpyzozLovhkuXIGBUBX5hrcR/wm6KZ9uqm+3TVseYv52Jchgdug zv/zh0u+stRXoudI34md+LWj3JzHFmQKvE3tlg2facQAYErqSux/Yq+oJytuFBbIeQ5H dlNsl+23xVfb65rihc9XN7nvkYnLWEwUCdfYY4AGlBqfYSbciyBRI1ChvQ/PJ3HUvKiy r51Q== X-Gm-Message-State: AElRT7Hgv3dDR6lvPX6rW+K7toX3d4iiuYAKhC0x86Sd5HApdnQ0bqLN bthiNmTO/Umo2W+kF6wMZ5hpkO1aRkhNQTKx8BfzPwOm X-Google-Smtp-Source: AG47ELsvBh7+qaUoaEmdZvFj/ClzwuOPMpUK9w4H5eSJm2nFrFYY7+ldrbKQMJDOUP48VM6ZBchPksq+tqGVI92qxhc= X-Received: by 10.107.20.213 with SMTP id 204mr42522645iou.239.1522170926126; Tue, 27 Mar 2018 10:15:26 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Tue, 27 Mar 2018 10:15:05 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 27 Mar 2018 13:15:05 -0400 X-Google-Sender-Auth: sektya6LYFVR1ieeDT__ysn16kU Message-ID: Subject: Re: Heads-up: linker (lld) changes for amd64 coming soon To: Antoine Brodin Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:15:27 -0000 On 27 March 2018 at 02:20, Antoine Brodin wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in contemporary binutils ld.bfd from ports, but not in the in-tree >> ld.bfd 2.17.50. > > I have no concerns about 1. OK. My guess is I won't get any other feedback on this one until it makes it into a release. I suspect kib will commit this part later this week or early next week. >> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, >> and thus the linker used for linking ports. I plan to switch this to >> default on. >> > > About 2., I am concerned that changes breaking a large number of > ports are committed without portmgr@ approval. > If WITH_LLD_IS_LD is committed as is on amd64, packages for head > won't be published as it doesn't meet our current criteria for > publication. Fair enough - this was the reason I sent the email. I've now gone through and submitted a PR for for each failure that did not already have one. I've also added LLD_UNSAFE to a few ports where where it was straightforward. In this batch of PRs I noticed four main issues: 1. Ports that pass compiler flags, such as -fPIC, to the linker. lld has more strict command-line parsing and rejects these invalid invocations, while ld.bfd happily creates bogus output (e.g. a shared library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a reasonable discussion of this issue. 2. lld has no built-in search paths (/lib, /usr/lib). Normally the linker is invoked from the compiler driver, which provides default search paths. If lld is invoked directly then library search paths must be specified explicitly with -L/lib -L/usr/lib. 3. Shared library protected visibility symbol preemption. 4. lld does not have a built-in default output target. For the common use of the linker (linking individual .o objects into an executable or shared object) lld infers the target from the first object file. However, when the linker is used to convert an arbitrary binary file into an ELF ojbect (via -r -b binary) lld needs the output target to be specified explicitly with -m. The vast majority of skipped ports in the exp-run come from two failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for lang/ghc reports that the current released version of ghc mentions improved lld support; I hope the port update will solve this issue. I submitted a bug report upstream for lang/fpc about one fpc bug that affected lld, and that issue has now been resolved upstream. We'll need to check again once the port is updated. From owner-freebsd-current@freebsd.org Tue Mar 27 19:31:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3A58F5213F for ; Tue, 27 Mar 2018 19:31:37 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) (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 055487C07E; Tue, 27 Mar 2018 19:31:37 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f51.google.com with SMTP id e5-v6so52666lfb.7; Tue, 27 Mar 2018 12:31:36 -0700 (PDT) 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=y5mPy6MqR7ECNjr2rD0DVQP940zQjfxBYpdI+2BmIIE=; b=HQY1q16Dhi1dhvn7jUTmpfGh3MhySWO+in4v1dQXm3qYwKs8hCnlOf7Dw+8t6dCub8 hdOrtO5byg0FZgyVb0uGa2HnZwCfronTaIvWPYQzR4GD2um0g62OXyp3Cp/f/yHuHoSD Y3ovPHM1FZEFlL/EnbqOk3sY1KcBvrQdfdBuYHMsOIyoxIkk+7uNIR2V49a6d27uzd/9 3H0vh7sl9WUlJOaCx2sg+b83ef+cZv+1gaWNOLoYX2QnRSFPpWGewzwTfs8yuDhncJfU YAa5wY9LtuCg/FEEa+BvTMpywj6tLOO3juqPOzmS5SvWPNdmmYxVskoOPv1AEwV4PXAl 0AKg== X-Gm-Message-State: AElRT7HUKF8HOPXG6CPaOBprWavOp5Hfj8ZQ5kF1TK+em3LBdFWAX2mU adWnpqzKX0hTOBuqde7sJJs1i5Z4 X-Google-Smtp-Source: AIpwx48hgu/4PlKkrJdnOM7K/SUNgTtg0YNrUuQtcwuf1pxqiFKl9JYtP2diaz8kkdw6wMrGQQ40YQ== X-Received: by 2002:a19:a387:: with SMTP id m129-v6mr364766lfe.31.1522179095255; Tue, 27 Mar 2018 12:31:35 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com. [209.85.215.54]) by smtp.gmail.com with ESMTPSA id p66-v6sm360942lfp.79.2018.03.27.12.31.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 12:31:35 -0700 (PDT) Received: by mail-lf0-f54.google.com with SMTP id x205-v6so79163lfa.0; Tue, 27 Mar 2018 12:31:35 -0700 (PDT) X-Received: by 10.46.127.30 with SMTP id a30mr390095ljd.93.1522179095009; Tue, 27 Mar 2018 12:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 27 Mar 2018 12:31:14 -0700 (PDT) In-Reply-To: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Kyle Evans Date: Tue, 27 Mar 2018 14:31:14 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Boot failure: panic: No heap setup To: Stefan Esser Cc: "" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 19:31:37 -0000 On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote: > A few weeks ago I tried the LUA boot and found, that my kernel did not start > (i.e. did not print the initial FreeBSD version line), but instead stopped > with: Oy =/ > panic: No heap setup > > I recovered by booting from an alternate boot device and kept my system > running until today, where I decided to give the LUA boot another try. > > The boot failure happened again, with identical message: > > panic: No heap setup Hmm... that's an sbrk panic [1], indicating that setheap hadn't been called. zfsgptboot is zfsboot with gpt bits included, so the relevant setheap call is [2] I believe. It's not immediately clear to me how switching interpreters could actually be breaking it in this way. At what point are you hitting this panic? After menu, before kernel transition? > I tried booting a GENERIC kernel, but only rebuilding the boot loader > (gptzfsloader in my case) without LUA support fixed the issue for me ... > > The system is -CURRENT (built today) on amd64 (not converted to UEFI, yet). [1] https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 [2] https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 From owner-freebsd-current@freebsd.org Tue Mar 27 23:49:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A91AEF6B96A for ; Tue, 27 Mar 2018 23:49:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from sonic306-35.consmr.mail.ir2.yahoo.com (sonic306-35.consmr.mail.ir2.yahoo.com [77.238.176.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FD11697F3 for ; Tue, 27 Mar 2018 23:49:47 +0000 (UTC) (envelope-from se@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1522194581; bh=DQ0FHyzKEO3Ce4YMW+IFqZ8tYDj7y2SajwVfrvxlz3Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=FOn7Tir5Gw1jhOxIWh1B5HFXo9xj6gwH2w2gG/1lcr2QY26U/hjd1upUnmP0KIrHbhpNCaXSdRN3OufZIyirIImHN/9KRa6u7jvSgNjQDdgi0QOnHWNMSuffd2eNFkq+K54U8KDAWHbF9juiqXu6mcSGeFAdESrnrIST/xt5WO0hRAVSndQanB67Xvw/0GAuSqmTfGhCo/1zXh//qzxOXKbvWUNpMeCWYWmQ8UvsdKTXRMasI/kfPBmJH4znB6aAy+wTfeiMwmBuQf/q25YC8Y1vwmzxjipBF07deUG7b9skDL06/2nUgZzYfrw7m9vgLrMYBpuVrlehjsAhAA4wiw== X-YMail-OSG: dIaYy.0VM1meD76bDbRAesTqPOudepxeuxNDdG7anZmiZBJBwA2DQwqgnJbPbUG XZVSXwKDsqIN.vM6bU5jWaMClIaJNThhATDHxUhCWylk2rvA3f75u8JkAE3C0AfMqZ04tQoRMlBg nwicTkz50.6vK_p8LXtlkGNxdGO0C1Om5uLk85JDmOdvPsv2If7YvFP7pb85.bUD9Yqtrcrv1Wsn NRdobBuM92vTxD6ON3NOi3OADyH6dE62ouQE.URqgzWKbZ.Qp9FgUiCoFev9XPvmzdwZ18YLNCht n2kI5ZO8WaQN2znOgnXgko60ffsqhu2xsEacL8i.h0m2yMYQvJvhS7._8pdPdK6r.N8ZHjeP4PFx gCTlDl9hYXZp7AgE.0iqqy5Ma7lJmH87pjeIj79XDBjQrKjznPe6L7t5RfkDIcKiElzy_mdEqgvb zeaAN0aWtOJhFpT1us4xeIeJ95RBdGeNqIjxlIqN9dcIo8hMkBogSUvOUKTPQlA.30itXKDDe1aV WdQi4zeLkENwanHVXIgeW2oyHldcwW7s- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Tue, 27 Mar 2018 23:49:41 +0000 Received: from p5797D1FA.dip0.t-ipconnect.de (EHLO Stefans-MBP-7.fritz.box) ([87.151.209.250]) by smtp413.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0c3e725a8ed3b282714f6c5ccb62da74; Tue, 27 Mar 2018 23:39:31 +0000 (UTC) Subject: Re: Boot failure: panic: No heap setup To: Kyle Evans , Stefan Esser Cc: "" References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Stefan Esser Message-ID: Date: Wed, 28 Mar 2018 01:39:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 23:49:49 -0000 Am 27.03.18 um 21:31 schrieb Kyle Evans: > On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote: >> A few weeks ago I tried the LUA boot and found, that my kernel did not start >> (i.e. did not print the initial FreeBSD version line), but instead stopped >> with: > > Oy =/ > >> panic: No heap setup >> >> I recovered by booting from an alternate boot device and kept my system >> running until today, where I decided to give the LUA boot another try. >> >> The boot failure happened again, with identical message: >> >> panic: No heap setup > > Hmm... that's an sbrk panic [1], indicating that setheap hadn't been > called. zfsgptboot is zfsboot with gpt bits included, so the relevant > setheap call is [2] I believe. It's not immediately clear to me how > switching interpreters could actually be breaking it in this way. > > At what point are you hitting this panic? After menu, before kernel transition? The menu is displayed and I can unload the kernel and load the kernel and modules from an alternate path. The lua code seems to work just fine, but as soon as I enter the "boot" command, the panic happens. This happens when the loader transfers control to the kernel but before any other output is generated. I tried booting a GENERIC kernel just to be sure this is not caused by an out-dated kernel config file. >> I tried booting a GENERIC kernel, but only rebuilding the boot loader >> (gptzfsloader in my case) without LUA support fixed the issue for me ... >> >> The system is -CURRENT (built today) on amd64 (not converted to UEFI, yet). Hmmm, the code references point into the boot loader code - I had expected that there is a problem in the kernel, not the boot loader. > [1] https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 Seems that setbase has either not been called or has been called with base=0. > [2] https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 I had thought, that the zfs boot code has been initialized before the menu is displayed? Or do I misunderstand this phase of the boot process??? Regards, STefan From owner-freebsd-current@freebsd.org Wed Mar 28 07:56:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50D0DF673B3 for ; Wed, 28 Mar 2018 07:56:04 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 C218D7B41B; Wed, 28 Mar 2018 07:56:03 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-pl0-x229.google.com with SMTP id p9-v6so1116390pls.2; Wed, 28 Mar 2018 00:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RApecdAnHIlSfSBvPH9EVfRL21qpuPLEVVRDrFl8BqI=; b=rKIY6HHCmnytfl+zA1QXPBMutr4NYB5Bbq8lyx8Xg994x8KnwYNGNH5Q6zKkmwRod5 anMaYsO6kJYTFOJ0kFK6h/zxbLXc7dLyLIJbkU7GJImFFO2QvfZPZmblm2oMXLSTMmmN SnqirmdY8h5zzGfCbM8OiVV0PfjS2De6yK80uLs/wkf0VilOD2cJNzwrnAqxateGis53 KDV4avk1zy+gc1qOSxxPunnwJmW5EuAqArlNhqQu1jFiVaa8aDXsch+JoeAY56lCnAx+ gdzHgZH//v1ELgFM0HlmeyW4h7KCBWaINRBfreYJ6yZbMTCVCauxw0yU6QDHB0arD8iw SG+g== 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=RApecdAnHIlSfSBvPH9EVfRL21qpuPLEVVRDrFl8BqI=; b=ANYy1swPaFjwm0BythpId7f8uLv9opDZ+57hZPXxrD3cE+hDhPq6iXJieW8/ZWeeDr ++XeHLz9+rMBXV+0MJPPLXToGVBu6KVj/LddzZPIfKwAK9ImXXgpBcGZJMP4RbQ3LcPI bvrMgYUfJ8xP0n4soaVxul2KzlmrGaPavwHCf90DJJUbg9Pj0nMPfKaxZz8T0LdTUCCx Lorfy5M0vgqDifBwbuquHah2JT4RESTIRJeUBTMEydG33a7CpdmIgLdil6B2LCNCzj59 XMwijZFSC0sdwZyuZlKEWwEG0q+xqrQzHDEzKvdBzY2hVbbOTCzFLWkSHrEfWrb4QsSU Es2A== X-Gm-Message-State: AElRT7GK8St3X/YjaSYcrJt0CZsk8JaJ4CBEkFAId9Xxpzs30OipZraH pFhhTy3uyYRewDmn+ox0NPaI/2ZqUxBNX0zB91nuQA== X-Google-Smtp-Source: AIpwx4+Ozfs0akgpNGu66ACLaIkZ03iVye7Umz4MRZ6NZY5kmE+oVvvSkKMsC06qZ+U5Albi3ETxR7O0d79bZnC8jWo= X-Received: by 2002:a17:902:7084:: with SMTP id z4-v6mr2761471plk.395.1522223762331; Wed, 28 Mar 2018 00:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.196 with HTTP; Wed, 28 Mar 2018 00:56:01 -0700 (PDT) In-Reply-To: <8349653f-fe9a-a896-48f5-325738d7bd8e@FreeBSD.org> References: <3E242843-7D43-4A36-A448-E4B0DACB2AB4@jnielsen.net> <8349653f-fe9a-a896-48f5-325738d7bd8e@FreeBSD.org> From: Maurizio Vairani Date: Wed, 28 Mar 2018 09:56:01 +0200 Message-ID: Subject: Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module. To: Andriy Gapon Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 07:56:04 -0000 2018-02-04 14:40 GMT+01:00 Andriy Gapon : > On 04/02/2018 11:50, Maurizio Vairani wrote: > > I have added a socket in the ifioctl() call as in the > > /usr/src/sys/nfs/bootp_subr.c source. > > Please let me know if you prefer a patch. > > A patch here https://reviews.freebsd.org/ would be the best. > > -- > Andriy Gapon > Hi, I have uploaded a patch here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226982 -- Maurizio From owner-freebsd-current@freebsd.org Wed Mar 28 15:11:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B204CF6727B for ; Wed, 28 Mar 2018 15:11:37 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E730706EA for ; Wed, 28 Mar 2018 15:11:37 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yb0-x22b.google.com with SMTP id k8-v6so902271ybd.6 for ; Wed, 28 Mar 2018 08:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=to:subject:from:message-id:date:user-agent:mime-version :content-language; bh=S/kZOaioMHlbCYQzLus5hIY15aEBAOy6UxSsyQVdAGY=; b=QtWnoI1BHNb6Qou2L7cN/35ks2J/fx6J58p+bst+X5Wagt7bPbR3AXRz7S/o8mXS/+ Ws+VD5+zzBrenwlp9CPSWJ2sk2rUB5nMhNGRTd0LLLBETUMQx+rNNI1zAsgeeyG+WfA6 KWzAPLLHVb9l6XyAhuKjxhxOTMzdSvuAOJMLNXXabA+ykGpCdqUMNDJkjk2kr90UewP8 iEbcs7VqIzRn2qHfVbAp0DTHithpln9TawQF9J1Vsi5BiMkfRBITD0gp5pC/mUNdknED hnhKAVJs8tuWyn3e+x5gVSHBsTyozdX1IxSSIfWSOun+IbnlUa7QZE08yFLL9+bneBz4 vLWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-language; bh=S/kZOaioMHlbCYQzLus5hIY15aEBAOy6UxSsyQVdAGY=; b=MQ5lJjI51igHJmqZ2UbTW6Uxjp55Pt8bwQ+XPLHg4ix2P8yw9qfPRECVsOjGjnf6jw DEI22Sofo9vODIZ+pVjdDW6mYNPHuurYOcb4umbv/arVyXc6Tzhh4obYrk5TNADD4BSg P4TeZ0b6OUiLEAKCdr4icDcQqLNnNrTMArL23GS5PLgNE26RaAEZ2LsNL6giGL9aVUr4 INPDAS9RPoxBX0PBeCYIujZayoQxX53fHD9RhEi/oFqpOobdwdSMDBoK0uV/z0nvwLqf Kn+tXUiwAbPGkzcAGC4Dq/WHVoTc7WmOseZNFA9cF9UDX4Jv7oQ5LzcWEUZSE5mHurJv 6+9w== X-Gm-Message-State: AElRT7F24BWzV7oOmRVrIlF4hEsvyVTcwB7a4ZQm9MAPj/kN4nAqlOXS T9/msmV9FgpSxoqhMH9r626jC02dQ4NXegxv/mH1xgHaL5xQ8JCyTqD/XYXTS55UIBnU8qF5wXb VGl/gI6RuODvQpwgg+/VwbU4F7BOboxL+W0/1dUMAmwPGa+G65JquO+jUTm06Ml6wGo2mkH4uaJ kf60QLvxxj2uk= X-Google-Smtp-Source: AIpwx48ASCQbQosfu0CLn6609KYr39+KLvxgIDZ3wcR/r7jTtEEu2GO8kqHKvHoJhlHtgX9cjtUKYg== X-Received: by 2002:a25:b207:: with SMTP id i7-v6mr2438165ybj.362.1522249896237; Wed, 28 Mar 2018 08:11:36 -0700 (PDT) Received: from [10.0.11.220] ([64.53.114.237]) by smtp.gmail.com with ESMTPSA id d135sm1499504ywh.2.2018.03.28.08.11.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 08:11:35 -0700 (PDT) To: FreeBSD Current Subject: r331650 breaks amd64 kernel build From: Ian FREISLICH Message-ID: <6f91516c-55c5-6e86-61db-918d9bb83faa@capeaugusta.com> Date: Wed, 28 Mar 2018 11:11:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 15:11:37 -0000 Hi (As noted by Oliver Hartman in svn-src-all@) r331650 breaks amd64 kernel build as follows: --- machdep.o --- /usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier 'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT; ^ The fix: Index: sys/amd64/amd64/machdep.c =================================================================== --- sys/amd64/amd64/machdep.c (revision 331680) +++ sys/amd64/amd64/machdep.c (working copy) @@ -128,6 +128,7 @@ #include #include #include +#include #ifdef SMP #include #endif Ian -- From owner-freebsd-current@freebsd.org Wed Mar 28 17:23:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 458AFF6D6E4 for ; Wed, 28 Mar 2018 17:23:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic307-11.consmr.mail.ne1.yahoo.com (sonic307-11.consmr.mail.ne1.yahoo.com [66.163.190.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6D92790B5 for ; Wed, 28 Mar 2018 17:23:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: v2k3FDwVM1n6I.s20NXGxTxY6cYZ4uF7566pKhw7YK38A8azHgwcOlx8BdoMZxB 4aM4inDEaCiP2KuwCFYrBVrGstkgKo_7FmN_ai_NrqwqfxemIOm4DdYj0dHNT7txoMebpqbICdUh GeAkXoEO9JxDxoyMbuf3PTsk7ZIL072F0Ip2ecuFMNRj93Q5ML2bowX6Fz3I9irY.zdlh4td7KJC dQXeCO317mUwYrKHNjCaLJarmX96hfQQs8WX.1o2qZGWDl4Kkhc6N4vm71dlsqYXA9RSGbnZPhBX JS3jo2cldai5we_FdOHseDMIjTmnE0Z_uXrieXrp9hqtg2MSS0ZVAwZO8REkXLJ_d8TSphm3qKSI iHNowvnRbDyIAe20J314ejDxW7Ckr2CtQBrqLVkRILAOMid.WjSVbozRztvNfaSiD5i6O71VyJzB pljGM3JHrrsrJju16u90L_BDQcYb4W8oqI8FmXm6HWh9LHFm2nP3H833AdL4lxjgLAeh.kEj8Q79 uvNcSBP1s_EqgtnHQFqQApXQY Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 28 Mar 2018 17:23:26 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0d602f54e9fe32c917639d8ff90544f1; Wed, 28 Mar 2018 17:23:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) Date: Wed, 28 Mar 2018 10:23:22 -0700 References: Cc: freebsd-ppc@freebsd.org, FreeBSD Current , sfertile@ca.ibm.com To: Nathan Whitehorn , Justin Hibbits , Ed Maste Message-Id: X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 17:23:28 -0000 I'm not one of the better people to be responding to the the likes of the below. So I've forwarded to some folks better able to comment, and 2 freebsd lists so others can see the note as well. sfertile at ca.ibm.com likely does not monitor any FreeBSD lists. So either direct sends or use of llvm's bug 31716 comments are probably required for responses. Begin forwarded message: > From: bugzilla-daemon@llvm.org > Subject: [Bug 31716] FreeBSD's 3.9.1 lld: Powerpc64: code in .plt = expects function descriptor layout but .got.plt space it uses does not = have such > Date: March 28, 2018 at 10:00:01 AM PDT > To: marklmi26-fbsd at yahoo.com >=20 > sfertile@ca.ibm.com changed bug 31716=20 > What Removed Added > CC sfertile at ca.ibm.com >=20 > Comment # 2 on bug 31716 from sfertile at ca.ibm.com > Hi Mark,=20 >=20 > I'm one of a few people now actively working on adding support for the = PPC64 V2 > abi.Our plan was to explicitly remove support for the V1 abi (at least = until > someone makes a pointed effort to support it). I'm interested in = hearing what > support FreeBSD has for ppc64 right now. Is there any support for the > little-endian/V2 abi? >=20 >=20 > You are receiving this mail because: > =E2=80=A2 You reported the bug. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 28 18:39:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C52F5F6F8B3 for ; Wed, 28 Mar 2018 18:39:55 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 58E637C76E; Wed, 28 Mar 2018 18:39:55 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id j26so3608862qtl.11; Wed, 28 Mar 2018 11:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zmT84zNjsbVvo7D5aCxsxfECzoaOU9a03178LZ0xPY0=; b=K6YugdfXmLFHM9IaQaexW5LM1b7rzjUMaOKU9IkRGJXuBz/MIl7K455/Zg87sD2GVe Q6ywh1dnVPOikKBp91jIRuOWCuSnrpydM+PLwLDPTfnAPkSHSvc7sk3Iahu+/D9VPgvI 0ISc2VXmGq38Qp1O1kioM6v2rdIdoHjQlDzHxvnmeteB4EUYr3AFDuBZ7jcAM3aO8l8k 8sjyXbnRpho4fJsjEyNu8cgw3dQDIdwhni4bN7ZZrwAxiNMjDfDQAv8w8pHkrhRb50Sj E5U7IBcTXjDO2ts/7xMfdF2ZxWCa1FHGFAa/0qFGVp5YyV33kzqkLDrY1IhDL1iheBk6 geAA== 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=zmT84zNjsbVvo7D5aCxsxfECzoaOU9a03178LZ0xPY0=; b=O0MA7PpYpAR2wz3UDjBnUYUF+svZomc5/acVSsDQKLd/oIT4S0srzf7tFNW0KMfMFu Jx+RTdbAOqwK3/FvX8IgSsDUHrfajnTInFhaKh43lDIvALqBQpD6EoFczygG8JaoYiy3 tfB387oeJliSu0l4K84Iv/GLVB5eV2pLF9xTwNEv3lzHONk5Y9lRy67TJjazOe2vE93Q Mgm+dAijB7OmEkRa1Zhar2oNhI0MLTAMbyHs8IC3FVLa5AO2L1K2W/Oftz7Q3v0mjuJV iAxm87XZTRGwMHxMLtcrdqOfDfUW/ssS+l4dkY8sMs1WOHDqDgC7FO8Leo2DovuouAyz 4rGA== X-Gm-Message-State: AElRT7EOK/YyubBwOPWHW3V9dbMgWIS5stsWA7gDnFshSFIuQ9mTqLXA oU8IXy0+Kf+VnPOv0GjbIxNTWQRNKErk7TswAy5+HLR/ X-Google-Smtp-Source: AIpwx48yV8FMWemvXjjrS7WTM1GY+AotrLN7ejBt2Ey71h/FXEOX92QRR26KdbDFFQZt+Kl2SA5FgIG9DYSvA78Qh2c= X-Received: by 10.200.27.216 with SMTP id m24mr6987093qtk.212.1522262394649; Wed, 28 Mar 2018 11:39:54 -0700 (PDT) MIME-Version: 1.0 Sender: tommi.pernila@gmail.com Received: by 10.237.58.103 with HTTP; Wed, 28 Mar 2018 11:39:53 -0700 (PDT) In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Tommi Pernila Date: Wed, 28 Mar 2018 21:39:53 +0300 X-Google-Sender-Auth: TN9nVLgLBxCjfJAbNcczFBBMnZQ Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 18:39:56 -0000 Hi all, is there any chance that this would make it to 11.2 RELEASE ? stable/11 slush: April 20, 2018 stable/11 freeze: May 4, 2018 Br, Tommi On Thu, Feb 22, 2018 at 8:18 AM, Tommi Pernila wrote: > Awesome, thanks for the update and the work that you have done! > > Now we just need some more reviewers eyes on the code :) > > Br, > > Tommi > > On Thu, 22 Feb 2018 at 2.03, Eric McCorkle wrote: > >> FYI, I just IFC'ed everything, and the current patches are still fine. >> >> Also, the full GELI + standalone loader has been deployed on one of my >> laptops for some time now. >> >> On 02/21/2018 18:15, Eric McCorkle wrote: >> > The GELI work could be merged at this point, though it won't be usable >> > without an additional patch to enable loader-only operation. The >> > patches are currently up for review: >> > >> > This is the order in which they'd need to be merged: >> > >> > >> > https://reviews.freebsd.org/D12732 >> > >> > This one changes the efipart device. Toomas Soome identified some >> > problems, which I have addressed. He has not re-reviewed it, however. >> > >> > >> > https://reviews.freebsd.org/D12692 >> > >> > This adds some crypto code needed for GELI. It simply adds new code, >> > and doesn't conflict with anything. >> > >> > >> > https://reviews.freebsd.org/D12698 >> > >> > This adds the EFI KMS interface code, and has the EFI loader pass keys >> > into the keybuf interface. >> > >> > >> > I can't post the main GELI driver until those get merged, as it depends >> > on them. It can be found on the geli branch on my github freebsd >> > repository, however. >> > >> > >> > Additionally, you need this patch, which allows loader.efi to function >> > when installed directly to the ESP: >> > >> > https://reviews.freebsd.org/D13497 >> > >> > On 02/20/2018 22:56, Tommi Pernila wrote: >> >> Hi Eric, >> >> >> >> could you provide a brief update how the work is going? >> >> >> >> >> >> Br, >> >> >> >> Tommi >> >> >> >> >> >> On Nov 16, 2017 04:29, "Eric McCorkle" > >> > wrote: >> >> >> >> Right, so basically, the remaining GELI patches are against >> loader, and >> >> most of them can go in independently of the work on removing boot1. >> >> There's a unanimous consensus on getting rid of boot1 which >> includes its >> >> original author, so that's going to happen. >> >> >> >> >> >> For GELI, we have the following (not necessarily in order): >> >> >> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf >> >> interactions >> >> b) Modifications to the efipart driver >> >> c) boot crypto >> >> d) GELI partition types (not strictly necessary) >> >> >> >> Then there's the GELI driver itself. (a) and (c) are good to >> land, (b) >> >> needs some more work after Toomas Soome pointed out a legitimate >> >> problem, and (d) actually needs a good bit more code (but again, >> it's >> >> more cosmetic). Additionally, the GELI driver will need further >> mods to >> >> efipart to be written (nothing too big). But we could go ahead >> with (a) >> >> and (c), as they've already been proven to work. >> >> >> >> I'd wanted to have this stuff shaped up sooner, but I'm >> preoccupied with >> >> the 7th RISC-V workshop at the end of the month. >> >> >> >> Once this stuff is all in, loader should handle any GELI volumes it >> >> finds, and it should Just Work once boot1 is gone. >> >> >> >> >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> freebsd.org" >> > >> > From owner-freebsd-current@freebsd.org Wed Mar 28 18:50:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69DC7F6FECD; Wed, 28 Mar 2018 18:50:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 071697D4DB; Wed, 28 Mar 2018 18:50:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from helicon.physics.ucla.edu (helicon.physics.ucla.edu [169.232.156.253]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w2SIcGI2009644 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2018 11:38:16 -0700 Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) To: Sean Fertile , marklmi26-fbsd@yahoo.com Cc: chmeeedalf@gmail.com, emaste@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org References: From: Nathan Whitehorn Message-ID: Date: Wed, 28 Mar 2018 11:38:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVaOZ1VFSR+F12WGETgJIfrnytFq9JEOX5+fRE5bgQ+oQz1bZxdf4LS1ZjiQ9OcTWvofueNtHzsgmx+Hgfxn9OHwZsY5gmD8ERY= X-Sonic-ID: C;viGwLbcy6BGjVFDNXaHR5A== M;7tj1Lbcy6BGjVFDNXaHR5A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.3/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 18:50:25 -0000 Is this big-endian support or V1 support being removed? We support the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on Linux, the default ABI on big-endian will likely remain V1 for the indefinite future, however, and it would be good if it were at least simple to re-add support at some later date. -Nathan On 03/28/18 11:22, Sean Fertile wrote: > Hi Mark, > Just so we are clear this is about V1 abi support in lld, not in llvm. > The compiler will still be able to produce valid code for big-endian > ppc64. > Regards > Sean > > ----- Original message ----- > From: Mark Millard > To: Nathan Whitehorn , Justin Hibbits > , Ed Maste > Cc: freebsd-ppc@freebsd.org, FreeBSD Current > , sfertile@ca.ibm.com > Subject: From LLVM: I got a note that LLVM plans to remove PPC64's > V1 abi support; I'm asked about what support there is for the > PPC64 little-endian/V2 abi (see forwarded message) > Date: Wed, Mar 28, 2018 1:23 PM > I'm not one of the better people to be responding to the the likes of > the below. So I've forwarded to some folks better able to comment, > and 2 freebsd lists so others can see the note as well. > > sfertile at ca.ibm.com likely does not monitor any FreeBSD lists. So > either direct sends or use of llvm's bug 31716 comments are probably > required for responses. > > Begin forwarded message: > > > From: bugzilla-daemon@llvm.org > > Subject: [Bug 31716] FreeBSD's 3.9.1 lld: Powerpc64: code in > .plt expects function descriptor layout but .got.plt space it uses > does not have such > > Date: March 28, 2018 at 10:00:01 AM PDT > > To: marklmi26-fbsd at yahoo.com > > > > sfertile@ca.ibm.com changed bug 31716 > > What Removed Added > > CC sfertile at ca.ibm.com > > > > Comment # 2 on bug 31716 from sfertile at ca.ibm.com > > Hi Mark, > > > > I'm one of a few people now actively working on adding support > for the PPC64 V2 > > abi.Our plan was to explicitly remove support for the V1 abi (at > least until > > someone makes a pointed effort to support it). I'm interested in > hearing what > > support FreeBSD has for ppc64 right now. Is there any support > for the > > little-endian/V2 abi? > > > > > > You are receiving this mail because: > > • You reported the bug. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > From owner-freebsd-current@freebsd.org Wed Mar 28 18:56:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B46EF7021A for ; Wed, 28 Mar 2018 18:56:24 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDEA7DB27; Wed, 28 Mar 2018 18:56:23 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.208] (cpe-75-82-194-8.socal.res.rr.com [75.82.194.8]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 16e63429 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Wed, 28 Mar 2018 11:56:20 -0700 (PDT) Subject: Re: New ACPI Errors From: Pete Wright To: Jung-uk Kim , Claude Buisson Cc: FreeBSD-current References: <58d889fa-a9c5-5108-c838-01f4904950cd@nomadlogic.org> <8fed618b-5402-f396-b51e-48de8ac4f36b@orange.fr> <7bb2e69f-2666-e813-b683-a4f035b220d5@FreeBSD.org> <17a0c5eb-38a7-1956-5b6e-9ac08c2593e6@nomadlogic.org> Message-ID: Date: Wed, 28 Mar 2018 11:56:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <17a0c5eb-38a7-1956-5b6e-9ac08c2593e6@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 18:56:24 -0000 On 02/16/2018 13:54, Pete Wright wrote: > > > On 02/15/2018 13:37, Jung-uk Kim wrote: >> On 02/13/2018 17:34, Claude Buisson wrote: >>> On 02/13/2018 22:49, Pete Wright wrote: >>>> Hello, >>>> I have started seeing a lot of these messages spam my system log: >>>> >>>> ACPI Error: No pointer back to namespace node in package >>>> 0xfffff8000f79a080 (20180209/dsargs-472) >>>> ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, >>>> AE_AML_INTERNAL (20180209/psparse-677) >>>> ACPI Error: Method parse/execution failed \134_SB.AC._PSR, >>>> AE_AML_INTERNAL (20180209/psparse-677) >>>> >>>> I noticed this starting from a CURRENT build i installed two weeks >>>> ago, and still see it from a world/kernel i built last night.  two >>>> questions: >>>> 1) has anyone else noticed this? >>>> 2) is this something to worry about? >>>> >>>> i can help debug the issue but am not sure where to start poking. >>>> >>>> thanks! >>>> -pete >>>> >>> Here I have >>> >>> ACPI Error: No pointer back to namespace node in package >>> 0xfffff8000171f700 (20180209/dsargs-472) >>> ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName >>> unavailable] (20180209/dswexec-606) >>> ACPI Error: Method parse/execution failed >>> \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677) >>> >>> with svn 329142 on a Lenovo ThinkCentre M83 >>> ACPI APIC Table: >>> >>> Claude Buisson >> I believe you can silence the errors with the attached patch. Please >> try it and let me know. > hrm still getting errors: > > Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to > namespace node in package 0xfffff80003c8c080 (20180209/dsargs-472) > Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution > failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) > Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution > failed \_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) > > > here's my diff: > diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h > b/sys/contrib/dev/acpica/include/platform/acfreebsd.h > index 905dffb7a40..df89399a369 100644 > --- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h > +++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h > @@ -166,6 +166,7 @@ > >  #define ACPI_UINTPTR_T      uintptr_t > > +#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS >  #define ACPI_USE_DO_WHILE_0 >  #define ACPI_USE_LOCAL_CACHE >  #define ACPI_USE_NATIVE_DIVIDE > > hi there - i was wondering if anyone has taken a look at this issue.  I am still seeing these ACPI errors on recent CURRENT systems: ACPI Error: No pointer back to namespace node in package 0xfffff803e71fff00 (20180313/dsargs-472) ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, AE_AML_INTERNAL (20180313/psparse-677) ACPI Error: Method parse/execution failed \134_SB.AC._PSR, AE_AML_INTERNAL (20180313/psparse-677) I have two amd64 (skylake and kabylake) systems that are exhibiting this behavior and am more than happy to test patches or other things. cheers! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Wed Mar 28 19:09:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A6BF7064C for ; Wed, 28 Mar 2018 19:09:39 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4152F7E223 for ; Wed, 28 Mar 2018 19:09:38 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yw0-x235.google.com with SMTP id e17so1173614ywa.1 for ; Wed, 28 Mar 2018 12:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=v+Qphah8FrBfEcSB4PbSB9CAjd0hfTiTnjUdoR/8rjU=; b=EsJ2SrtpnL7aCXi2iOhpI5Fr+ss3m16zTg7JRHVNiRo+FID4deUENEU9OKFXxLjD66 UIFdsTDGVKm1U69trAQ5xGd29uu1I4FtM6kV26BY9DUyRBBx0m82gFuSI2TPt3t8OwKg 9J5ITgnjMzdYUiN7qckHk7uc70oboM/ASuzIsWpgPvMPe2YA2AlyL/+/twryunPjLMzs dVlVT4/afn7wg1OU5ZIDoVVNV2nDEKsWMNQRn3ZwMIqXGopOE1O8WjGYYmmoTJMdnMx1 1QcT6LigPdg0IuFZYzv9WNdZpj8px2L6fX0E9eTIvqaCLYpmdE0BX9lg+ZG6EUv6D7qO 7WAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=v+Qphah8FrBfEcSB4PbSB9CAjd0hfTiTnjUdoR/8rjU=; b=s7yN0U75j4OOpwo8i+KupXdKAlN5Bn1/KVtfEVH7LNj7lToqP8oPEf7eNOTU72HeNn 4UKJ1+U5TLFWF+NrNV/qNY3ci10VA9rG5zZkp+Dk0VZgzvqbp9C9S9nDsgE8/6gHZhUM WtisOCr0ZPkIaKAr/z1qBohEInQOolglCQ4Ps08fZOKhYkKQNryeVYqd8eTCZF5mScwy d5blQttAq/FIf3gT5KmAAJnP62V6hB2HVmK63y7MM5KUO+itCOBy7ZkVy0IpSTv8phLw hqbGQoRJWfl+k7Kv1NdqC59azS2fCBKGssueKR1OvhXJFXISieGMWb7jlF0q/EEQvzsP 82rQ== X-Gm-Message-State: AElRT7Ghssy8N6pqdEG+cV2EMPwiVKFZzpy3iCVWhjlntRXvtLQwEX4q xA3v/sROT5tamZD7WQF7Zx1kuc/43XOl4V41RJLtvzcmifnWqsRd3R69Z8v7LCr2yuBcpvnanh3 8QshRl6yLWbuzzc+xRLIEDRm2ZRkA2OevVZcxtJW4j2e7hdCLh+zpMaFK3sJHilsHk4SkvipwV8 i/i9aMl9dd1wY= X-Google-Smtp-Source: AIpwx4/jtrPgvF710kHpIaMESN2tsFITAGXAGEjLQEv0/+WFbD01kRo0Y/DoU8L5mYDaJ9aGlddASQ== X-Received: by 10.13.225.145 with SMTP id k139mr3145085ywe.399.1522264178212; Wed, 28 Mar 2018 12:09:38 -0700 (PDT) Received: from [10.0.0.220] (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id j1sm1627837ywi.99.2018.03.28.12.09.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 12:09:37 -0700 (PDT) Subject: Re: r331650 breaks amd64 kernel build From: Ian FREISLICH To: FreeBSD Current References: <6f91516c-55c5-6e86-61db-918d9bb83faa@capeaugusta.com> Message-ID: <51cc5207-8282-c57c-ec56-ee7315f5b720@capeaugusta.com> Date: Wed, 28 Mar 2018 15:09:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6f91516c-55c5-6e86-61db-918d9bb83faa@capeaugusta.com> Content-Type: text/plain; charset="UTF-8" Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 19:09:39 -0000 On 03/28/2018 11:11 AM, Ian FREISLICH wrote: > Hi > > (As noted by Oliver Hartman in svn-src-all@) > > r331650 breaks amd64 kernel build as follows: > > --- machdep.o --- > /usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier > 'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT; > ^ Appears fixed in r331681 Ian -- From owner-freebsd-current@freebsd.org Wed Mar 28 19:23:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 397B1F70D4B for ; Wed, 28 Mar 2018 19:23:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 BA0FC7EC9D for ; Wed, 28 Mar 2018 19:23:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id d7so4822908ioc.11 for ; Wed, 28 Mar 2018 12:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=StDL28XsFMYr8/J8x0CnRa3zvpR9HoGorqG5hwrOLoU=; b=dZE/vSQbmNYa8L82+0S0bY8a1UKXty9HnLKs7ffp5Yrrc1ntKJAo3I0gNopZ/w83GM zaCvo2N+mqwCm9gEirwRDoStoPRzpDVwGdVedLlY/p11VtEH/Uy6yTUwOIB0IbXWKJR6 mZa+7eeVFtojarXL0VENyMz9xhXgNDH5XUJcD21hPtek8iEXiBJPU7iLvz+98jO45BPb RPPTN625Mz8eMJEE+OKMZLsmXNM6ND4/r2rfhxcM0y4inZem1R171O4L8SnNYs4kNVjA kXa2kQNBQMo2dHqLu0tYqIneM8NH6uh/3eSyyFB3oCZYRBEFLD8oJThSetQW4lNgy2Wv STGQ== 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=StDL28XsFMYr8/J8x0CnRa3zvpR9HoGorqG5hwrOLoU=; b=kflsf+dHT4uLdlNJ9y+M5gO0mnh2cy1igIim6e/aNrGTs+aftTkt0bF5rEdMo5X3um nBKzeA1xckbsxFIcJxVAgk3i/NGSuWIDtXtxA/wbizAbXlTatwz7RJuwNI8Cm/gZQRJy gnHok05LMvQfI9N4qmLoVDc6+V6NKbg01EYVMOlo80HLWAqOS9W8+VIv20GuZ2Q4sdfs zWDfgQW6tfM+yyoxM/WtEq6mLz/MmZ5AtOeWsC3kvw6x5f7QlIEZ3CXzbrZfIpGUongx XM46T/dFJF9jimVuk83CS38wiWCSuh3SC6MS+h7Uufsm5KOcR9GKJFG/ZwLZxUzgZP7S n+Bg== X-Gm-Message-State: AElRT7EBhtgoUwwymzByHaTPYzL5ZT8uTL/CCMNUDZ6XkhCxbOdaXN+f g8inGCwpsUWp1L8EVid7BjzB8y7YWm/wmikI8zJt4A== X-Google-Smtp-Source: AG47ELvOdBYs/G3zW1zCN/lbNXivMgpRrSglo1vZVNobAiDENG+JRXFDwKeqRe8dXMkN0e+WgpkGM5Pc9xHU/vPkGmk= X-Received: by 10.107.162.146 with SMTP id l140mr44315112ioe.39.1522265004488; Wed, 28 Mar 2018 12:23:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Wed, 28 Mar 2018 12:23:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:811:70b8:3eb8:9dfe] Received: by 10.79.203.196 with HTTP; Wed, 28 Mar 2018 12:23:23 -0700 (PDT) In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Warner Losh Date: Wed, 28 Mar 2018 12:23:23 -0700 X-Google-Sender-Auth: m2boyXrSxNiQ4ZFUUtzZMNwQKQM Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Tommi Pernila Cc: Eric McCorkle , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 19:23:26 -0000 It's on my list for nexr, finally. I have an alternate patch for loader.efi from ESP, but i don't think it will affect the GELI stuff. I have some time slotted for integration issues though. I am quite mindful of the freeze dates.... I have some uefi boot loader protocol changes that I need to get in. Warner On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrote: > Awesome, thanks for the update and the work that you have done! > > Now we just need some more reviewers eyes on the code :) > > Br, > > Tommi > > On Thu, 22 Feb 2018 at 2.03, Eric McCorkle wrote: > >> FYI, I just IFC'ed everything, and the current patches are still fine. >> >> Also, the full GELI + standalone loader has been deployed on one of my >> laptops for some time now. >> >> On 02/21/2018 18:15, Eric McCorkle wrote: >> > The GELI work could be merged at this point, though it won't be usable >> > without an additional patch to enable loader-only operation. The >> > patches are currently up for review: >> > >> > This is the order in which they'd need to be merged: >> > >> > >> > https://reviews.freebsd.org/D12732 >> > >> > This one changes the efipart device. Toomas Soome identified some >> > problems, which I have addressed. He has not re-reviewed it, however. >> > >> > >> > https://reviews.freebsd.org/D12692 >> > >> > This adds some crypto code needed for GELI. It simply adds new code, >> > and doesn't conflict with anything. >> > >> > >> > https://reviews.freebsd.org/D12698 >> > >> > This adds the EFI KMS interface code, and has the EFI loader pass keys >> > into the keybuf interface. >> > >> > >> > I can't post the main GELI driver until those get merged, as it depends >> > on them. It can be found on the geli branch on my github freebsd >> > repository, however. >> > >> > >> > Additionally, you need this patch, which allows loader.efi to function >> > when installed directly to the ESP: >> > >> > https://reviews.freebsd.org/D13497 >> > >> > On 02/20/2018 22:56, Tommi Pernila wrote: >> >> Hi Eric, >> >> >> >> could you provide a brief update how the work is going? >> >> >> >> >> >> Br, >> >> >> >> Tommi >> >> >> >> >> >> On Nov 16, 2017 04:29, "Eric McCorkle" > >> > wrote: >> >> >> >> Right, so basically, the remaining GELI patches are against >> loader, and >> >> most of them can go in independently of the work on removing boot1. >> >> There's a unanimous consensus on getting rid of boot1 which >> includes its >> >> original author, so that's going to happen. >> >> >> >> >> >> For GELI, we have the following (not necessarily in order): >> >> >> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf >> >> interactions >> >> b) Modifications to the efipart driver >> >> c) boot crypto >> >> d) GELI partition types (not strictly necessary) >> >> >> >> Then there's the GELI driver itself. (a) and (c) are good to >> land, (b) >> >> needs some more work after Toomas Soome pointed out a legitimate >> >> problem, and (d) actually needs a good bit more code (but again, >> it's >> >> more cosmetic). Additionally, the GELI driver will need further >> mods to >> >> efipart to be written (nothing too big). But we could go ahead >> with (a) >> >> and (c), as they've already been proven to work. >> >> >> >> I'd wanted to have this stuff shaped up sooner, but I'm >> preoccupied with >> >> the 7th RISC-V workshop at the end of the month. >> >> >> >> Once this stuff is all in, loader should handle any GELI volumes it >> >> finds, and it should Just Work once boot1 is gone. >> >> >> >> >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> freebsd.org" >> > >> > From owner-freebsd-current@freebsd.org Wed Mar 28 19:25:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC859F70E5E for ; Wed, 28 Mar 2018 19:25:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 89A757EDE8; Wed, 28 Mar 2018 19:25:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.82.237.131] (mobile-107-107-61-156.mycingular.net [107.107.61.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id E3F22756B; Wed, 28 Mar 2018 19:25:29 +0000 (UTC) Date: Wed, 28 Mar 2018 15:25:27 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> MIME-Version: 1.0 Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Warner Losh ,Tommi Pernila CC: "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org From: Eric McCorkle Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 19:25:37 -0000 I'll do another rebase from head just to be sure=20 On March 28, 2018 3:23:23 PM EDT, Warner Losh wrote: >It's on my list for nexr, finally=2E I have an alternate patch for >loader=2Eefi >from ESP, but i don't think it will affect the GELI stuff=2E I have some >time >slotted for integration issues though=2E > >I am quite mindful of the freeze dates=2E=2E=2E=2E I have some uefi boot >loader >protocol changes that I need to get in=2E > >Warner > >On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrot= e: > >> Awesome, thanks for the update and the work that you have done! >> >> Now we just need some more reviewers eyes on the code :) >> >> Br, >> >> Tommi >> >> On Thu, 22 Feb 2018 at 2=2E03, Eric McCorkle >wrote: >> >>> FYI, I just IFC'ed everything, and the current patches are still >fine=2E >>> >>> Also, the full GELI + standalone loader has been deployed on one of >my >>> laptops for some time now=2E >>> >>> On 02/21/2018 18:15, Eric McCorkle wrote: >>> > The GELI work could be merged at this point, though it won't be >usable >>> > without an additional patch to enable loader-only operation=2E The >>> > patches are currently up for review: >>> > >>> > This is the order in which they'd need to be merged: >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12732 >>> > >>> > This one changes the efipart device=2E Toomas Soome identified some >>> > problems, which I have addressed=2E He has not re-reviewed it, >however=2E >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12692 >>> > >>> > This adds some crypto code needed for GELI=2E It simply adds new >code, >>> > and doesn't conflict with anything=2E >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12698 >>> > >>> > This adds the EFI KMS interface code, and has the EFI loader pass >keys >>> > into the keybuf interface=2E >>> > >>> > >>> > I can't post the main GELI driver until those get merged, as it >depends >>> > on them=2E It can be found on the geli branch on my github freebsd >>> > repository, however=2E >>> > >>> > >>> > Additionally, you need this patch, which allows loader=2Eefi to >function >>> > when installed directly to the ESP: >>> > >>> > https://reviews=2Efreebsd=2Eorg/D13497 >>> > >>> > On 02/20/2018 22:56, Tommi Pernila wrote: >>> >> Hi Eric, >>> >> >>> >> could you provide a brief update how the work is going? >>> >> >>> >> >>> >> Br, >>> >> >>> >> Tommi >>> >> >>> >> >>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >> >> > wrote: >>> >> >>> >> Right, so basically, the remaining GELI patches are against >>> loader, and >>> >> most of them can go in independently of the work on removing >boot1=2E >>> >> There's a unanimous consensus on getting rid of boot1 which >>> includes its >>> >> original author, so that's going to happen=2E >>> >> >>> >> >>> >> For GELI, we have the following (not necessarily in order): >>> >> >>> >> a) Adding the KMS interfaces, pseudo-device, and kernel >keybuf >>> >> interactions >>> >> b) Modifications to the efipart driver >>> >> c) boot crypto >>> >> d) GELI partition types (not strictly necessary) >>> >> >>> >> Then there's the GELI driver itself=2E (a) and (c) are good to >>> land, (b) >>> >> needs some more work after Toomas Soome pointed out a >legitimate >>> >> problem, and (d) actually needs a good bit more code (but >again, >>> it's >>> >> more cosmetic)=2E Additionally, the GELI driver will need >further >>> mods to >>> >> efipart to be written (nothing too big)=2E But we could go >ahead >>> with (a) >>> >> and (c), as they've already been proven to work=2E >>> >> >>> >> I'd wanted to have this stuff shaped up sooner, but I'm >>> preoccupied with >>> >> the 7th RISC-V workshop at the end of the month=2E >>> >> >>> >> Once this stuff is all in, loader should handle any GELI >volumes it >>> >> finds, and it should Just Work once boot1 is gone=2E >>> >> >>> >> >>> > _______________________________________________ >>> > freebsd-current@freebsd=2Eorg mailing list >>> > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >>> freebsd=2Eorg" >>> > >>> >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Wed Mar 28 20:11:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7BB5F71E3E for ; Wed, 28 Mar 2018 20:11:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 3146980B2F; Wed, 28 Mar 2018 20:11:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id m16-v6so5263242lfc.4; Wed, 28 Mar 2018 13:11:08 -0700 (PDT) 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=JkcvS6tlcQeSOT/oE5Yw+hwWWWLDwCrau8qHHKXrl9k=; b=XWcMfX6sS8uMJJ373PPXrxZxctqQ9tsoUybBbLsjvTKoeldOxhErVTNo5msWjkkqk4 3J8uemJXMcqWBkhz87NTyVZtInXgyUONDSi/poR02fCnyvNf4v2D27OuYYCdVpNqyJOp 0WJ9/eAR5GHeTsPaOFpl72lNe78izT9eZJCWqFZNPP6QLXaWSVpLAtoJN7opaw65lICr BwGp2Tkd6sjRL9hvF/pe26eXdu1JkFjOOt7USGUPjhzCrnb5cma43e7BltEZ4EaYwx6H p8FwbwbJqMt7snPVeITfzW4LGzZAwI6gXhLKGdq/ZCdL5DdkjeyEv9l9R1wLTIfp8g3c OsIg== X-Gm-Message-State: AElRT7HZ6BiAcVDihLZgb2jMhMD3b6o/H9d5Jao3ijdbCD9stiFOpUjE jkqZPltB0+v+gsWG66Qc3zuXSgj+ X-Google-Smtp-Source: AIpwx49JnkXqwuAcJJpaE/qNGyShrnIC8RsHh7Qmo6zFRPtctBs0T1SRUihDqwnqshCe7yBGMyJwQA== X-Received: by 2002:a19:e48e:: with SMTP id x14-v6mr3387773lfi.115.1522267860485; Wed, 28 Mar 2018 13:11:00 -0700 (PDT) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com. [209.85.215.51]) by smtp.gmail.com with ESMTPSA id d24-v6sm813268lfc.51.2018.03.28.13.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 13:11:00 -0700 (PDT) Received: by mail-lf0-f51.google.com with SMTP id v207-v6so5243633lfa.10; Wed, 28 Mar 2018 13:11:00 -0700 (PDT) X-Received: by 10.46.155.204 with SMTP id w12mr3345929ljj.76.1522267859996; Wed, 28 Mar 2018 13:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Wed, 28 Mar 2018 13:10:39 -0700 (PDT) In-Reply-To: References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Kyle Evans Date: Wed, 28 Mar 2018 15:10:39 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Boot failure: panic: No heap setup To: Stefan Esser Cc: "" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 20:11:09 -0000 On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser wrote: > Am 27.03.18 um 21:31 schrieb Kyle Evans: >> >> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote: >>> >>> A few weeks ago I tried the LUA boot and found, that my kernel did not >>> start >>> (i.e. did not print the initial FreeBSD version line), but instead >>> stopped >>> with: >> >> >> Oy =/ >> >>> panic: No heap setup >>> >>> I recovered by booting from an alternate boot device and kept my system >>> running until today, where I decided to give the LUA boot another try. >>> >>> The boot failure happened again, with identical message: >>> >>> panic: No heap setup >> >> >> Hmm... that's an sbrk panic [1], indicating that setheap hadn't been >> called. zfsgptboot is zfsboot with gpt bits included, so the relevant >> setheap call is [2] I believe. It's not immediately clear to me how >> switching interpreters could actually be breaking it in this way. >> >> At what point are you hitting this panic? After menu, before kernel >> transition? > > > The menu is displayed and I can unload the kernel and load the kernel > and modules from an alternate path. The lua code seems to work just fine, > but as soon as I enter the "boot" command, the panic happens. > > This happens when the loader transfers control to the kernel but before > any other output is generated. I tried booting a GENERIC kernel just to > be sure this is not caused by an out-dated kernel config file. > >>> I tried booting a GENERIC kernel, but only rebuilding the boot loader >>> (gptzfsloader in my case) without LUA support fixed the issue for me ... >>> >>> The system is -CURRENT (built today) on amd64 (not converted to UEFI, >>> yet). > > > Hmmm, the code references point into the boot loader code - I had > expected that there is a problem in the kernel, not the boot loader. > >> [1] >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 > > > Seems that setbase has either not been called or has been called with > base=0. Right, which is odd... >> [2] >> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 > > > I had thought, that the zfs boot code has been initialized before the > menu is displayed? Right, all of this should be done looooong before we get to the interpreter. Can you break into the loader prompt and try the `heap` command, see what that outputs? CC'ing imp@ because he actually knows things. > Or do I misunderstand this phase of the boot process??? > > Regards, STefan From owner-freebsd-current@freebsd.org Wed Mar 28 20:24:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07729F722B8 for ; Wed, 28 Mar 2018 20:24:17 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wilcox-tech.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C353812BE for ; Wed, 28 Mar 2018 20:24:16 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 15553 invoked from network); 28 Mar 2018 20:17:31 -0000 Received: from 107-131-85-28.lightspeed.tulsok.sbcglobal.net (HELO ?192.168.1.237?) (awilcox@wilcox-tech.com@107.131.85.28) by mail.wilcox-tech.com with ESMTPA; 28 Mar 2018 20:17:31 -0000 Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) To: Nathan Whitehorn , Sean Fertile , marklmi26-fbsd@yahoo.com Cc: chmeeedalf@gmail.com, emaste@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org References: From: "A. Wilcox" Message-ID: <7e000df1-6f91-b255-3548-3faa2968d17e@Wilcox-Tech.com> Date: Wed, 28 Mar 2018 15:17:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JPTEQkTl4zjt8z543zTbGgrOHbVwPzMRE" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 20:24:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JPTEQkTl4zjt8z543zTbGgrOHbVwPzMRE Content-Type: multipart/mixed; boundary="RW28kyw8aStgcFj2C1YJKzrQfODWanLqh"; protected-headers="v1" From: "A. Wilcox" To: Nathan Whitehorn , Sean Fertile , marklmi26-fbsd@yahoo.com Cc: chmeeedalf@gmail.com, emaste@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org Message-ID: <7e000df1-6f91-b255-3548-3faa2968d17e@Wilcox-Tech.com> Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) References: In-Reply-To: --RW28kyw8aStgcFj2C1YJKzrQfODWanLqh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 03/28/18 13:38, Nathan Whitehorn wrote: > Is this big-endian support or V1 support being removed? We support=20 > the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on=20 > Linux, the default ABI on big-endian will likely remain V1 for the=20 > indefinite future, This is an important distinction to make (big-endian !=3D ELFv1, and ELFv= 1 !=3D big-endian). But do note that on Linux, the musl libc (in use by distros like Alpine, Ad=C3=A9lie, postmarketOS) only supports ELFv2, even in big-endian mode. = And as the maintainer of Ad=C3=A9lie using it as a daily-driver on an iMac G5= , it's definitely something you can use (the only breakage I've seen so far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function descriptors anyway). So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to keep LLVM happy. It'd be some effort but it should work. If this is really something FreeBSD is interested in, you might even manage to convince me to put on my ports hat again, to help get the JIT patches in that are needed for upstreams that went comatose. Best, --arw > however, and it would be good if it were at least simple to re-add=20 > support at some later date. -Nathan >=20 --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --RW28kyw8aStgcFj2C1YJKzrQfODWanLqh-- --JPTEQkTl4zjt8z543zTbGgrOHbVwPzMRE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjNyWOYPU1SaTSMHHyynLUZIrnRQFAlq7+HIACgkQyynLUZIr nRTVaw//Q2LNcz77vojZsBmTEtDO6Va+6rudqKz4S8+xxZtdS/uPCRCq1VlyzQqh pTie8lRxHxy7VhbAhtdBE/p1bJrbQRd28/BSFcSgA+8fXpV09EYi4DHuF6rpPKZr NSJeYfLJSCX4RmI3vsV66oO9qOKklBuOFPEhlJGxKK2VE51XfefAlQAEWcL0nCmK svluVNH8EZQHm5SLEX0Takm9K98WA+8nskYw2wC2kfko9tZfoBQFSgCzBMBdRlBQ /oRzuYAkp4VciucjiYQvdSqQki+hSz+7Ms5reZ8IhteFxn+AvrwmuVhUCkC7sXDh Dbb0FcHS6oSVjsqH9eMdgR4YWVvVzajXnfVFLS1mhfs9RQwZEfKAbhIvJY+Yti8y yPWcGvxGYRZtSJ3atsLZGdybq8r93eyJYsn2hSsTE/UjZKcpUr3VWswZc4XiWoJ+ vngrl6wWK2Sq1JMIJtUyUyY3FxhsflAvn8Pt8o2a9ROz5bH9WwPq/1SCvCNVif7/ tUhetraLRrhvuNFoQOXo4XYFrDMhkUWyICL0yWsxLhW6OXQVZ6scp4jHHb3PfMhT j/dBH+kWaVc5TMsEcW8YHqN2mgpbeD4lHUsGPuR/Lg7zedt6sQNMXZ6PJSaSxDED k7p47/fzuEPHXeYNlKHoOQUT+rWghJ55110O1M4sh7Jgc7pnUKA= =57Z8 -----END PGP SIGNATURE----- --JPTEQkTl4zjt8z543zTbGgrOHbVwPzMRE-- From owner-freebsd-current@freebsd.org Wed Mar 28 20:28:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B6C4F723CC for ; Wed, 28 Mar 2018 20:28:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF60C81477 for ; Wed, 28 Mar 2018 20:28:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id z143-v6so20677275itc.0 for ; Wed, 28 Mar 2018 13:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BVkLl7Zg0bh6uOpWPMi2jJD8f9vTwLTT2Hpvnz3NkIU=; b=nvZTC0HNSrPOWdLcbCWX9te1mfrqfefpwraQLk3KIFVtC2NCFy0XJh4+64V2fbLbq/ 9WC62OLS+smKI3GyjIv2KA2PKsakYwN5l/nrtLCxb1ZFcZtwDQb01P/0JZwpZIe2zUs0 sy7FtoKPr+C8yygNxlgVBMdReLkxN6f1aeDywOZQ9q+icvnQ+V6y96o3gBze9KDU8eE9 7ctB+p4MWx0MibwrGWHC9X+OuSb1FonvI9JGpV7tMj8bH65OUQTpj59xJPaVA96TDOJv GFJ/S9KQ93KAC6WZdsIFIBrnj4DKGfL+0tfoaQKTZu3/j2yQYYvQdSguc853uLZmKyHX 2TYw== 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=BVkLl7Zg0bh6uOpWPMi2jJD8f9vTwLTT2Hpvnz3NkIU=; b=h6n6F89rABA8y5CNtRDF0Lg3Ip/ZJHpp/T2/+tuGYwHY4XWq8Sk1j8LeI8TFjwJc3f nV/ZLoA7nBKKRswhK5wyNHdGmG8dZ52dseYanppSWo/urm2bJZ9jrqy8hiQpalDV4xHj Nk9OAacH5BWw8Hw7F/p05EuotsKf7f02wiaG1XsQS1aa+jRWn2tW4j0uG1OcGpPFywQo ftsUPt7R4nxl4w0R2jSpqiIqKs2BioNXHKEJ2Ir12rHryEhN3Vi8304jAxWe9uoQokhK CwfJYYhxYqNP1a0e7DqxoPBQ/1wCAV4ZWgBMlDAs/ADb0WXX95GOz9piqJVM3+h7E96z 8j3w== X-Gm-Message-State: AElRT7G8TfEmGRFqeT5/YDwx4z+BXmWvWUQa9HZ7m7rYdjRpM9o0fkkn 699aTZqY/M7bgeyPFvP2nHEvhHUqTVjbN4AdztBeiw== X-Google-Smtp-Source: AIpwx49BoktgrGkmhdUJWhPNF87+vOaFE/pzO4OIa80tzknXiMWKvRk1XQclK1Kfw4xs8hHQfXLZV99dh3lP2mU/u6s= X-Received: by 2002:a24:19c9:: with SMTP id b192-v6mr3840716itb.1.1522268909936; Wed, 28 Mar 2018 13:28:29 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Wed, 28 Mar 2018 13:28:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Warner Losh Date: Wed, 28 Mar 2018 13:28:29 -0700 X-Google-Sender-Auth: Qfw2nMVY7tHYPvgT1kEy_wzONNQ Message-ID: Subject: Re: Boot failure: panic: No heap setup To: Kyle Evans Cc: Stefan Esser , "" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 20:28:31 -0000 On Wed, Mar 28, 2018 at 1:10 PM, Kyle Evans wrote: > On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser wrote: > > Am 27.03.18 um 21:31 schrieb Kyle Evans: > >> > >> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote: > >>> > >>> A few weeks ago I tried the LUA boot and found, that my kernel did not > >>> start > >>> (i.e. did not print the initial FreeBSD version line), but instead > >>> stopped > >>> with: > >> > >> > >> Oy =/ > >> > >>> panic: No heap setup > >>> > >>> I recovered by booting from an alternate boot device and kept my system > >>> running until today, where I decided to give the LUA boot another try. > >>> > >>> The boot failure happened again, with identical message: > >>> > >>> panic: No heap setup > >> > >> > >> Hmm... that's an sbrk panic [1], indicating that setheap hadn't been > >> called. zfsgptboot is zfsboot with gpt bits included, so the relevant > >> setheap call is [2] I believe. It's not immediately clear to me how > >> switching interpreters could actually be breaking it in this way. > >> > >> At what point are you hitting this panic? After menu, before kernel > >> transition? > > > > > > The menu is displayed and I can unload the kernel and load the kernel > > and modules from an alternate path. The lua code seems to work just fine, > > but as soon as I enter the "boot" command, the panic happens. > > > > This happens when the loader transfers control to the kernel but before > > any other output is generated. I tried booting a GENERIC kernel just to > > be sure this is not caused by an out-dated kernel config file. > > > >>> I tried booting a GENERIC kernel, but only rebuilding the boot loader > >>> (gptzfsloader in my case) without LUA support fixed the issue for me > ... > >>> > >>> The system is -CURRENT (built today) on amd64 (not converted to UEFI, > >>> yet). > > > > > > Hmmm, the code references point into the boot loader code - I had > > expected that there is a problem in the kernel, not the boot loader. > > > >> [1] > >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 > > > > > > Seems that setbase has either not been called or has been called with > > base=0. > > Right, which is odd... > > >> [2] > >> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/ > zfsboot.c?view=markup#l688 > > > > > > I had thought, that the zfs boot code has been initialized before the > > menu is displayed? > > Right, all of this should be done looooong before we get to the > interpreter. Can you break into the loader prompt and try the `heap` > command, see what that outputs? CC'ing imp@ because he actually knows > things. Totally weird. I'd add a printf to the sethead() function to display its args and see if you get this panic before/after that printf... Warner From owner-freebsd-current@freebsd.org Wed Mar 28 20:34:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3932F727DA; Wed, 28 Mar 2018 20:34:03 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E235281967; Wed, 28 Mar 2018 20:34:02 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id z143-v6so5352263lff.3; Wed, 28 Mar 2018 13:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QIyt/cEq5lpdFSX4zKTKTSt58/crO3lBAaIDzI4NiyQ=; b=Iwb2d78hdXoMl6l5opl3PQkJbICZWVVA079X4sHiqyU6W/sGRLiaPbqUUnfSvcCUPg mD62ZKWtysoIQZyYS0WHh1mnFNWmRIDGQfpNkVq9upl+fZu9+QeWv7P1ZZbPzDqrhqW7 4RuKxhhJCqrj7kIAnF5f1fQVBtPvQRmoJ9Lc4YgbFuA6sheytS0VECVRAvUAlsMgYPrt sVjcjh/GVRf83jjLI5vjYPQ242SZ5LWm0sfGHcSIXJwBiydAMg9y1LIa2h/+v9wiiuR7 ylffwuCs7GzcflLZCMitZsTzTZUCHMkwx+TeGiplILfVGtaqM4a9wdnunVc1JhsIkcsH 5Vow== 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=QIyt/cEq5lpdFSX4zKTKTSt58/crO3lBAaIDzI4NiyQ=; b=ZSbjvjoTnGew9jtHDz5WPafZavMTrEaipfqcISmnTBKoC/LVDbiaMqf7m2SlUF8tlx gVz62C4DyhRa9fR7Aq9xBKLogMj+L9Ogdbg3dkfruYKimE8V8cWA5LJCSJYb/mUVp5EJ U7PyOivX176ydKOB5jVGHCHAU1VmpScfEFqFoB0bxDxzHWmVxK9xs47UQmsDl3Pdo1Oz IX/tJr9I/IH04os4h8bap8ARVQKtronNj1rmm+e1Lw2P2kSX1LS7N70qh8FKu/ZxKW8Y qnGGyfIby9JRjuYm28SAjBh8xWbGSjVAltuAZt5Q8f1f9+wsS6XcY65fRCkbcc5I+nRp 5EpQ== X-Gm-Message-State: AElRT7FiyhLhwF4jAu8WyALEpxEfbR8XBwnoSbTtlHJm/H3lLnap/Gjx Mkg2hCcB1wD2UxHb7PyTi4/VrryvN3BhdhqH/yU= X-Google-Smtp-Source: AIpwx485uqbXpVL/aAb6n5luPns+naaDrvCj6Z9ikRjuxqcQuNZYJZogjLIhWDTl2LrNKqkcAf2a+G8TCEB1H/RNJ4k= X-Received: by 2002:a19:2044:: with SMTP id g65-v6mr3497915lfg.0.1522269241346; Wed, 28 Mar 2018 13:34:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.85.13 with HTTP; Wed, 28 Mar 2018 13:34:00 -0700 (PDT) In-Reply-To: <7e000df1-6f91-b255-3548-3faa2968d17e@Wilcox-Tech.com> References: <7e000df1-6f91-b255-3548-3faa2968d17e@Wilcox-Tech.com> From: Justin Hibbits Date: Wed, 28 Mar 2018 15:34:00 -0500 Message-ID: Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) To: "A. Wilcox" Cc: Nathan Whitehorn , Sean Fertile , marklmi26-fbsd@yahoo.com, Ed Maste , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 20:34:03 -0000 On Wed, Mar 28, 2018 at 3:17 PM, A. Wilcox wrote: > On 03/28/18 13:38, Nathan Whitehorn wrote: >> Is this big-endian support or V1 support being removed? We support >> the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on >> Linux, the default ABI on big-endian will likely remain V1 for the >> indefinite future, > > This is an important distinction to make (big-endian !=3D ELFv1, and ELFv= 1 > !=3D big-endian). > > But do note that on Linux, the musl libc (in use by distros like Alpine, > Ad=C3=A9lie, postmarketOS) only supports ELFv2, even in big-endian mode. = And > as the maintainer of Ad=C3=A9lie using it as a daily-driver on an iMac G5= , > it's definitely something you can use (the only breakage I've seen so > far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function > descriptors anyway). > > So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to > keep LLVM happy. It'd be some effort but it should work. > > If this is really something FreeBSD is interested in, you might even > manage to convince me to put on my ports hat again, to help get the JIT > patches in that are needed for upstreams that went comatose. > > > Best, > --arw > > >> however, and it would be good if it were at least simple to re-add >> support at some later date. -Nathan >> > > -- > A. Wilcox (awilfox) > Open-source programmer (C, C++, Python) > https://code.foxkit.us/u/awilfox/ > Moving to ELFv2 is predicated on having a complete toolchain supporting it. Right now, base gcc+binutils only supports ELFv1, and we cannot upgrade to newer toolchain yet. - Justin From owner-freebsd-current@freebsd.org Wed Mar 28 22:06:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB98DF7641B for ; Wed, 28 Mar 2018 22:06:53 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 810AC84E46; Wed, 28 Mar 2018 22:06:53 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de [172.20.27.64]) by mailout04.t-online.de (Postfix) with SMTP id EBC6741AFF81; Thu, 29 Mar 2018 00:06:45 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (TWopYaZLQh1ZGG5OUc+bsb8UaovcKxCur7tELlGlgy0U-9YRvUGSnldsQo9AibPZqI@[87.151.209.250]) by fwd17.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f1JDR-4faQJE0; Thu, 29 Mar 2018 00:06:45 +0200 Subject: Re: Boot failure: panic: No heap setup To: Warner Losh References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Stefan Esser Cc: Kyle Evans , FreeBSD Current Message-ID: Date: Thu, 29 Mar 2018 00:06:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ID: TWopYaZLQh1ZGG5OUc+bsb8UaovcKxCur7tELlGlgy0U-9YRvUGSnldsQo9AibPZqI X-TOI-MSGID: e5a01b17-ac65-42bb-9463-168dd46a1094 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 22:06:54 -0000 Am 28.03.18 um 22:28 schrieb Warner Losh: > > Hmmm, the code references point into the boot loader code - I had > > expected that there is a problem in the kernel, not the boot loader. > > > >> [1] > >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 > > > > > > > Seems that setbase has either not been called or has been called with > > base=0. > > Right, which is odd... > > >> [2] > >> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 > > > > > > > I had thought, that the zfs boot code has been initialized before the > > menu is displayed? > > Right, all of this should be done looooong before we get to the > interpreter. Can you break into the loader prompt and try the `heap` > command, see what that outputs? CC'ing imp@ because he actually knows > things. > > Totally weird. I'd add a printf to the sethead() function to display its args > and see if you get this panic before/after that printf... I'm currently using a Forth-enabled boot loader again, since this is a "production" machine (my home server, which also receives and keeps all my work email, for example). I'll build a clean world with the LUA loader and test it on one of the next days. Tests will include the "heap" loader command and I'll add the printf (though, if sbrk() has really not been called, I guess that will not go too well ...). Is it possible, that the setheap function is called a second time, just before jumping into the kernel? (In that case adding the printf might crash the loader in the first setheap call ...) Since the loader menu (and escaping from the menu) works, there must be a valid heap, at that time. Regards, STefan From owner-freebsd-current@freebsd.org Wed Mar 28 18:22:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91594F6F0AE for ; Wed, 28 Mar 2018 18:22:54 +0000 (UTC) (envelope-from prvs=06258ac586=sfertile@ca.ibm.com) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26B197BBD2 for ; Wed, 28 Mar 2018 18:22:53 +0000 (UTC) (envelope-from prvs=06258ac586=sfertile@ca.ibm.com) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2SILnVx118246 for ; Wed, 28 Mar 2018 14:22:47 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [158.85.210.114]) by mx0a-001b2d01.pphosted.com with ESMTP id 2h0f46avbv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 28 Mar 2018 14:22:47 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Wed, 28 Mar 2018 18:22:46 -0000 Received: from us1b3-smtp02.a3dr.sjc01.isc4sb.com (10.122.7.175) by smtp.notes.na.collabserv.com (10.122.47.58) with smtp.notes.na.collabserv.com ESMTP; Wed, 28 Mar 2018 18:22:40 -0000 Received: from us1b3-mail101.a3dr.sjc01.isc4sb.com ([10.122.105.216]) by us1b3-smtp02.a3dr.sjc01.isc4sb.com with ESMTP id 2018032818223957-808510 ; Wed, 28 Mar 2018 18:22:39 +0000 Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) In-Reply-To: From: "Sean Fertile" To: marklmi26-fbsd@yahoo.com Cc: chmeeedalf@gmail.com, emaste@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org, nwhitehorn@freebsd.org Date: Wed, 28 Mar 2018 18:22:39 +0000 Sensitivity: References: , Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 16007-1287 | IBM Domino Build SCN1805107_20180220T0755_FP3 March 05, 2018 at 16:31 X-KeepSent: B623A0BD:2F031A77-0025825E:0064A0F1; type=4; name=$KeepSent X-LLNOutbound: False X-Disclaimed: 60287 X-TNEFEvaluated: 1 X-LLNXfer: False x-cbid: 18032818-9695-0000-0000-00000298F2B8 X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.407427; ST=0; TS=0; UL=0; ISC=; MB=0.281426 X-IBM-SpamModules-Versions: BY=3.00008760; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000255; SDB=6.01009736; UDB=6.00514403; IPR=6.00789018; BA=6.00005888; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00020295; XFM=3.00000015; UTC=2018-03-28 18:22:44 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-03-28 16:33:41 - 6.00008254 x-cbparentid: 18032818-9696-0000-0000-0000E57AF831 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-28_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-Mailman-Approved-At: Wed, 28 Mar 2018 22:11:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 18:22:54 -0000 From owner-freebsd-current@freebsd.org Wed Mar 28 22:46:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D154F507A8 for ; Wed, 28 Mar 2018 22:46:52 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D64EF8724F for ; Wed, 28 Mar 2018 22:46:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: Uo2vU5cVM1n2lWqGcmkMMuYrzy5z5.TSsh4LCEYz9BfxtpMPVTeeiINhggBIM9v PzPZtU6fJytBEr5XKSD5S345FMNuqA2VpwNthyDf7Sa.od6Abfrlp7bRV6ERvo4TZP530GQAUdHn VEZXN0cs3olMIwAmk7z90YT.QyJSejtu6SbwW5sBgpHAgf8TetEVqiaMfWgJZ3197MdcPCQBdSDd 80BSjDn0Xn3g5WNF2shckVFQltO9DB4yEufKtj7.Cp_eUCBXrIYU99ybbJBkDcAC0rspYyESYcBa sRG9qDr6Evyjx5YcAq311DWOeB3ZdRlIMlT59lWF04KeG6NJPJubEiRMEt76D.NacwPAjYYi_E3C VA_lKewQs9dK04HLmfcAqY993tA3g..LiPzcd7IOlTsXEtlBFesawMVG4n0nv0VNImpT_Lbb8P2i qDlRJwxdep05IafCoQy0R5rOcLqEAxsWtimlbkjEiM7t3Lf6vzq04lgPhGud2oi33tqvTvqigI3n rluhvrCHb6GLxoNxCVf_BgKB5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Mar 2018 22:46:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5fb2a167a9fb453c21bd29e2b274652c; Wed, 28 Mar 2018 22:36:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 28 Mar 2018 15:36:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-ppc@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 22:46:52 -0000 Sean Fertile's messages are showing up empty on the list. So I'm just forwarding the two that I've gotten to the lists (and not the individuals). I think they stand fairly well on their own, so no other message history is included. On 2018-Mar-28, at 3:08 PM, Sean Fertile wrote: > This is specifically the V1 abi support in the 64-bit PowerPC target = in lld. I'm definitely guilty of conflating big-endian with V1-abi and = little-endian with V2-abi. I wasn't aware of people using the V2 abi on = big-endian machines. We can make sure to test big-endian in lit tests as = we deliver support for the V2 abi, but its unlikely I'll be able to run = big-endian programs on actual hardware . I agree that we should keep it = simple to add back the V1 abi support. > =20 > Sean On 03/28/18 11:22, Sean Fertile wrote: > Hi Mark, > =20 > Just so we are clear this is about V1 abi support in lld, not in llvm. = The compiler will still be able to produce valid code for big-endian = ppc64. > =20 > Regards > Sean =20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 28 22:08:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAD72F765B5 for ; Wed, 28 Mar 2018 22:08:29 +0000 (UTC) (envelope-from prvs=06258ac586=sfertile@ca.ibm.com) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67AEE85076 for ; Wed, 28 Mar 2018 22:08:29 +0000 (UTC) (envelope-from prvs=06258ac586=sfertile@ca.ibm.com) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2SM6DAB156757 for ; Wed, 28 Mar 2018 18:08:26 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [158.85.210.119]) by mx0b-001b2d01.pphosted.com with ESMTP id 2h0hwc3tv0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 28 Mar 2018 18:08:26 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Wed, 28 Mar 2018 22:08:25 -0000 Received: from us1b3-smtp05.a3dr.sjc01.isc4sb.com (10.122.203.183) by smtp.notes.na.collabserv.com (10.122.182.123) with smtp.notes.na.collabserv.com ESMTP; Wed, 28 Mar 2018 22:08:20 -0000 Received: from us1b3-mail101.a3dr.sjc01.isc4sb.com ([10.122.105.216]) by us1b3-smtp05.a3dr.sjc01.isc4sb.com with ESMTP id 2018032822081981-962577 ; Wed, 28 Mar 2018 22:08:19 +0000 Subject: Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message) In-Reply-To: From: "Sean Fertile" To: nwhitehorn@freebsd.org Cc: chmeeedalf@gmail.com, emaste@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org, marklmi26-fbsd@yahoo.com Date: Wed, 28 Mar 2018 22:08:20 +0000 Sensitivity: References: , Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 16007-1287 | IBM Domino Build SCN1805107_20180220T0755_FP3 March 05, 2018 at 16:31 X-KeepSent: 07D86599:BBA4B42B-0025825E:00772EFE; type=4; name=$KeepSent X-LLNOutbound: False X-Disclaimed: 49375 X-TNEFEvaluated: 1 X-LLNXfer: False x-cbid: 18032822-6115-0000-0000-0000026345EB X-IBM-SpamModules-Scores: BY=0.151791; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.360817; ST=0; TS=0; UL=0; ISC=; MB=0.277733 X-IBM-SpamModules-Versions: BY=3.00008761; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000255; SDB=6.01009811; UDB=6.00514446; IPR=6.00789094; BA=6.00005888; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00020299; XFM=3.00000015; UTC=2018-03-28 22:08:24 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-03-28 20:46:09 - 6.00008255 x-cbparentid: 18032822-6116-0000-0000-000066BC4F54 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-28_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-Mailman-Approved-At: Wed, 28 Mar 2018 23:36:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 22:08:30 -0000 From owner-freebsd-current@freebsd.org Thu Mar 29 03:56:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21FE6F71496 for ; Thu, 29 Mar 2018 03:56:02 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) (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 B9B4277835; Thu, 29 Mar 2018 03:56:01 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: by mail-qk0-f182.google.com with SMTP id o5so4711372qki.11; Wed, 28 Mar 2018 20:56:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+9EGBPzREo1VNFXqT13pmAqZffgLi53IDBLbAMhPm5Q=; b=MtLiImA5EVgg9vt1OfnMI79V5vNUv/KagdntrTmvBup+lBztGQsbuTC+nZ32lovXpA zNF/x/OauOf9h1SAenxDpp4xN0SI43otWB4FP/O5fy5ynEARSppV5myD6EJ51hAeAr/o PkaqyC0LyK1OrRWlOUcEdufG59fOObONlBcY6AcxVSJqxtNKHzOrMX/KWip2SXyzvt4Y NaUoT3HUvy0NCa74OxPFfUgBFP9FAuj7vL0W7Foj01GMSCoqdVHxyHKiZ+EM1G2D3oV4 vdfEP/14agPmZ+OiqOfkRJqdQnMf6Sd5FRvNeilx/dL3b1w+iFjf5IK531V3MgusECkF +w3Q== X-Gm-Message-State: AElRT7EI8twrhdF9eDr2K5gcdvKDnBwOrrdVq9o/VitT8MxjkVyXfgqV B9j+TlpGDNacPD6UV5luac6iwobq5CCEu7FSYx0= X-Google-Smtp-Source: AIpwx49n3341LaF3TXYejtNGdAJcuSFExlJ63J+qIwwzPRjmPAAW/pstaFAdmLqdI8AshVCPFpfGax6/ap1DPdksLgw= X-Received: by 10.55.169.207 with SMTP id s198mr8654788qke.96.1522295760722; Wed, 28 Mar 2018 20:56:00 -0700 (PDT) MIME-Version: 1.0 References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> In-Reply-To: From: Tommi Pernila Date: Thu, 29 Mar 2018 03:55:50 +0000 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 03:56:02 -0000 excellent, thanks again for all your work. On Wed, 28 Mar 2018 at 22.25, Eric McCorkle wrote: > I'll do another rebase from head just to be sure > > On March 28, 2018 3:23:23 PM EDT, Warner Losh wrote: >> >> It's on my list for nexr, finally. I have an alternate patch for >> loader.efi from ESP, but i don't think it will affect the GELI stuff. I >> have some time slotted for integration issues though. >> >> I am quite mindful of the freeze dates.... I have some uefi boot loader >> protocol changes that I need to get in. >> >> Warner >> >> On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrote: >> >>> Awesome, thanks for the update and the work that you have done! >>> >>> Now we just need some more reviewers eyes on the code :) >>> >>> Br, >>> >>> Tommi >>> >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle wrote: >>> >>>> FYI, I just IFC'ed everything, and the current patches are still fine. >>>> >>>> Also, the full GELI + standalone loader has been deployed on one of my >>>> laptops for some time now. >>>> >>>> On 02/21/2018 18:15, Eric McCorkle wrote: >>>> > The GELI work could be merged at this point, though it won't be usable >>>> > without an additional patch to enable loader-only operation. The >>>> > patches are currently up for review: >>>> > >>>> > This is the order in which they'd need to be merged: >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12732 >>>> > >>>> > This one changes the efipart device. Toomas Soome identified some >>>> > problems, which I have addressed. He has not re-reviewed it, however. >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12692 >>>> > >>>> > This adds some crypto code needed for GELI. It simply adds new code, >>>> > and doesn't conflict with anything. >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12698 >>>> > >>>> > This adds the EFI KMS interface code, and has the EFI loader pass keys >>>> > into the keybuf interface. >>>> > >>>> > >>>> > I can't post the main GELI driver until those get merged, as it >>>> depends >>>> > on them. It can be found on the geli branch on my github freebsd >>>> > repository, however. >>>> > >>>> > >>>> > Additionally, you need this patch, which allows loader.efi to function >>>> > when installed directly to the ESP: >>>> > >>>> > https://reviews.freebsd.org/D13497 >>>> > >>>> > On 02/20/2018 22:56, Tommi Pernila wrote: >>>> >> Hi Eric, >>>> >> >>>> >> could you provide a brief update how the work is going? >>>> >> >>>> >> >>>> >> Br, >>>> >> >>>> >> Tommi >>>> >> >>>> >> >>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >>> >> > wrote: >>>> >> >>>> >> Right, so basically, the remaining GELI patches are against >>>> loader, and >>>> >> most of them can go in independently of the work on removing >>>> boot1. >>>> >> There's a unanimous consensus on getting rid of boot1 which >>>> includes its >>>> >> original author, so that's going to happen. >>>> >> >>>> >> >>>> >> For GELI, we have the following (not necessarily in order): >>>> >> >>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf >>>> >> interactions >>>> >> b) Modifications to the efipart driver >>>> >> c) boot crypto >>>> >> d) GELI partition types (not strictly necessary) >>>> >> >>>> >> Then there's the GELI driver itself. (a) and (c) are good to >>>> land, (b) >>>> >> needs some more work after Toomas Soome pointed out a legitimate >>>> >> problem, and (d) actually needs a good bit more code (but again, >>>> it's >>>> >> more cosmetic). Additionally, the GELI driver will need further >>>> mods to >>>> >> efipart to be written (nothing too big). But we could go ahead >>>> with (a) >>>> >> and (c), as they've already been proven to work. >>>> >> >>>> >> I'd wanted to have this stuff shaped up sooner, but I'm >>>> preoccupied with >>>> >> the 7th RISC-V workshop at the end of the month. >>>> >> >>>> >> Once this stuff is all in, loader should handle any GELI volumes >>>> it >>>> >> finds, and it should Just Work once boot1 is gone. >>>> >> >>>> >> >>>> > _______________________________________________ >>>> > 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" >>>> > >>>> >>> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From owner-freebsd-current@freebsd.org Thu Mar 29 06:15:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91292F50F8D for ; Thu, 29 Mar 2018 06:15:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8897CC26; Thu, 29 Mar 2018 06:15:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P6C00N006JZA600@st13p35im-asmtp001.me.com>; Thu, 29 Mar 2018 05:15:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1522300506; bh=s1RbX8Vv5XtwQcZPt8iMib+HbBD8lLYKepq+aJMBQXc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=P1B+ooPyG4aKDj/NfGyUxCihnvtcdzyiiEzbalE4MSsHW59G6Y8IMWkEBNz36CZs7 Q9mydqWz/mPxDm6oSNH3LvLiwp5xKuz9cQJ0PSDFUHPO2xjah0gJcL/nSyv6Q6egqq 4ZCHYLv9v1ABg8oqoqtO15FoCGNlHbjdXDrEUPnLqG2qymFFVRA1Wdocl7+vTUYL16 LhLEMDRy2RmhuBFh89qpUIxLzw+EpmHiI+ODPXBPC7eJy0X/VanvqJKEgRvJUEBYrQ ElRMvyorAZG0YE8Or1vcTozqo843/shxnS+gpu37LYqHW8UqUkoyk9+l0/51rdZfsr zZlMctG0sBdmg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P6C001ES6L3CD40@st13p35im-asmtp001.me.com>; Thu, 29 Mar 2018 05:15:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-29_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1803290059 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Boot failure: panic: No heap setup From: Toomas Soome In-reply-to: Date: Thu, 29 Mar 2018 08:15:02 +0300 Cc: Warner Losh , Kyle Evans , FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 06:15:43 -0000 > On 29 Mar 2018, at 01:06, Stefan Esser wrote: >=20 > Am 28.03.18 um 22:28 schrieb Warner Losh: >>> Hmmm, the code references point into the boot loader code - I had >>> expected that there is a problem in the kernel, not the boot loader. >>>=20 >>>> [1] >>>> = https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=3Dmarkup#l56 >> = >>>=20 >>>=20 >>> Seems that setbase has either not been called or has been called = with >>> base=3D0. >>=20 >> Right, which is odd... >>=20 >>>> [2] >>>> = https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=3Dm= arkup#l688 >> = >>>=20 >>>=20 >>> I had thought, that the zfs boot code has been initialized before = the >>> menu is displayed? >>=20 >> Right, all of this should be done looooong before we get to the >> interpreter. Can you break into the loader prompt and try the = `heap` >> command, see what that outputs? CC'ing imp@ because he actually = knows >> things. >>=20 >> Totally weird. I'd add a printf to the sethead() function to display = its args >> and see if you get this panic before/after that printf... >=20 > I'm currently using a Forth-enabled boot loader again, since this is a > "production" machine (my home server, which also receives and keeps = all > my work email, for example). >=20 > I'll build a clean world with the LUA loader and test it on one of the > next days. Tests will include the "heap" loader command and I'll add = the > printf (though, if sbrk() has really not been called, I guess that = will > not go too well ...). >=20 > Is it possible, that the setheap function is called a second time, = just > before jumping into the kernel? (In that case adding the printf might > crash the loader in the first setheap call ...) >=20 > Since the loader menu (and escaping from the menu) works, there must = be > a valid heap, at that time. >=20 indeed. and assuming the message really is from loader, it means, there = must be memory corruption - if so, you can check which variables are = located close to heap related ones=E2=80=A6 Also, since you have the = working menu, it has to be related to actual loading. Since the loading = itself has been working so far, it should be related to lua specific = bits which are preparing towards to call load functions. rgds, toomas From owner-freebsd-current@freebsd.org Fri Mar 30 15:03:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9017EF73C06 for ; Fri, 30 Mar 2018 15:03:37 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C1686C346; Fri, 30 Mar 2018 15:03:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137]) by mailout02.t-online.de (Postfix) with SMTP id 40DED41B02AD; Fri, 30 Mar 2018 17:03:29 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (G5+YDOZTQhCZC5O+IkOIoIHiv2ZnFh2VIDS-AsOpLQneuGXTFhw4QY2oCdDY80hQlW@[84.154.109.148]) by fwd37.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f1vYm-4eIP4q0; Fri, 30 Mar 2018 17:03:20 +0200 Subject: Re: Boot failure: panic: No heap setup References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== To: tsoome@me.com Cc: "M. Warner Losh" , Kyle Evans , FreeBSD Current Message-ID: <838e40f6-2f05-9251-e5a9-13d52ba510b7@freebsd.org> Date: Fri, 30 Mar 2018 17:03:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ID: G5+YDOZTQhCZC5O+IkOIoIHiv2ZnFh2VIDS-AsOpLQneuGXTFhw4QY2oCdDY80hQlW X-TOI-MSGID: 2148957a-98b0-49a4-9182-b22381955f51 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 15:03:37 -0000 Am 29.03.18 um 07:15 schrieb Toomas Soome: > > >> On 29 Mar 2018, at 01:06, Stefan Esser wrote: >> >> Am 28.03.18 um 22:28 schrieb Warner Losh: >>>> Hmmm, the code references point into the boot loader code - I had >>>> expected that there is a problem in the kernel, not the boot loader. >>>> >>>>> [1] >>>>> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 >>> >>>> >>>> >>>> Seems that setbase has either not been called or has been called with >>>> base=0. >>> >>> Right, which is odd... >>> >>>>> [2] >>>>> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 >>> >>>> >>>> >>>> I had thought, that the zfs boot code has been initialized before the >>>> menu is displayed? >>> >>> Right, all of this should be done looooong before we get to the >>> interpreter. Can you break into the loader prompt and try the `heap` >>> command, see what that outputs? CC'ing imp@ because he actually knows >>> things. >>> >>> Totally weird. I'd add a printf to the sethead() function to display its args >>> and see if you get this panic before/after that printf... >> >> I'm currently using a Forth-enabled boot loader again, since this is a >> "production" machine (my home server, which also receives and keeps all >> my work email, for example). >> >> I'll build a clean world with the LUA loader and test it on one of the >> next days. Tests will include the "heap" loader command and I'll add the >> printf (though, if sbrk() has really not been called, I guess that will >> not go too well ...). >> >> Is it possible, that the setheap function is called a second time, just >> before jumping into the kernel? (In that case adding the printf might >> crash the loader in the first setheap call ...) >> >> Since the loader menu (and escaping from the menu) works, there must be >> a valid heap, at that time. >> > > indeed. and assuming the message really is from loader, it means, there must > be memory corruption - if so, you can check which variables are located > close to heap related ones Also, since you have the working menu, it has to > be related to actual loading. Since the loading itself has been working so > far, it should be related to lua specific bits which are preparing towards > to call load functions. Ok, some more data points: 1) A printf in setheap reported plausible values during start-up of zfsboot. The menu appeared and wiped away the values so fast that I could not take a photo or write them down. 2) I have rebuilt world and kernel based on r331763. Booting resulted in the same panic as reported before. There was no debug output from the patched setheap call before the panic (which indicates that it was not called a second time). 3) In order to get my system to boot, I interrupted loading of zfsloader and forced loading of the previous version (from a world build with Forth in the loader). Booting succeeded with the latest kernel ... It looks as if sbrk() was called in zfsloader before setheap() has been used to initialize the heap parameters, if lua is enabled instead if Forth. See stand/i386/loader/main.c:124 for the location of the setheap call in the loader. This is obviously hard to debug, though, since printf cannot be called at that point. A pure write(2) should be possible without heap, but since the console has not been initialized at the point of the setheap invocation, there is no working output device, AFAIK. I do not see, how any sbrk() call could occur before setheap is called. And there does not appear to be any other setheap function (or macro) in the tree, that could overload the one defined in stand/libsa/sbrk.c ... I have no idea how to proceed from here ... But now I'm sure it is a problem in zfsloader (or loader in general?). Hmmm: How is the panic message printed by sbrk() without a initialized heap? The definition of panic in stand/libsa/panic.c relies on a working printf! I should be able to use printf in the same way as panic does, but I did not succeed when I tried to use it early in zfsloader ... Regards, STefan From owner-freebsd-current@freebsd.org Fri Mar 30 18:10:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 277CBF52D09 for ; Fri, 30 Mar 2018 18:10:51 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C208E73A63; Fri, 30 Mar 2018 18:10:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P6F00E000UJVQ00@st13p35im-asmtp001.me.com>; Fri, 30 Mar 2018 18:10:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1522433436; bh=DgL0GbxtjuYdpubgXazuJq+NTw+kKc4dcMCgIrfLxds=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=kiEP0p+LOu46Chi4A4mH9Yu6xKxEciBHg9TZ9B2dwr3QlUZvtWeMCNSotie7S6a/m 3fa0+XEul+lGFJRShOGw3iQWbtrm3vPgGu2uht2Huxj8g5KGjfMAhicFUqeWaiiOTE gCDrTVb/PMF4jX8rWP/up6H/7z5J7DG59WHrfoPySrGlrYOmBhLaycdcO+Fbb6ZN8N mebZBWBUTDjJ6a5a7VjKDImLEk6aERWafs2qhwdgk1yWjAoL6hDtrVH6mDnqyGmRw5 wXAHE3rFxy7fgvGuBrohU0CYrPabmwLeP1/bMm1D6X/p4l896b4mjTLbb22Ksx1Iil UCQ59acrE5TMw== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P6F0056F15JB130@st13p35im-asmtp001.me.com>; Fri, 30 Mar 2018 18:10:35 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-30_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1803300185 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Boot failure: panic: No heap setup Date: Fri, 30 Mar 2018 21:10:31 +0300 In-reply-to: <838e40f6-2f05-9251-e5a9-13d52ba510b7@freebsd.org> Cc: "M. Warner Losh" , Kyle Evans , FreeBSD Current To: Stefan Esser References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> <838e40f6-2f05-9251-e5a9-13d52ba510b7@freebsd.org> X-Mailer: Apple Mail (2.3445.6.18) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 18:10:51 -0000 > On 30 Mar 2018, at 18:03, Stefan Esser wrote: >=20 > Am 29.03.18 um 07:15 schrieb Toomas Soome: >>=20 >>=20 >>> On 29 Mar 2018, at 01:06, Stefan Esser wrote: >>>=20 >>> Am 28.03.18 um 22:28 schrieb Warner Losh: >>>>> Hmmm, the code references point into the boot loader code - I had >>>>> expected that there is a problem in the kernel, not the boot = loader. >>>>>=20 >>>>>> [1] >>>>>> = https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=3Dmarkup#l56 >>>> = >>>>>=20 >>>>>=20 >>>>> Seems that setbase has either not been called or has been called = with >>>>> base=3D0. >>>>=20 >>>> Right, which is odd... >>>>=20 >>>>>> [2] >>>>>> = https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=3Dm= arkup#l688 >>>> = >>>>>=20 >>>>>=20 >>>>> I had thought, that the zfs boot code has been initialized before = the >>>>> menu is displayed? >>>>=20 >>>> Right, all of this should be done looooong before we get to the >>>> interpreter. Can you break into the loader prompt and try the = `heap` >>>> command, see what that outputs? CC'ing imp@ because he actually = knows >>>> things. >>>>=20 >>>> Totally weird. I'd add a printf to the sethead() function to = display its args >>>> and see if you get this panic before/after that printf... >>>=20 >>> I'm currently using a Forth-enabled boot loader again, since this is = a >>> "production" machine (my home server, which also receives and keeps = all >>> my work email, for example). >>>=20 >>> I'll build a clean world with the LUA loader and test it on one of = the >>> next days. Tests will include the "heap" loader command and I'll add = the >>> printf (though, if sbrk() has really not been called, I guess that = will >>> not go too well ...). >>>=20 >>> Is it possible, that the setheap function is called a second time, = just >>> before jumping into the kernel? (In that case adding the printf = might >>> crash the loader in the first setheap call ...) >>>=20 >>> Since the loader menu (and escaping from the menu) works, there must = be >>> a valid heap, at that time. >>>=20 >>=20 >> indeed. and assuming the message really is from loader, it means, = there must >> be memory corruption - if so, you can check which variables are = located >> close to heap related ones=E2=80=A6 Also, since you have the working = menu, it has to >> be related to actual loading. Since the loading itself has been = working so >> far, it should be related to lua specific bits which are preparing = towards >> to call load functions. >=20 > Ok, some more data points: >=20 > 1) A printf in setheap reported plausible values during start-up of = zfsboot. > The menu appeared and wiped away the values so fast that I could not = take > a photo or write them down. >=20 if you got menu and stuff, it means that at that point the heap was all = OK. just after setheap() the bcache_init() is called and that too will = allocate memory. what you can do is to esc out from menu to OK prompt and check the = output of heap and biosmem commands=E2=80=A6=20 > 2) I have rebuilt world and kernel based on r331763. Booting resulted = in the > same panic as reported before. There was no debug output from the = patched > setheap call before the panic (which indicates that it was not = called a > second time). >=20 > 3) In order to get my system to boot, I interrupted loading of = zfsloader and > forced loading of the previous version (from a world build with = Forth in > the loader). Booting succeeded with the latest kernel ... >=20 > It looks as if sbrk() was called in zfsloader before setheap() has = been used > to initialize the heap parameters, if lua is enabled instead if Forth. = See > stand/i386/loader/main.c:124 for the location of the setheap call in = the > loader. this can only happen when something is called before main=E2=80=A6=20 >=20 > This is obviously hard to debug, though, since printf cannot be called = at that > point. A pure write(2) should be possible without heap, but since the = console > has not been initialized at the point of the setheap invocation, there = is no > working output device, AFAIK. >=20 > I do not see, how any sbrk() call could occur before setheap is = called. And > there does not appear to be any other setheap function (or macro) in = the > tree, that could overload the one defined in stand/libsa/sbrk.c ... >=20 > I have no idea how to proceed from here ... >=20 > But now I'm sure it is a problem in zfsloader (or loader in general?). >=20 > Hmmm: How is the panic message printed by sbrk() without a initialized = heap? > The definition of panic in stand/libsa/panic.c relies on a working = printf! >=20 > I should be able to use printf in the same way as panic does, but I = did > not succeed when I tried to use it early in zfsloader ... >=20 > Regards, STefan rgds, toomas From owner-freebsd-current@freebsd.org Fri Mar 30 18:53:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FE2EF57220 for ; Fri, 30 Mar 2018 18:53:57 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 E72E878152 for ; Fri, 30 Mar 2018 18:53:56 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 18E9D5A9F18; Fri, 30 Mar 2018 18:53:50 +0000 (UTC) Date: Fri, 30 Mar 2018 18:53:50 +0000 From: Brooks Davis To: freebsd-current@freebsd.org Subject: 32-bit compat ifconfig support Message-ID: <20180330185349.GM88362@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TA4f0niHM6tHt3xR" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 18:53:57 -0000 --TA4f0niHM6tHt3xR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With this change, 32-bit ifconfig is expected to work. I've done most of my testing on a different compat ABI in CheriBSD, but am happy to receive reports one way or another. If you find edge cases, please file bug reports and I'll take a look at them. -- Brooks ----- Forwarded message from Brooks Davis ----- Date: Fri, 30 Mar 2018 18:50:13 +0000 (UTC) =46rom: Brooks Davis To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r331797 - in head/sys: dev/an dev/ath dev/cxgbe dev/if_ndis dev/iwi dev/ixl dev/mlx4/mlx4_en dev/mlx5/mlx5_en dev/mwl dev/nxge dev/oce dev/qlnx/qlnxe dev/sbni dev/sfxge dev/vxge net net... Author: brooks Date: Fri Mar 30 18:50:13 2018 New Revision: 331797 URL: https://svnweb.freebsd.org/changeset/base/331797 Log: Use an accessor function to access ifr_data. =20 This fixes 32-bit compat (no ioctl command defintions are required as struct ifreq is the same size). This is believed to be sufficent to fully support ifconfig on 32-bit systems. =20 Reviewed by: kib Obtained from: CheriBSD MFC after: 1 week Relnotes: yes Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14900 Modified: head/sys/dev/an/if_an.c head/sys/dev/ath/if_ath_ioctl.c head/sys/dev/cxgbe/t4_main.c head/sys/dev/if_ndis/if_ndis.c head/sys/dev/iwi/if_iwi.c head/sys/dev/ixl/ixl_pf_main.c head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c head/sys/dev/mwl/if_mwl.c head/sys/dev/nxge/if_nxge.c head/sys/dev/oce/oce_if.c head/sys/dev/qlnx/qlnxe/qlnx_os.c head/sys/dev/sbni/if_sbni.c head/sys/dev/sfxge/sfxge.c head/sys/dev/vxge/vxge.c head/sys/net/if.c head/sys/net/if.h head/sys/net/if_gif.c head/sys/net/if_gre.c head/sys/net/if_ipsec.c head/sys/net/if_spppsubr.c head/sys/net/if_var.h head/sys/net/if_vlan.c head/sys/net/iflib.c head/sys/net80211/ieee80211_ioctl.c head/sys/netinet/ip_carp.c head/sys/netpfil/pf/if_pfsync.c head/sys/security/mac/mac_net.c Modified: head/sys/dev/an/if_an.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/an/if_an.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/an/if_an.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1934,7 +1934,8 @@ an_ioctl(struct ifnet *ifp, u_long command, caddr_t da error =3D 0; break; case SIOCGAIRONET: - error =3D copyin(ifr->ifr_data, &sc->areq, sizeof(sc->areq)); + error =3D copyin(ifr_data_get_ptr(ifr), &sc->areq, + sizeof(sc->areq)); if (error !=3D 0) break; AN_LOCK(sc); @@ -1963,13 +1964,15 @@ an_ioctl(struct ifnet *ifp, u_long command, caddr_t= da break; } AN_UNLOCK(sc); - error =3D copyout(&sc->areq, ifr->ifr_data, sizeof(sc->areq)); + error =3D copyout(&sc->areq, ifr_data_get_ptr(ifr), + sizeof(sc->areq)); break; case SIOCSAIRONET: if ((error =3D priv_check(td, PRIV_DRIVER))) goto out; AN_LOCK(sc); - error =3D copyin(ifr->ifr_data, &sc->areq, sizeof(sc->areq)); + error =3D copyin(ifr_data_get_ptr(ifr), &sc->areq, + sizeof(sc->areq)); if (error !=3D 0) break; an_setdef(sc, &sc->areq); @@ -1978,7 +1981,8 @@ an_ioctl(struct ifnet *ifp, u_long command, caddr_t da case SIOCGPRIVATE_0: /* used by Cisco client utility */ if ((error =3D priv_check(td, PRIV_DRIVER))) goto out; - error =3D copyin(ifr->ifr_data, &l_ioctl, sizeof(l_ioctl)); + error =3D copyin(ifr_data_get_ptr(ifr), &l_ioctl, + sizeof(l_ioctl)); if (error) goto out; mode =3D l_ioctl.command; @@ -1996,13 +2000,15 @@ an_ioctl(struct ifnet *ifp, u_long command, caddr_t= da AN_UNLOCK(sc); if (!error) { /* copy out the updated command info */ - error =3D copyout(&l_ioctl, ifr->ifr_data, sizeof(l_ioctl)); + error =3D copyout(&l_ioctl, ifr_data_get_ptr(ifr), + sizeof(l_ioctl)); } break; case SIOCGPRIVATE_1: /* used by Cisco client utility */ if ((error =3D priv_check(td, PRIV_DRIVER))) goto out; - error =3D copyin(ifr->ifr_data, &l_ioctl, sizeof(l_ioctl)); + error =3D copyin(ifr_data_get_ptr(ifr), &l_ioctl, + sizeof(l_ioctl)); if (error) goto out; l_ioctl.command =3D 0; Modified: head/sys/dev/ath/if_ath_ioctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/ath/if_ath_ioctl.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/ath/if_ath_ioctl.c Fri Mar 30 18:50:13 2018 (r331797) @@ -267,12 +267,12 @@ ath_ioctl(struct ieee80211com *ic, u_long cmd, void *d rt->info[sc->sc_txrix].dot11Rate &~ IEEE80211_RATE_BASIC; if (rt->info[sc->sc_txrix].phy & IEEE80211_T_HT) sc->sc_stats.ast_tx_rate |=3D IEEE80211_RATE_MCS; - return copyout(&sc->sc_stats, - ifr->ifr_data, sizeof (sc->sc_stats)); + return copyout(&sc->sc_stats, ifr_data_get_ptr(ifr), + sizeof (sc->sc_stats)); } case SIOCGATHAGSTATS: - return copyout(&sc->sc_aggr_stats, - ifr->ifr_data, sizeof (sc->sc_aggr_stats)); + return copyout(&sc->sc_aggr_stats, ifr_data_get_ptr(ifr), + sizeof (sc->sc_aggr_stats)); case SIOCZATHSTATS: { int error; =20 Modified: head/sys/dev/cxgbe/t4_main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/cxgbe/t4_main.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/cxgbe/t4_main.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1800,7 +1800,7 @@ fail: case SIOCGI2C: { struct ifi2creq i2c; =20 - rc =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + rc =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (rc !=3D 0) break; if (i2c.dev_addr !=3D 0xA0 && i2c.dev_addr !=3D 0xA2) { @@ -1818,7 +1818,7 @@ fail: i2c.offset, i2c.len, &i2c.data[0]); end_synchronized_op(sc, 0); if (rc =3D=3D 0) - rc =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + rc =3D copyout(&i2c, ifr_data_get_ptr(ifr), sizeof(i2c)); break; } =20 Modified: head/sys/dev/if_ndis/if_ndis.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/if_ndis/if_ndis.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/if_ndis/if_ndis.c Fri Mar 30 18:50:13 2018 (r331797) @@ -2975,11 +2975,12 @@ ndis_80211ioctl(struct ieee80211com *ic, u_long cmd= , v switch (cmd) { case SIOCGDRVSPEC: case SIOCSDRVSPEC: - error =3D copyin(ifr->ifr_data, &oid, sizeof(oid)); + error =3D copyin(ifr_data_get_ptr(ifr), &oid, sizeof(oid)); if (error) break; oidbuf =3D malloc(oid.len, M_TEMP, M_WAITOK | M_ZERO); - error =3D copyin(ifr->ifr_data + sizeof(oid), oidbuf, oid.len); + error =3D copyin((caddr_t)ifr_data_get_ptr(ifr) + sizeof(oid), + oidbuf, oid.len); } =20 if (error) { @@ -3001,7 +3002,7 @@ ndis_80211ioctl(struct ieee80211com *ic, u_long cmd, v NDIS_UNLOCK(sc); break; } - error =3D copyin(ifr->ifr_data, &evt, sizeof(evt)); + error =3D copyin(ifr_data_get_ptr(ifr), &evt, sizeof(evt)); if (error) { NDIS_UNLOCK(sc); break; @@ -3012,14 +3013,15 @@ ndis_80211ioctl(struct ieee80211com *ic, u_long cmd= , v break; } error =3D copyout(&sc->ndis_evt[sc->ndis_evtcidx], - ifr->ifr_data, sizeof(uint32_t) * 2); + ifr_data_get_ptr(ifr), sizeof(uint32_t) * 2); if (error) { NDIS_UNLOCK(sc); break; } if (sc->ndis_evt[sc->ndis_evtcidx].ne_len) { error =3D copyout(sc->ndis_evt[sc->ndis_evtcidx].ne_buf, - ifr->ifr_data + (sizeof(uint32_t) * 2), + (caddr_t)ifr_data_get_ptr(ifr) + + (sizeof(uint32_t) * 2), sc->ndis_evt[sc->ndis_evtcidx].ne_len); if (error) { NDIS_UNLOCK(sc); @@ -3041,10 +3043,11 @@ ndis_80211ioctl(struct ieee80211com *ic, u_long cmd= , v switch (cmd) { case SIOCGDRVSPEC: case SIOCSDRVSPEC: - error =3D copyout(&oid, ifr->ifr_data, sizeof(oid)); + error =3D copyout(&oid, ifr_data_get_ptr(ifr), sizeof(oid)); if (error) break; - error =3D copyout(oidbuf, ifr->ifr_data + sizeof(oid), oid.len); + error =3D copyout(oidbuf, + (caddr_t)ifr_data_get_ptr(ifr) + sizeof(oid), oid.len); } =20 free(oidbuf, M_TEMP); Modified: head/sys/dev/iwi/if_iwi.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/iwi/if_iwi.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/iwi/if_iwi.c Fri Mar 30 18:50:13 2018 (r331797) @@ -2059,7 +2059,7 @@ iwi_ioctl(struct ieee80211com *ic, u_long cmd, void *d switch (cmd) { case SIOCGIWISTATS: /* XXX validate permissions/memory/etc? */ - error =3D copyout(&sc->sc_linkqual, ifr->ifr_data, + error =3D copyout(&sc->sc_linkqual, ifr_data_get_ptr(ifr), sizeof(struct iwi_notif_link_quality)); break; case SIOCZIWISTATS: Modified: head/sys/dev/ixl/ixl_pf_main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/ixl/ixl_pf_main.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/ixl/ixl_pf_main.c Fri Mar 30 18:50:13 2018 (r331797) @@ -5174,7 +5174,7 @@ ixl_ioctl(struct ifnet * ifp, u_long command, caddr_t= =20 if (!pf->has_i2c) return (ENOTTY); =20 - error =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + error =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (error !=3D 0) break; if (i2c.dev_addr !=3D 0xA0 && i2c.dev_addr !=3D 0xA2) { @@ -5191,7 +5191,7 @@ ixl_ioctl(struct ifnet * ifp, u_long command, caddr_t= =20 i2c.dev_addr, &i2c.data[i])) return (EIO); =20 - error =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + error =3D copyout(&i2c, ifr_data_get_ptr(ifr), sizeof(i2c)); break; } #endif Modified: head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c Fri Mar 30 18:49:52 2018 (r3= 31796) +++ head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c Fri Mar 30 18:50:13 2018 (r3= 31797) @@ -2058,7 +2058,7 @@ out: case SIOCGI2C: { struct ifi2creq i2c; =20 - error =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + error =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (error) break; if (i2c.len > sizeof(i2c.data)) { @@ -2075,7 +2075,7 @@ out: error =3D -error; break; } - error =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + error =3D copyout(&i2c, ifr_data_get_ptr(ifr), sizeof(i2c)); break; } #endif Modified: head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c Fri Mar 30 18:49:52 2018 (r331= 796) +++ head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c Fri Mar 30 18:50:13 2018 (r331= 797) @@ -2884,7 +2884,7 @@ out: * Copy from the user-space address ifr_data to the * kernel-space address i2c */ - error =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + error =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (error) break; =20 @@ -2948,7 +2948,7 @@ out: goto err_i2c; } =20 - error =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + error =3D copyout(&i2c, ifr_data_get_ptr(ifr), sizeof(i2c)); err_i2c: PRIV_UNLOCK(priv); break; Modified: head/sys/dev/mwl/if_mwl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/mwl/if_mwl.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/mwl/if_mwl.c Fri Mar 30 18:50:13 2018 (r331797) @@ -4750,8 +4750,8 @@ mwl_ioctl(struct ieee80211com *ic, u_long cmd, void *d * statistics. The alternative is to copy the data * to a local structure. */ - return (copyout(&sc->sc_stats, - ifr->ifr_data, sizeof (sc->sc_stats))); + return (copyout(&sc->sc_stats, ifr_data_get_ptr(ifr), + sizeof (sc->sc_stats))); #ifdef MWL_DIAGAPI case SIOCGMVDIAG: /* XXX check privs */ Modified: head/sys/dev/nxge/if_nxge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/nxge/if_nxge.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/nxge/if_nxge.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1368,7 +1368,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre void *info =3D NULL; int retValue =3D EINVAL; =20 - cmd =3D fubyte(ifreqp->ifr_data); + cmd =3D fubyte(ifr_data_get_ptr(ifreqp)); if (cmd =3D=3D -1) return (EFAULT); =20 @@ -1379,7 +1379,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre (xge_hal_stats_hw_info_t **)&info); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(info, ifreqp->ifr_data, + if(copyout(info, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_stats_hw_info_t)) =3D=3D 0) retValue =3D 0; } @@ -1397,7 +1397,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre sizeof(xge_hal_pci_config_t)); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(info, ifreqp->ifr_data, + if(copyout(info, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_pci_config_t)) =3D=3D 0) retValue =3D 0; } @@ -1417,7 +1417,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre sizeof(xge_hal_stats_device_info_t)); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(info, ifreqp->ifr_data, + if(copyout(info, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_stats_device_info_t)) =3D=3D 0) retValue =3D 0; } @@ -1438,7 +1438,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre sizeof(xge_hal_stats_sw_err_t)); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(info, ifreqp->ifr_data, + if(copyout(info, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_stats_sw_err_t)) =3D=3D 0) retValue =3D 0; } @@ -1451,7 +1451,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre break; =20 case XGE_QUERY_DRIVERSTATS: - if(copyout(&lldev->driver_stats, ifreqp->ifr_data, + if(copyout(&lldev->driver_stats, ifr_data_get_ptr(ifreqp), sizeof(xge_driver_stats_t)) =3D=3D 0) { retValue =3D 0; } @@ -1465,7 +1465,8 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre info =3D xge_os_malloc(NULL, XGE_BUFFER_SIZE); if(info !=3D NULL) { strcpy(info, XGE_DRIVER_VERSION); - if(copyout(info, ifreqp->ifr_data, XGE_BUFFER_SIZE) =3D=3D 0) + if(copyout(info, ifr_data_get_ptr(ifreqp), + XGE_BUFFER_SIZE) =3D=3D 0) retValue =3D 0; xge_os_free(NULL, info, XGE_BUFFER_SIZE); } @@ -1479,7 +1480,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre sizeof(xge_hal_device_config_t)); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(info, ifreqp->ifr_data, + if(copyout(info, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_device_config_t)) =3D=3D 0) retValue =3D 0; } @@ -1492,7 +1493,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre break; =20 case XGE_QUERY_BUFFER_MODE: - if(copyout(&lldev->buffer_mode, ifreqp->ifr_data, + if(copyout(&lldev->buffer_mode, ifr_data_get_ptr(ifreqp), sizeof(int)) =3D=3D 0) retValue =3D 0; break; @@ -1501,7 +1502,7 @@ xge_ioctl_stats(xge_lldev_t *lldev, struct ifreq *ifre case XGE_SET_BUFFER_MODE_2: case XGE_SET_BUFFER_MODE_5: mode =3D (cmd =3D=3D XGE_SET_BUFFER_MODE_1) ? 'Y':'N'; - if(copyout(&mode, ifreqp->ifr_data, sizeof(mode)) =3D=3D 0) + if(copyout(&mode, ifr_data_get_ptr(ifreqp), sizeof(mode)) =3D=3D = 0) retValue =3D 0; break; default: @@ -1529,7 +1530,7 @@ xge_ioctl_registers(xge_lldev_t *lldev, struct ifreq * int error; u64 val64 =3D 0; =20 - error =3D copyin(ifreqp->ifr_data, &tmpdata, sizeof(tmpdata)); + error =3D copyin(ifr_data_get_ptr(ifreqp), &tmpdata, sizeof(tmpdata)); if (error !=3D 0) return (error); data =3D &tmpdata; @@ -1542,7 +1543,8 @@ xge_ioctl_registers(xge_lldev_t *lldev, struct ifreq * &data->value); mtx_unlock(&lldev->mtx_drv); if(status =3D=3D XGE_HAL_OK) { - if(copyout(data, ifreqp->ifr_data, sizeof(xge_register_t)) =3D=3D= 0) + if(copyout(data, ifr_data_get_ptr(ifreqp), + sizeof(xge_register_t)) =3D=3D 0) retValue =3D 0; } } @@ -1587,7 +1589,7 @@ xge_ioctl_registers(xge_lldev_t *lldev, struct ifreq * mtx_unlock(&lldev->mtx_drv); =20 if(retValue =3D=3D 0) { - if(copyout(data, ifreqp->ifr_data, + if(copyout(data, ifr_data_get_ptr(ifreqp), sizeof(xge_hal_pci_bar0_t)) !=3D 0) { xge_trace(XGE_ERR, "Copyout of register values failed"); retValue =3D EINVAL; Modified: head/sys/dev/oce/oce_if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/oce/oce_if.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/oce/oce_if.c Fri Mar 30 18:50:13 2018 (r331797) @@ -2276,7 +2276,7 @@ oce_handle_passthrough(struct ifnet *ifp, caddr_t data struct ifreq *ifr =3D (struct ifreq *)data; int rc =3D ENXIO; char cookie[32] =3D {0}; - void *priv_data =3D (void *)ifr->ifr_data; + void *priv_data =3D ifr_data_get_ptr(ifr); void *ioctl_ptr; uint32_t req_size; struct mbx_hdr req; Modified: head/sys/dev/qlnx/qlnxe/qlnx_os.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/qlnx/qlnxe/qlnx_os.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/qlnx/qlnxe/qlnx_os.c Fri Mar 30 18:50:13 2018 (r331797) @@ -2464,7 +2464,7 @@ qlnx_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data struct ecore_hwfn *p_hwfn =3D &ha->cdev.hwfns[0]; struct ecore_ptt *p_ptt; =20 - ret =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + ret =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); =20 if (ret) break; @@ -2494,7 +2494,7 @@ qlnx_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data break; } =20 - ret =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + ret =3D copyout(&i2c, ifr_data_get_ptr(ifr), sizeof(i2c)); =20 QL_DPRINT8(ha, "SIOCGI2C copyout ret =3D %d \ len =3D %d addr =3D 0x%02x offset =3D 0x%04x \ Modified: head/sys/dev/sbni/if_sbni.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/sbni/if_sbni.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/sbni/if_sbni.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1153,7 +1153,7 @@ sbni_ioctl(struct ifnet *ifp, u_long command, caddr_t= =20 SBNI_LOCK(sc); bcopy(&sc->in_stats, in_stats, sizeof(struct sbni_in_stats)); SBNI_UNLOCK(sc); - error =3D copyout(ifr->ifr_data, in_stats, + error =3D copyout(ifr_data_get_ptr(ifr), in_stats, sizeof(struct sbni_in_stats)); free(in_stats, M_DEVBUF); break; Modified: head/sys/dev/sfxge/sfxge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/sfxge/sfxge.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/sfxge/sfxge.c Fri Mar 30 18:50:13 2018 (r331797) @@ -529,7 +529,7 @@ sfxge_if_ioctl(struct ifnet *ifp, unsigned long comman { struct ifi2creq i2c; =20 - error =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + error =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (error !=3D 0) break; =20 @@ -544,7 +544,8 @@ sfxge_if_ioctl(struct ifnet *ifp, unsigned long comman &i2c.data[0]); SFXGE_ADAPTER_UNLOCK(sc); if (error =3D=3D 0) - error =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + error =3D copyout(&i2c, ifr_data_get_ptr(ifr), + sizeof(i2c)); break; } #endif @@ -552,12 +553,13 @@ sfxge_if_ioctl(struct ifnet *ifp, unsigned long comman error =3D priv_check(curthread, PRIV_DRIVER); if (error !=3D 0) break; - error =3D copyin(ifr->ifr_data, &ioc, sizeof(ioc)); + error =3D copyin(ifr_data_get_ptr(ifr), &ioc, sizeof(ioc)); if (error !=3D 0) return (error); error =3D sfxge_private_ioctl(sc, &ioc); if (error =3D=3D 0) { - error =3D copyout(&ioc, ifr->ifr_data, sizeof(ioc)); + error =3D copyout(&ioc, ifr_data_get_ptr(ifr), + sizeof(ioc)); } break; default: Modified: head/sys/dev/vxge/vxge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/vxge/vxge.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/dev/vxge/vxge.c Fri Mar 30 18:50:13 2018 (r331797) @@ -3710,8 +3710,8 @@ vxge_ioctl_regs(vxge_dev_t *vdev, struct ifreq *ifr) u32 offset, reqd_size =3D 0; int i, err =3D EINVAL; =20 - char *command =3D (char *) ifr->ifr_data; - void *reg_info =3D (void *) ifr->ifr_data; + char *command =3D ifr_data_get_ptr(ifr); + void *reg_info =3D ifr_data_get_ptr(ifr); =20 vxge_vpath_t *vpath; vxge_hal_status_e status =3D VXGE_HAL_OK; @@ -3818,7 +3818,7 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) vxge_drv_stats_t *drv_stat; =20 char *buffer =3D NULL; - char *command =3D (char *) ifr->ifr_data; + char *command =3D ifr_data_get_ptr(ifr); vxge_hal_status_e status =3D VXGE_HAL_OK; =20 switch (*command) { @@ -3829,7 +3829,8 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) status =3D vxge_hal_aux_pci_config_read(vdev->devh, bufsize, buffer, &retsize); if (status =3D=3D VXGE_HAL_OK) - err =3D copyout(buffer, ifr->ifr_data, retsize); + err =3D copyout(buffer, ifr_data_get_ptr(ifr), + retsize); else device_printf(vdev->ndev, "failed pciconfig statistics query\n"); @@ -3848,7 +3849,8 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) status =3D vxge_hal_aux_stats_mrpcim_read(vdev->devh, bufsize, buffer, &retsize); if (status =3D=3D VXGE_HAL_OK) - err =3D copyout(buffer, ifr->ifr_data, retsize); + err =3D copyout(buffer, ifr_data_get_ptr(ifr), + retsize); else device_printf(vdev->ndev, "failed mrpcim statistics query\n"); @@ -3864,7 +3866,8 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) status =3D vxge_hal_aux_stats_device_read(vdev->devh, bufsize, buffer, &retsize); if (status =3D=3D VXGE_HAL_OK) - err =3D copyout(buffer, ifr->ifr_data, retsize); + err =3D copyout(buffer, ifr_data_get_ptr(ifr), + retsize); else device_printf(vdev->ndev, "failed device statistics query\n"); @@ -3888,7 +3891,7 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) ((vxge_device_hw_info_t *) buffer)->port_failure =3D vdev->port_failure; =20 - err =3D copyout(buffer, ifr->ifr_data, bufsize); + err =3D copyout(buffer, ifr_data_get_ptr(ifr), bufsize); if (err !=3D 0) device_printf(vdev->ndev, "failed device hardware info query\n"); @@ -3915,7 +3918,7 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) sizeof(vxge_drv_stats_t)); } =20 - err =3D copyout(drv_stat, ifr->ifr_data, bufsize); + err =3D copyout(drv_stat, ifr_data_get_ptr(ifr), bufsize); if (err !=3D 0) device_printf(vdev->ndev, "failed driver statistics query\n"); @@ -3925,7 +3928,7 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) break; =20 case VXGE_GET_BANDWIDTH: - bw_info =3D (vxge_bw_info_t *) ifr->ifr_data; + bw_info =3D ifr_data_get_ptr(ifr); =20 if ((vdev->config.hw_info.func_id !=3D 0) && (vdev->hw_fw_version < VXGE_FW_VERSION(1, 8, 0))) @@ -3938,7 +3941,8 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) if (status !=3D VXGE_HAL_OK) break; =20 - err =3D copyout(bw_info, ifr->ifr_data, sizeof(vxge_bw_info_t)); + err =3D copyout(bw_info, ifr_data_get_ptr(ifr), + sizeof(vxge_bw_info_t)); break; =20 case VXGE_SET_BANDWIDTH: @@ -3949,7 +3953,7 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *ifr) case VXGE_SET_PORT_MODE: if (vdev->is_privilaged) { if (vdev->config.hw_info.ports =3D=3D VXGE_DUAL_PORT_MODE) { - port_info =3D (vxge_port_info_t *) ifr->ifr_data; + port_info =3D ifr_data_get_ptr(ifr); vdev->config.port_mode =3D port_info->port_mode; err =3D vxge_port_mode_update(vdev); if (err !=3D ENXIO) @@ -3966,10 +3970,11 @@ vxge_ioctl_stats(vxge_dev_t *vdev, struct ifreq *if= r) case VXGE_GET_PORT_MODE: if (vdev->is_privilaged) { if (vdev->config.hw_info.ports =3D=3D VXGE_DUAL_PORT_MODE) { - port_info =3D (vxge_port_info_t *) ifr->ifr_data; + port_info =3D ifr_data_get_ptr(ifr); err =3D vxge_port_mode_get(vdev, port_info); if (err =3D=3D VXGE_HAL_OK) { - err =3D copyout(port_info, ifr->ifr_data, + err =3D copyout(port_info, + ifr_data_get_ptr(ifr), sizeof(vxge_port_info_t)); } } @@ -4005,7 +4010,7 @@ vxge_bw_priority_set(vxge_dev_t *vdev, struct ifreq *i u32 func_id; vxge_bw_info_t *bw_info; =20 - bw_info =3D (vxge_bw_info_t *) ifr->ifr_data; + bw_info =3D ifr_data_get_ptr(ifr); func_id =3D bw_info->func_id; =20 vdev->config.bw_info[func_id].priority =3D bw_info->priority; Modified: head/sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if.c Fri Mar 30 18:50:13 2018 (r331797) @@ -2403,6 +2403,20 @@ ifr_buffer_set_length(struct thread *td, void *data,= s ifrup->ifr.ifr_ifru.ifru_buffer.length =3D len; } =20 +void * +ifr_data_get_ptr(void *ifrp) +{ + union ifreq_union *ifrup; + + ifrup =3D ifrp; +#ifdef COMPAT_FREEBSD32 + if (SV_CURPROC_FLAG(SV_ILP32)) + return ((void *)(uintptr_t) + ifrup->ifr32.ifr_ifru.ifru_data); +#endif + return (ifrup->ifr.ifr_ifru.ifru_data); +} + /* * Hardware specific interface ioctls. */ @@ -2584,7 +2598,8 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t data, error =3D priv_check(td, PRIV_NET_SETIFNAME); if (error) return (error); - error =3D copyinstr(ifr->ifr_data, new_name, IFNAMSIZ, NULL); + error =3D copyinstr(ifr_data_get_ptr(ifr), new_name, IFNAMSIZ, + NULL); if (error !=3D 0) return (error); if (new_name[0] =3D=3D '\0') @@ -2895,8 +2910,8 @@ ifioctl(struct socket *so, u_long cmd, caddr_t data, s error =3D priv_check(td, PRIV_NET_IFCREATE); if (error =3D=3D 0) error =3D if_clone_create(ifr->ifr_name, - sizeof(ifr->ifr_name), - cmd =3D=3D SIOCIFCREATE2 ? ifr->ifr_data : NULL); + sizeof(ifr->ifr_name), cmd =3D=3D SIOCIFCREATE2 ? + ifr_data_get_ptr(ifr) : NULL); CURVNET_RESTORE(); return (error); case SIOCIFDESTROY: Modified: head/sys/net/if.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if.h Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if.h Fri Mar 30 18:50:13 2018 (r331797) @@ -412,7 +412,9 @@ struct ifreq { #define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ #define ifr_phys ifr_ifru.ifru_phys /* physical wire */ #define ifr_media ifr_ifru.ifru_media /* physical media */ +#ifndef _KERNEL #define ifr_data ifr_ifru.ifru_data /* for use by interface */ +#endif #define ifr_reqcap ifr_ifru.ifru_cap[0] /* requested capabilities */ #define ifr_curcap ifr_ifru.ifru_cap[1] /* current capabilities */ #define ifr_index ifr_ifru.ifru_index /* interface index */ Modified: head/sys/net/if_gif.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_gif.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_gif.c Fri Mar 30 18:50:13 2018 (r331797) @@ -898,12 +898,14 @@ gif_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) break; case GIFGOPTS: options =3D sc->gif_options; - error =3D copyout(&options, ifr->ifr_data, sizeof(options)); + error =3D copyout(&options, ifr_data_get_ptr(ifr), + sizeof(options)); break; case GIFSOPTS: if ((error =3D priv_check(curthread, PRIV_NET_GIF)) !=3D 0) break; - error =3D copyin(ifr->ifr_data, &options, sizeof(options)); + error =3D copyin(ifr_data_get_ptr(ifr), &options, + sizeof(options)); if (error) break; if (options & ~GIF_OPTMASK) Modified: head/sys/net/if_gre.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_gre.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_gre.c Fri Mar 30 18:50:13 2018 (r331797) @@ -455,7 +455,8 @@ gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) case GRESKEY: if ((error =3D priv_check(curthread, PRIV_NET_GRE)) !=3D 0) break; - if ((error =3D copyin(ifr->ifr_data, &opt, sizeof(opt))) !=3D 0) + if ((error =3D copyin(ifr_data_get_ptr(ifr), &opt, + sizeof(opt))) !=3D 0) break; if (sc->gre_key !=3D opt) { GRE_WLOCK(sc); @@ -465,13 +466,14 @@ gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) } break; case GREGKEY: - error =3D copyout(&sc->gre_key, ifr->ifr_data, + error =3D copyout(&sc->gre_key, ifr_data_get_ptr(ifr), sizeof(sc->gre_key)); break; case GRESOPTS: if ((error =3D priv_check(curthread, PRIV_NET_GRE)) !=3D 0) break; - if ((error =3D copyin(ifr->ifr_data, &opt, sizeof(opt))) !=3D 0) + if ((error =3D copyin(ifr_data_get_ptr(ifr), &opt, + sizeof(opt))) !=3D 0) break; if (opt & ~GRE_OPTMASK) error =3D EINVAL; @@ -486,7 +488,7 @@ gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) break; =20 case GREGOPTS: - error =3D copyout(&sc->gre_options, ifr->ifr_data, + error =3D copyout(&sc->gre_options, ifr_data_get_ptr(ifr), sizeof(sc->gre_options)); break; default: Modified: head/sys/net/if_ipsec.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_ipsec.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_ipsec.c Fri Mar 30 18:50:13 2018 (r331797) @@ -688,12 +688,12 @@ ipsec_ioctl(struct ifnet *ifp, u_long cmd, caddr_t dat break; case IPSECGREQID: reqid =3D sc->reqid; - error =3D copyout(&reqid, ifr->ifr_data, sizeof(reqid)); + error =3D copyout(&reqid, ifr_data_get_ptr(ifr), sizeof(reqid)); break; case IPSECSREQID: if ((error =3D priv_check(curthread, PRIV_NET_SETIFCAP)) !=3D 0) break; - error =3D copyin(ifr->ifr_data, &reqid, sizeof(reqid)); + error =3D copyin(ifr_data_get_ptr(ifr), &reqid, sizeof(reqid)); if (error !=3D 0) break; error =3D ipsec_set_reqid(ifp, reqid); Modified: head/sys/net/if_spppsubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_spppsubr.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_spppsubr.c Fri Mar 30 18:50:13 2018 (r331797) @@ -5058,17 +5058,17 @@ sppp_params(struct sppp *sp, u_long cmd, void *data) if ((spr =3D malloc(sizeof(struct spppreq), M_TEMP, M_NOWAIT)) =3D=3D NUL= L) return (EAGAIN); /* - * ifr->ifr_data is supposed to point to a struct spppreq. + * ifr_data_get_ptr(ifr) is supposed to point to a struct spppreq. * Check the cmd word first before attempting to fetch all the * data. */ - rv =3D fueword(ifr->ifr_data, &subcmd); + rv =3D fueword(ifr_data_get_ptr(ifr), &subcmd); if (rv =3D=3D -1) { rv =3D EFAULT; goto quit; } =20 - if (copyin((caddr_t)ifr->ifr_data, spr, sizeof(struct spppreq)) !=3D 0) { + if (copyin(ifr_data_get_ptr(ifr), spr, sizeof(struct spppreq)) !=3D 0) { rv =3D EFAULT; goto quit; } @@ -5105,8 +5105,8 @@ sppp_params(struct sppp *sp, u_long cmd, void *data) * setting it. */ spr->defs.lcp.timeout =3D sp->lcp.timeout * 1000 / hz; - rv =3D copyout(spr, (caddr_t)ifr->ifr_data, - sizeof(struct spppreq)); + rv =3D copyout(spr, ifr_data_get_ptr(ifr), + sizeof(struct spppreq)); break; =20 case (u_long)SPPPIOSDEFS: Modified: head/sys/net/if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_var.h Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_var.h Fri Mar 30 18:50:13 2018 (r331797) @@ -719,6 +719,9 @@ int drbr_enqueue_drv(if_t ifp, struct buf_ring *br, st void if_hw_tsomax_common(if_t ifp, struct ifnet_hw_tsomax *); int if_hw_tsomax_update(if_t ifp, struct ifnet_hw_tsomax *); =20 +/* accessors for struct ifreq */ +void *ifr_data_get_ptr(void *ifrp); + #ifdef DEVICE_POLLING enum poll_cmd { POLL_ONLY, POLL_AND_CHECK_STATUS }; =20 Modified: head/sys/net/if_vlan.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/if_vlan.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/if_vlan.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1857,7 +1857,7 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data break; } #endif - error =3D copyin(ifr->ifr_data, &vlr, sizeof(vlr)); + error =3D copyin(ifr_data_get_ptr(ifr), &vlr, sizeof(vlr)); if (error) break; if (vlr.vlr_parent[0] =3D=3D '\0') { @@ -1888,7 +1888,7 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data vlr.vlr_tag =3D ifv->ifv_vid; } VLAN_SUNLOCK(); - error =3D copyout(&vlr, ifr->ifr_data, sizeof(vlr)); + error =3D copyout(&vlr, ifr_data_get_ptr(ifr), sizeof(vlr)); break; =09 case SIOCSIFFLAGS: Modified: head/sys/net/iflib.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net/iflib.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net/iflib.c Fri Mar 30 18:50:13 2018 (r331797) @@ -3984,7 +3984,7 @@ iflib_if_ioctl(if_t ifp, u_long command, caddr_t data) { struct ifi2creq i2c; =20 - err =3D copyin(ifr->ifr_data, &i2c, sizeof(i2c)); + err =3D copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c)); if (err !=3D 0) break; if (i2c.dev_addr !=3D 0xA0 && i2c.dev_addr !=3D 0xA2) { @@ -3997,7 +3997,8 @@ iflib_if_ioctl(if_t ifp, u_long command, caddr_t data) } =20 if ((err =3D IFDI_I2C_REQ(ctx, &i2c)) =3D=3D 0) - err =3D copyout(&i2c, ifr->ifr_data, sizeof(i2c)); + err =3D copyout(&i2c, ifr_data_get_ptr(ifr), + sizeof(i2c)); break; } case SIOCSIFCAP: Modified: head/sys/net80211/ieee80211_ioctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_ioctl.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/net80211/ieee80211_ioctl.c Fri Mar 30 18:50:13 2018 (r331797) @@ -3567,7 +3567,8 @@ ieee80211_ioctl(struct ifnet *ifp, u_long cmd, caddr_t break; case SIOCG80211STATS: ifr =3D (struct ifreq *)data; - copyout(&vap->iv_stats, ifr->ifr_data, sizeof (vap->iv_stats)); + copyout(&vap->iv_stats, ifr_data_get_ptr(ifr), + sizeof (vap->iv_stats)); break; case SIOCSIFMTU: ifr =3D (struct ifreq *)data; Modified: head/sys/netinet/ip_carp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/netinet/ip_carp.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/netinet/ip_carp.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1708,7 +1708,7 @@ carp_ioctl(struct ifreq *ifr, u_long cmd, struct threa struct carp_softc *sc =3D NULL; int error =3D 0, locked =3D 0; =20 - if ((error =3D copyin(ifr->ifr_data, &carpr, sizeof carpr))) + if ((error =3D copyin(ifr_data_get_ptr(ifr), &carpr, sizeof carpr))) return (error); =20 ifp =3D ifunit_ref(ifr->ifr_name); @@ -1824,7 +1824,8 @@ carp_ioctl(struct ifreq *ifr, u_long cmd, struct threa break; } carp_carprcp(&carpr, sc, priveleged); - error =3D copyout(&carpr, ifr->ifr_data, sizeof(carpr)); + error =3D copyout(&carpr, ifr_data_get_ptr(ifr), + sizeof(carpr)); } else { int i, count; =20 @@ -1842,7 +1843,8 @@ carp_ioctl(struct ifreq *ifr, u_long cmd, struct threa IFNET_FOREACH_CARP(ifp, sc) { carp_carprcp(&carpr, sc, priveleged); carpr.carpr_count =3D count; - error =3D copyout(&carpr, ifr->ifr_data + + error =3D copyout(&carpr, + (caddr_t)ifr_data_get_ptr(ifr) + (i * sizeof(carpr)), sizeof(carpr)); if (error) { CIF_UNLOCK(ifp->if_carp); Modified: head/sys/netpfil/pf/if_pfsync.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/netpfil/pf/if_pfsync.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/netpfil/pf/if_pfsync.c Fri Mar 30 18:50:13 2018 (r331797) @@ -1319,7 +1319,8 @@ pfsyncioctl(struct ifnet *ifp, u_long cmd, caddr_t dat pfsyncr.pfsyncr_defer =3D (PFSYNCF_DEFER =3D=3D (sc->sc_flags & PFSYNCF_DEFER)); PFSYNC_UNLOCK(sc); - return (copyout(&pfsyncr, ifr->ifr_data, sizeof(pfsyncr))); + return (copyout(&pfsyncr, ifr_data_get_ptr(ifr), + sizeof(pfsyncr))); =20 case SIOCSETPFSYNC: { @@ -1330,7 +1331,8 @@ pfsyncioctl(struct ifnet *ifp, u_long cmd, caddr_t dat =20 if ((error =3D priv_check(curthread, PRIV_NETINET_PF)) !=3D 0) return (error); - if ((error =3D copyin(ifr->ifr_data, &pfsyncr, sizeof(pfsyncr)))) + if ((error =3D copyin(ifr_data_get_ptr(ifr), &pfsyncr, + sizeof(pfsyncr)))) return (error); =20 if (pfsyncr.pfsyncr_maxupdates > 255) Modified: head/sys/security/mac/mac_net.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/security/mac/mac_net.c Fri Mar 30 18:49:52 2018 (r331796) +++ head/sys/security/mac/mac_net.c Fri Mar 30 18:50:13 2018 (r331797) @@ -406,7 +406,7 @@ mac_ifnet_ioctl_get(struct ucred *cred, struct ifreq * if (!(mac_labeled & MPC_OBJECT_IFNET)) return (EINVAL); =20 - error =3D copyin(ifr->ifr_ifru.ifru_data, &mac, sizeof(mac)); + error =3D copyin(ifr_data_get_ptr(ifr), &mac, sizeof(mac)); if (error) return (error); =20 @@ -449,7 +449,7 @@ mac_ifnet_ioctl_set(struct ucred *cred, struct ifreq * if (!(mac_labeled & MPC_OBJECT_IFNET)) return (EINVAL); =20 - error =3D copyin(ifr->ifr_ifru.ifru_data, &mac, sizeof(mac)); + error =3D copyin(ifr_data_get_ptr(ifr), &mac, sizeof(mac)); if (error) return (error); =20 ----- End forwarded message ----- --TA4f0niHM6tHt3xR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJavoe8AAoJEKzQXbSebgfAR10H/1Jgnc4wPEYADf3GkfYrdqhD eNckmUnd3uzx85hYLxpwe6NePmA3vspMg+L4cSiu9sDlytiGRTvs7ZUyv6ZF0t5V xhawYLopwJoS21oPBGCXXPp5GwzHPdEmUFfmMC5DCcSv1HNOGGkcNGbP0A+3lhSq IYJ/vYsM52YWxr8rp2HRxk/lbRwj20YR8Ah/CUqZj9VUeJrCa1j/hqxgJz9SK2UB cWH7x5nGe6hxIa/77JqzbH1tV/wbnWaSRAWDNh+m/yKfDRQFsFlSqb7APDWupNs7 +eMFFV4FALb1oyvqg6hKqOzMhkW5t2mguxalWfdM2uwqJfmJNbIoKh0tcHw3K5U= =Pxb5 -----END PGP SIGNATURE----- --TA4f0niHM6tHt3xR-- From owner-freebsd-current@freebsd.org Sat Mar 31 00:28:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30E75F76A97 for ; Sat, 31 Mar 2018 00:28:11 +0000 (UTC) (envelope-from areilly@bigpond.net.au) 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 BC9EA8779C for ; Sat, 31 Mar 2018 00:28:10 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: by mailman.ysv.freebsd.org (Postfix) id 6DF0DF76A93; Sat, 31 Mar 2018 00:28:10 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46CCDF76A92 for ; Sat, 31 Mar 2018 00:28:10 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta33p.bpe.bigpond.com (nsstlmta33p.bpe.bigpond.com [203.38.21.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F19A487783; Sat, 31 Mar 2018 00:28:05 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep33p-svc.bpe.nexus.telstra.com.au with ESMTP id <20180331002753.HTZY15908.nsstlfep33p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sat, 31 Mar 2018 11:27:53 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtgedrfeehgdefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpeetnhgurhgvficutfgvihhllhihuceorghrvghilhhlhiessghighhpohhnugdrnhgvthdrrghuqeenucffohhmrghinhepfhhrvggvsghsugdrohhrghdprggtqdhrrdhnuhenucfkphepuddvgedrudeltddrgedtrddukedvnecurfgrrhgrmhephhgvlhhopegkvghnrdgrtgdqrhdrnhhupdhinhgvthepuddvgedrudeltddrgedtrddukedvpdhm X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from Zen.ac-r.nu (124.190.40.182) by smtp.telstra.com (9.0.019.22-1) (authenticated as areilly@bigpond.net.au) id 5A614436199D079C; Sat, 31 Mar 2018 11:27:53 +1100 Date: Sat, 31 Mar 2018 11:27:46 +1100 From: Andrew Reilly To: Jonathan Looney Cc: FreeBSD Current , Warner Losh , jtl@freebsd.org Subject: Re: 12-Current panics on boot (didn't a week ago.) Message-ID: <20180331002746.GA2466@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> <20180324232206.GA2457@Zen.ac-r.nu> <20180325032110.GA10881@Zen.ac-r.nu> 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.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 31 Mar 2018 00:28:11 -0000 Hi Jonathan, all, I've just compiled and booted a kernel derived from current-GENERIC but with nooptions TCP_BLACKBOX, and much to my surprise it boots. Possible link to network-related activities is that the next line of boot output that was not being displayed during the crash is: [ath_hal] loaded That's vaguely network-shaped: could it be an issue? Please let me know if there's anything else that I could test or poke, in order to find the real culprit. My make.conf says: KERNCONF=ZEN WRKDIRPREFIX=/usr/obj/ports MALLOC_PRODUCTION=yes My /usr/src/sys/amd64/conf/ZEN says: include GENERIC nooptions TCP_BLACKBOX Uname -a says: FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331768M: Sat Mar 31 10:47:52 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/ZEN amd64 Cheers, Andrew Here's the top part of the new dmesg.boot, FYI: Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r331768M: Sat Mar 31 10:47:52 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/ZEN amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.45-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x7 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33271214080 (31729 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20180313/tbfadt-796) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1497224985 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0xffffffff8109f600, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 netmap: loaded module nexus0 vtvga0: on motherboard cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 350 Event timer "HPET2" frequency 14318180 Hz quality 350 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 amdsmn0: on hostb0 amdtemp0: on hostb0 On Sun, Mar 25, 2018 at 04:35:31AM +0000, Jonathan Looney wrote: > For now, you can update through r331485 and then take TCP_BLACKBOX out of > your kernel config file. That won’t really “fix” anything, but should at > least get you a booting system (assuming the new code from r331347 is > really triggering a problem). > > > I’ll take another look to see if I missed something in the commit. But, at > the moment, I’m hard-pressed to see how r331347 would cause the problem you > describe. > > > Jonathan > > On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly > wrote: > > > OK, I've completed the search: r331346 works, r331347 panics > > somewhere in the initialization of random. > > > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > > anything obvious to tweak, unfortunately. It's a fair chunk of new > > code but it's all network-stack related, and my kernel is panicking > > long before any network activity happens. > > > > Any suggestions? > > > > Cheers, > > > > Andrew > > > > On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote: > > > Thanks Andrew... I can't recreate this on my VM nor my real hardware. > > > > > > Warner > > > > > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly > > > wrote: > > > > > > > So, r331464 crashes in the same place, on my system. r331064 still > > boots > > > > OK. I'll keep searching. > > > > > > > > One week ago there was a change to randomdev to poll for signals every > > so > > > > often, as a defence against very large reads. That wouldn't have > > > > introduced a race somewhere, > > > > or left things in an unexpected state, perhaps? That change (r331070) > > by > > > > cem@ is just a few revisions after the one that is working for me. > > I'll > > > > start looking there... > > > > > > > > Cheers, > > > > > > > > Andrew > > > > > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > > > > > Hi Warner, > > > > > > > > > > The breakage was in 331470, and at least one version earlier, that I > > > > updated past when it panicked. > > > > > > > > > > I'm guessing that kdb's inability to dump would be down to it not > > having > > > > found any disk devices yet, right? So yes, bisecting to narrow down > > the > > > > issue is probably the best bet. I'll try your r331464: if that works > > that > > > > leaves only four or five revisions. Of course the breakage could be > > > > hardware specific. > > > > > > > > > > Cheers, > > > > > -- > > > > > Andrew > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Mar 31 10:29:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CD89F75D6B for ; Sat, 31 Mar 2018 10:29:13 +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 9E22C7C906 for ; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 58B4CF75D67; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44885F75D66; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD5207C901; Sat, 31 Mar 2018 10:29:11 +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 w2VAT1aI061503 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 31 Mar 2018 13:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2VAT1aI061503 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2VAT1I3061502; Sat, 31 Mar 2018 13:29:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 31 Mar 2018 13:29:01 +0300 From: Konstantin Belousov To: current@freebsd.org Cc: amd64@freebsd.org, bde@freebsd.org Subject: i386 4/4 change Message-ID: <20180331102901.GN1774@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) 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.25 Precedence: 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, 31 Mar 2018 10:29:13 -0000 Hi, the change to provide full 4G of address space for both kernel and user on i386 is ready to land. The motivation for the work was to both mitigate Meltdown on i386, and to give more breazing space for still used 32bit architecture. The patch was tested by Peter Holm, and I am satisfied with the code. If you use i386 with HEAD, I recommend you to apply the patch from https://reviews.freebsd.org/D14633 and report any regressions before the commit, not after. Unless a significant issue is reported, I plan to commit the change somewhere at Wed/Thu next week. Also I welcome patch comments and reviews. From owner-freebsd-current@freebsd.org Sat Mar 31 16:13:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3B09F6CF51 for ; Sat, 31 Mar 2018 16:13:09 +0000 (UTC) (envelope-from jmaloney@ixsystems.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 247BE6A2F9 for ; Sat, 31 Mar 2018 16:13:09 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: by mailman.ysv.freebsd.org (Postfix) id D9FC8F6CF43; Sat, 31 Mar 2018 16:13:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E8F3F6CF3B for ; Sat, 31 Mar 2018 16:13:08 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BD956A2ED for ; Sat, 31 Mar 2018 16:13:08 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: by mail-qk0-x232.google.com with SMTP id o205so11594743qke.3 for ; Sat, 31 Mar 2018 09:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qgbEDgC7tcIz5cxZxChtN1ORrcB1+rLKZHCFFSsv5QY=; b=yyq3b9W6VXwgUc1WB7c1TyJovGO43WU1jd2PUPNLUjdoPKnNOWwKPSpQCCYoWoI21z brPeQGkVzXj0pPxR8/nAcYb+xBn8KwAZ8rnUBoXPxfSqzG9tgtof3QVeza8E5ShvpK3z yXUrvetekZ5Wh2Wicuc7aiE/ULvpOqbCko5dvIzoeA0EQXIkDZsp30FaXOcymRnGJdsH 4/hrwEwLy6ZUVSHmrE2x/GIx0sJP45fwrrm7yT3b9qEO38g2HG5LNb91SV3moB79GNNB YkHAxswKg+oYEkAFgp8XEgtzvUYOe1PbCtjPXYUwks0T6EojnoqOsxV8miy5hYsWL92l Qc2Q== 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=qgbEDgC7tcIz5cxZxChtN1ORrcB1+rLKZHCFFSsv5QY=; b=edOyt6Xa+7ZimPpczN/xpfWCf4pUJ03YmEdLM4XYUi4hIJyWT3AsVFzT1uKnvRxdWB adQrg1KTN6I2YCorFoNafuFhEm7radaLTvsykcaPZtUJoOi40kLtU5OGXYAJy/e5PQtZ 3m4mj4Yn2/HODEYbDsBbndutLDkuQ2cJVKqaBxEw1iaQ7hfK+pPZOLXnL4pjMhXvyJ9T LfCZ4LLMmxDVzUqy0dnCowYZ8rhMtnwE2peG1xIanGqxaGKRhvT8lU/lpNzyhVbVwfNP 3mBRJKaoWFDVHrk0UiziP1qJew7v2mmwfIsdzofdfnU20lmO8NicYRUF8ONp1/qG5pNu 4obA== X-Gm-Message-State: ALQs6tAma543/FIHdI99RWyGCRLSqRS/s8QzH2MjE0q4V8PdCFQp6JDJ H5IxY9ax+5TEKa8U7iSgwmegcVDz19Z916REFmZ3Xw== X-Google-Smtp-Source: AIpwx495HFeD3twFM+1HrMKMRpQqGcODmeccMZr57Vc4TaQPxquLYLYGJAovxODMI1WsM4+XtjkS5L8N9bpCSkcbUQg= X-Received: by 10.55.22.28 with SMTP id g28mr4556263qkh.152.1522512787500; Sat, 31 Mar 2018 09:13:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.119 with HTTP; Sat, 31 Mar 2018 09:13:07 -0700 (PDT) In-Reply-To: <20180331002746.GA2466@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> <20180324232206.GA2457@Zen.ac-r.nu> <20180325032110.GA10881@Zen.ac-r.nu> <20180331002746.GA2466@Zen.ac-r.nu> From: Joe Maloney Date: Sat, 31 Mar 2018 12:13:07 -0400 Message-ID: Subject: Re: 12-Current panics on boot (didn't a week ago.) To: Andrew Reilly Cc: Jonathan Looney , FreeBSD Current , Warner Losh , "jtl@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 31 Mar 2018 16:13:10 -0000 The drm-next-kmod, and drm-stable-kmod modules panic for me. I will attach logs when I can. On Friday, March 30, 2018, Andrew Reilly wrote: > Hi Jonathan, all, > > I've just compiled and booted a kernel derived from current-GENERIC > but with nooptions TCP_BLACKBOX, and much to my surprise it boots. > Possible link to network-related activities is that the next line > of boot output that was not being displayed during the crash is: > > [ath_hal] loaded > > That's vaguely network-shaped: could it be an issue? > > Please let me know if there's anything else that I could test or > poke, in order to find the real culprit. > > My make.conf says: > > KERNCONF=3DZEN > WRKDIRPREFIX=3D/usr/obj/ports > MALLOC_PRODUCTION=3Dyes > > My /usr/src/sys/amd64/conf/ZEN says: > > include GENERIC > nooptions TCP_BLACKBOX > > Uname -a says: > FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331768M: Sat > Mar 31 10:47:52 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/Z= EN > amd64 > > Cheers, > > Andrew > > > Here's the top part of the new dmesg.boot, FYI: > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #0 r331768M: Sat Mar 31 10:47:52 AEDT 2018 > root@Zen:/usr/obj/usr/src/amd64.amd64/sys/ZEN amd64 > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLV= M > 6.0.0) > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.45-MHz K8-clas= s > CPU) > Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1 Ste= pping=3D1 > Features=3D0x178bfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=3D0x7ed8320b SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > AMD Features=3D0x2e500800 > AMD Features2=3D0x35c233ff Prefetch,OSVW,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX> > Structured Extended Features=3D0x209c01a9 BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA> > XSAVE Features=3D0xf > AMD Extended Feature Extensions ID EBX=3D0x7 > SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=3D32768 > TSC: P-state invariant, performance statistics > real memory =3D 34359738368 (32768 MB) > avail memory =3D 33271214080 (31729 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) > random: unblocking device. > Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid > Length but zero Address: 0x0000000000000000/0x1 (20180313/tbfadt-796) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-55 on motherboard > SMP: AP CPU #7 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1497224985 Hz quality 1000 > random: entropy device external interface > [ath_hal] loaded > module_register_init: MOD_LOAD (vesa, 0xffffffff8109f600, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > kbd1 at kbdmux0 > netmap: loaded module > nexus0 > vtvga0: on motherboard > cryptosoft0: on motherboard > aesni0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 on acpi0 > atrtc0: registered as a time-of-day clock, resolution 1.000000s > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 o= n > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 350 > Event timer "HPET1" frequency 14318180 Hz quality 350 > Event timer "HPET2" frequency 14318180 Hz quality 350 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > amdsmn0: on hostb0 > amdtemp0: on hostb0 > > > On Sun, Mar 25, 2018 at 04:35:31AM +0000, Jonathan Looney wrote: > > For now, you can update through r331485 and then take TCP_BLACKBOX out = of > > your kernel config file. That won=E2=80=99t really =E2=80=9Cfix=E2=80= =9D anything, but should at > > least get you a booting system (assuming the new code from r331347 is > > really triggering a problem). > > > > > > I=E2=80=99ll take another look to see if I missed something in the comm= it. But, > at > > the moment, I=E2=80=99m hard-pressed to see how r331347 would cause the= problem > you > > describe. > > > > > > Jonathan > > > > On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly > > wrote: > > > > > OK, I've completed the search: r331346 works, r331347 panics > > > somewhere in the initialization of random. > > > > > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > > > anything obvious to tweak, unfortunately. It's a fair chunk of new > > > code but it's all network-stack related, and my kernel is panicking > > > long before any network activity happens. > > > > > > Any suggestions? > > > > > > Cheers, > > > > > > Andrew > > > > > > On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote: > > > > Thanks Andrew... I can't recreate this on my VM nor my real hardwar= e. > > > > > > > > Warner > > > > > > > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly < > areilly@bigpond.net.au> > > > > wrote: > > > > > > > > > So, r331464 crashes in the same place, on my system. r331064 sti= ll > > > boots > > > > > OK. I'll keep searching. > > > > > > > > > > One week ago there was a change to randomdev to poll for signals > every > > > so > > > > > often, as a defence against very large reads. That wouldn't have > > > > > introduced a race somewhere, > > > > > or left things in an unexpected state, perhaps? That change > (r331070) > > > by > > > > > cem@ is just a few revisions after the one that is working for me= . > > > I'll > > > > > start looking there... > > > > > > > > > > Cheers, > > > > > > > > > > Andrew > > > > > > > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > > > > > > Hi Warner, > > > > > > > > > > > > The breakage was in 331470, and at least one version earlier, > that I > > > > > updated past when it panicked. > > > > > > > > > > > > I'm guessing that kdb's inability to dump would be down to it n= ot > > > having > > > > > found any disk devices yet, right? So yes, bisecting to narrow > down > > > the > > > > > issue is probably the best bet. I'll try your r331464: if that > works > > > that > > > > > leaves only four or five revisions. Of course the breakage could > be > > > > > hardware specific. > > > > > > > > > > > > Cheers, > > > > > > -- > > > > > > Andrew > > > > > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Joe Maloney QA Manager / iXsystems Enterprise Storage & Servers Driven By Open Source From owner-freebsd-current@freebsd.org Sat Mar 31 15:57:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1D68F6BB61 for ; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 5D91069871 for ; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 0F93DF6BB5F; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D84F0F6BB5A; Sat, 31 Mar 2018 15:57:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCE26986D; Sat, 31 Mar 2018 15:57:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 368CA107D6E; Sun, 1 Apr 2018 02:57:08 +1100 (AEDT) Date: Sun, 1 Apr 2018 02:57:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: current@freebsd.org, amd64@freebsd.org, bde@freebsd.org Subject: Re: i386 4/4 change In-Reply-To: <20180331102901.GN1774@kib.kiev.ua> Message-ID: <20180401004833.L3296@besplex.bde.org> References: <20180331102901.GN1774@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=DT3V0GftEuvEl1oZrMwA:9 a=1ZV-n0Uyi_mUE1wW:21 a=x2mBbHWrlB-c-CW1:21 a=-mbnTQFrRZPTw6fu:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Mailman-Approved-At: Sat, 31 Mar 2018 17:00:15 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 31 Mar 2018 15:57:19 -0000 On Sat, 31 Mar 2018, Konstantin Belousov wrote: > the change to provide full 4G of address space for both kernel and > user on i386 is ready to land. The motivation for the work was to both > mitigate Meltdown on i386, and to give more breazing space for still > used 32bit architecture. The patch was tested by Peter Holm, and I am > satisfied with the code. > > If you use i386 with HEAD, I recommend you to apply the patch from > https://reviews.freebsd.org/D14633 > and report any regressions before the commit, not after. Unless > a significant issue is reported, I plan to commit the change somewhere > at Wed/Thu next week. > > Also I welcome patch comments and reviews. It crashes at boot time in getmemsize() unless booted with loader which I don't want to use. It is much slower, and I couldn't find an option to turn it off. For makeworld, the system time is slightly more than doubled, the user time is increased by 16%, and the real time is increased by 21%. On amd64, turning off pti and not having ibrs gives almost no increase in makeworld times relative to old versions, and pti only costs about 5% IIRC. Makeworld is not very syscall-intensive. netblast is very syscall-intensive, and its throughput is down by a factor of 5 (660/136 = 4.9, 1331/242 = 5.5). netblast 127.0.0.1 5001 5 10 (localhost, port 5001, 5-byte tinygrams for 10 s): 537 kpps sent, 0 kpps dropped # before this patch (CPU use 1.3) 136 kpps sent, 0 kpps dropped # after (CPU use 2.1) (Pure software overheads. It uses 1.6 times as much CPU to go 4 times slower). netblast 192.168.2.8 (low end PCI33 lem on low latency 1 Gbps LAN) 275 kpps sent, 1045 kpps dropped # before (CPU use 1.3) 245 kpps sent, 0 kpps dropped # after (CPU use 1.3) (The hardware can't do anywhere near line rate of ~1500 kpps, so this becomes a benchmark of syscalls and dropping packets. The change makes FreeBSD so slow that 8 CPUs at 4.08 can't saturate a low end PCI33 NIC (the hardware saturates at about 282 kpps for tx and about 400 kpps for rx)). netblast 192.168.2.8 (low end PCIe em on low latency 1 Gbps LAN) 1316 kpps sent, 3 kpps dropped # before (CPU use 1.6) 243 kpps sent, 0 kpps dropped # after (CPU use 1.2) This is seriously slower for the most useful case. It reduces a system that could almost reach line rate using about 2 of 8 CPUs at 4 GHz to one that that is slower than with 1 CPU at 2 GHz (the latter saturates in software at about 640 kpps in old versions of FreeBSD at at about 400 kpps in -current). Initial debugging of the crash: it crashes on the first pmap_kenter() in getmemsize(). I configure debug.late_console to 0. That works, and without it getmemsize() can't even be debugged since it is after console initialization and ddb entry with -d. In getmemsize(), of course all the preload calls return 0 and smapbase is NULL. Then vm86 bios calls work and give basemem = 0x276. Then basemem_setup() is called and it returns. Then pmap_kenter() is called and it crashes: Stopped at getmemsize+0xb3: pushl $0x1000 Stopped at getmemsize+0xb8: pushl $0x1000 Stopped at getmemsize+0xbd: call pmap_kenter Stopped at pmap_kenter: pushl %ebp Stopped at pmap_kenter+0x1: movl %esp,%ebp Stopped at pmap_kenter+0x3: movl 0x8(%ebp),%eax Stopped at pmap_kenter+0x6: shrl $0xc,%eax Stopped at pmap_kenter+0x9: movl 0xc(%ebp),%edx Stopped at pmap_kenter+0xc: orl $0x3,%edx Stopped at pmap_kenter+0xf: movl %edx,PTmap(,%eax,4) The last instruction crashes because PTmap is not mapped at this point: db> p/x $edx 1003 db> p/x PTmap ff800000 db> p/x $eax 1 db> x/x PTmap PTmap:KDB: reentering KDB: stack backtrace: db_trace_self_wrapper(cec5cb,1420a04,c6de83,1420978,1,...) at db_trace_self_wrapper+0x24/frame 0x142095c kdb_reenter(1420978,1,ff80003a,1420998,8f1419,...) at kdb_reenter+0x24/frame 0x1420968 trap(1420a10) at trap+0xa0/frame 0x1420a04 calltrap() at calltrap+0x8/frame 0x1420a04 --- trap 0xc, eip = 0xc5c394, esp = 0x1420a50, ebp = 0x1420a88 --- db_read_bytes(ff800001,3,1420aa0) at db_read_bytes+0x29/frame 0x1420a88 db_get_value(ff800000,4,0,0,d2d304,...) at db_get_value+0x20/frame 0x1420ab4 db_examine(ff800000,1,ffffffff,1420b00) at db_examine+0x144/frame 0x1420ae4 db_command(cb1d99,1420be4,8f0f01,d1d28a,0,...) at db_command+0x20a/frame 0x1420b90 db_command_loop(d1d28a,0,1420bac,1420b9c,1420be4,...) at db_command_loop+0x55/frame 0x1420b9c db_trap(a,ffff4ff0,1,1,80046,...) at db_trap+0xe1/frame 0x1420be4 kdb_trap(a,ffff4ff0,1420cc4) at kdb_trap+0xb1/frame 0x1420c10 trap(1420cc4) at trap+0x523/frame 0x1420cb8 calltrap() at calltrap+0x8/frame 0x1420cb8 --- trap 0xa, eip = 0xc65a4a, esp = 0x1420d04, ebp = 0x1420d04 --- pmap_kenter(1000,1000,1429000,8efe13,0,...) at pmap_kenter+0xf/frame 0x1420d04 getmemsize(1,5a8807ff,ee,59a80097,ee,...) at getmemsize+0xc2/frame 0x1420fc4 init386(1428000) at init386+0x2bb/frame 0x1420ff4 btext() at btext+0x55 *** error reading from address ff800000 *** --More-- KDB: reentering KDB: stack backtrace: db_trace_self_wrapper(cec5cb,1420ab4,8ee255,cb1923,ff800000,...) at db_trace_self_wrapper+0x24/frame 0x1420a7c kdb_reenter(cb1923,ff800000,0) at kdb_reenter+0x24/frame 0x1420a88 db_get_value(ff800000,4,0,0,d2d304,...) at db_get_value+0x3a/frame 0x1420ab4 db_examine(ff800000,1,ffffffff,1420b00) at db_examine+0x144/frame 0x1420ae4 db_command(cb1d99,1420be4,8f0f01,d1d28a,0,...) at db_command+0x20a/frame 0x1420b90 db_command_loop(d1d28a,0,1420bac,1420b9c,1420be4,...) at db_command_loop+0x55/frame 0x1420b9c db_trap(a,ffff4ff0,1,1,80046,...) at db_trap+0xe1/frame 0x1420be4 kdb_trap(a,ffff4ff0,1420cc4) at kdb_trap+0xb1/frame 0x1420c10 trap(1420cc4) at trap+0x523/frame 0x1420cb8 calltrap() at calltrap+0x8/frame 0x1420cb8 --- trap 0xa, eip = 0xc65a4a, esp = 0x1420d04, ebp = 0x1420d04 --- pmap_kenter(1000,1000,1429000,8efe13,0,...) at pmap_kenter+0xf/frame 0x1420d04 getmemsize(1,5a8807ff,ee,59a80097,ee,...) at getmemsize+0xc2/frame 0x1420fc4 init386(1428000) at init386+0x2bb/frame 0x1420ff4 btext() at btext+0x55 db> Bruce From owner-freebsd-current@freebsd.org Sat Mar 31 23:06:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FF12F63B79 for ; Sat, 31 Mar 2018 23:06:02 +0000 (UTC) (envelope-from dim@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 9F8CB7B34D for ; Sat, 31 Mar 2018 23:06:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5D756F63B76; Sat, 31 Mar 2018 23:06:01 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A9AAF63B74; Sat, 31 Mar 2018 23:06:01 +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 6A6C87B34B; Sat, 31 Mar 2018 23:06:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1A99636A4E; Sun, 1 Apr 2018 01:05:58 +0200 (CEST) From: Dimitry Andric Message-Id: <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FEF4CFF3-A8E3-4C92-9CB5-9B04D7FD34B3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: i386 4/4 change Date: Sun, 1 Apr 2018 01:05:57 +0200 In-Reply-To: <20180401004833.L3296@besplex.bde.org> Cc: Konstantin Belousov , current@freebsd.org, amd64@freebsd.org, bde@freebsd.org To: Bruce Evans References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 31 Mar 2018 23:06:02 -0000 --Apple-Mail=_FEF4CFF3-A8E3-4C92-9CB5-9B04D7FD34B3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 31 Mar 2018, at 17:57, Bruce Evans wrote: > > On Sat, 31 Mar 2018, Konstantin Belousov wrote: > >> the change to provide full 4G of address space for both kernel and >> user on i386 is ready to land. The motivation for the work was to both >> mitigate Meltdown on i386, and to give more breazing space for still >> used 32bit architecture. The patch was tested by Peter Holm, and I am >> satisfied with the code. >> >> If you use i386 with HEAD, I recommend you to apply the patch from >> https://reviews.freebsd.org/D14633 >> and report any regressions before the commit, not after. Unless >> a significant issue is reported, I plan to commit the change somewhere >> at Wed/Thu next week. >> >> Also I welcome patch comments and reviews. > > It crashes at boot time in getmemsize() unless booted with loader which > I don't want to use. For me, it at least compiles and boots OK, but I'm one of those crazy people who use the default boot loader. ;) I haven't yet run any performance tests, I'll try building world and a few large ports tomorrow. General operation from the command line does not feel "sluggish" in any way, however. -Dimitry --Apple-Mail=_FEF4CFF3-A8E3-4C92-9CB5-9B04D7FD34B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsAUVQAKCRCwXqMKLiCW o98sAKCDkLWdzL8NVaBN8mYfJAtBViO+lgCg/53fGIcQd2gJ7rA6b/pxf8X50K4= =P8fD -----END PGP SIGNATURE----- --Apple-Mail=_FEF4CFF3-A8E3-4C92-9CB5-9B04D7FD34B3-- From owner-freebsd-current@freebsd.org Sat Mar 31 23:23:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FD8AF65110 for ; Sat, 31 Mar 2018 23:23:40 +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 06BFE7BDEA for ; Sat, 31 Mar 2018 23:23:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B249CF6510C; Sat, 31 Mar 2018 23:23:39 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FD83F6510A; Sat, 31 Mar 2018 23:23:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16E387BDE6; Sat, 31 Mar 2018 23:23: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 w2VNNS5u034732 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Apr 2018 02:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2VNNS5u034732 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2VNNSjq034731; Sun, 1 Apr 2018 02:23:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Apr 2018 02:23:28 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Bruce Evans , current@freebsd.org, amd64@freebsd.org, bde@freebsd.org Subject: Re: i386 4/4 change Message-ID: <20180331232328.GS1774@kib.kiev.ua> References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> User-Agent: Mutt/1.9.4 (2018-02-28) 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.25 Precedence: 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, 31 Mar 2018 23:23:40 -0000 On Sun, Apr 01, 2018 at 01:05:57AM +0200, Dimitry Andric wrote: > I haven't yet run any performance tests, I'll try building world and a > few large ports tomorrow. General operation from the command line does > not feel "sluggish" in any way, however. I just updated the review with some changes which should have effect on the copyout performance.