From owner-freebsd-current@freebsd.org Sun Jul 8 02:55:08 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 CF346FDD284 for ; Sun, 8 Jul 2018 02:55:07 +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 3DE417BAA3; Sun, 8 Jul 2018 02:55:07 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 033e05da TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sat, 7 Jul 2018 19:55:04 -0700 (PDT) Subject: Re: atomic changes break drm-next-kmod? To: Hans Petter Selasky , Johannes Lundberg , Konstantin Belousov Cc: Niclas Zeising , Warner Losh , jhb@freebsd.org, ohartmann@walstatt.org, freebsd-current References: <4c5411dd-9f6b-7245-6ade-e11040f74687@FreeBSD.org> <24f5d737-a205-6fcc-0a33-a84601d2ff7a@nomadlogic.org> <29ce4eab-6667-d2ca-b5d8-3deeef28f142@selasky.org> <20180705193646.GM5562@kib.kiev.ua> <5dc2a315-4b71-9ff0-0a37-576649e9144b@FreeBSD.org> <4797c607-c261-77f7-eccf-45056bf56694@daemonic.se> <20180706084729.GN5562@kib.kiev.ua> <1cd8c3c6-5d85-fbf3-cc06-1df8282216a1@selasky.org> From: Pete Wright Message-ID: Date: Sat, 7 Jul 2018 19:54:59 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <1cd8c3c6-5d85-fbf3-cc06-1df8282216a1@selasky.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.27 Precedence: 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, 08 Jul 2018 02:55:08 -0000 On 07/06/2018 03:15, Hans Petter Selasky wrote: > On 07/06/18 11:14, Johannes Lundberg wrote: >> On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov >> wrote: >> >>> On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote: >>>> On 07/06/18 00:02, Warner Losh wrote: >>>>> >>>>> >>>>> On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin >>>> > wrote: >>>>> >>>>>      On 7/5/18 12:36 PM, Konstantin Belousov wrote: >>>>>       > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky >>> wrote: >>>>>       >> On 07/05/18 20:59, Hans Petter Selasky wrote: >>>>>       >>> On 07/05/18 19:48, Pete Wright wrote: >>>>>       >>>> >>>>>       >>>> >>>>>       >>>> On 07/05/2018 10:10, John Baldwin wrote: >>>>>       >>>>> On 7/3/18 5:10 PM, Pete Wright wrote: >>>>>       >>>>>> >>>>>       >>>>>> On 07/03/2018 15:56, John Baldwin wrote: >>>>>       >>>>>>> On 7/3/18 3:34 PM, Pete Wright wrote: >>>>>       >>>>>>>> On 07/03/2018 15:29, John Baldwin wrote: >>>>>       >>>>>>>>> That seems like kgdb is looking at the wrong CPU.  >>>>> Can >>>>>      you use >>>>>       >>>>>>>>> 'info threads' and look for threads not stopped in >>>>>      'sched_switch' >>>>>       >>>>>>>>> and get their backtraces?  You could also just do >>> 'thread >>>>>      apply >>>>>       >>>>>>>>> all bt' and put that file at a URL if that is >>>>> easiest. >>>>>       >>>>>>>>> >>>>>       >>>>>>>> sure thing John - here's a gist of "thread apply >>>>> all bt" >>>>>       >>>>>>>> >>>>>       >>>>>>>> >>>>> https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed >>>>> >>> >>>>>       >>>>>>> That doesn't look right at all.  Are you sure the >>>>> kernel >>>>>      matches the >>>>>       >>>>>>> vmcore?  Also, which kgdb version are you using? >>>>>       >>>>>>> >>>>>       >>>>>> yea i agree that doesn't look right at all.  here is my >>> setup: >>>>>       >>>>>> >>>>>       >>>>>> $ which kgdb >>>>>       >>>>>> /usr/bin/kgdb >>>>>       >>>>>> $ kgdb >>>>>       >>>>>> GNU gdb 6.1.1 [FreeBSD] >>>>>       >>>>>> $ ls -lh /var/crash/vmcore.1 >>>>>       >>>>>> -rw-------  1 root  wheel 1.6G Jul  3 15:03 >>>>>      /var/crash/vmcore.1 >>>>>       >>>>>> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug >>>>>       >>>>>> -r-xr-xr-x  1 root  wheel 87840496 Jul  3 13:54 >>>>>       >>>>>> /usr/lib/debug/boot/kernel/kernel.debug >>>>>       >>>>>> >>>>>       >>>>>> and i invoke kgdb like so: >>>>>       >>>>>> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug >>>>>      /var/crash/vmcore.1 >>>>>       >>>>>> >>>>>       >>>>>> here's a gist of my full gdb session: >>>>>       >>>>>> http://termbin.com/krsn >>>>>       >>>>>> >>>>>       >>>>>> dunno - maybe i have a bad core dump?  regardless, more >>> than >>>>>      happy to >>>>>       >>>>>> help so let me know if i should try anything else or >>> patches >>>>>      etc.. >>>>>       >>>>> Can you try installing gdb from ports and using >>>>>      /usr/local/bin/kgdb? >>>>>       >>>>> >>>>>       >>>> >>>>>       >>>> that seems to have done the trick, at least the output >>>>> looks >>> more >>>>>       >>>> encouraging. >>>>>       >>>> >>>>>       >>>>   --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >>>>>       >>>> KDB: enter: panic >>>>>       >>>> >>>>>       >>>> __curthread () at ./machine/pcpu.h:231 >>>>>       >>>> 231        __asm("movq %%gs:%1,%0" : "=r" (td) >>>>>       >>>> >>>>>       >>>> >>>>>       >>>> here's my full kgdb session: >>>>>       >>>> http://termbin.com/qa4f >>>>>       >>>> >>>>>       >>>> i don't see any threads not in "sched_switch" though :( >>>>>       >>> >>>>>       >>> Hi, >>>>>       >>> >>>>>       >>> The problem may be that the patch to enable atomic inlining >>> of all >>>>>       >>> macros forgot to set the SMP keyword which means SMP is not >>>>>      defined at >>>>>       >>> all for KLD's so all non-kernel atomic usage is with >>>>> MPLOCKED >>>>>      empty! >>>>>       > Problem is that out-of-tree modules build does not have >>>>> opt*.h >>> files >>>>>       > from the kernel.  UP config is a valid one, flipping some >>> option's >>>>>       > default value does not solve the problem. >>>>> >>>>>      Yes, but using the lock prefix in a generic module is ok (it >>>>> will >>> still >>>>>      work, just not quite as fast) whereas the lack of lock is >>>>> fatal on >>>>>      SMP.  I would amend Hans' patch slightly to honor the opt_* >>>>> setting >>>>>      for KLD_TIED (but that is only true if KLD_TIED means "built as >>> part of >>>>>      a kernel build, so has valid opt_foo.h headers" and not >>>>>      'a standalone module where someone put MODULES_TIED=1 on the >>> command >>>>>      line >>>>>      to make'). >>>>> >>>>> >>>>> I agree with this default. It's sensible to default to (a) the most >>>>> popular thing and (b) thing that always works, especially when (a) >>>>> and >>>>> (b) are identical. >>>>> >>>>> Don't make me start the "Do we really need an SMP option, why not >>>>> make >>>>> it always on" thread :) The number of relevant uniprocessor x86 boxes >>>>> that benefit from omitting SMP is so small as to be irrelevant, IMHO. >>> A >>>>> MP kernel runs just fine on them... >>>>> >>>>> Warner >>>> >>>> Where are we on this? >>>> It is important to get it fixed, it's already been 4 days, which >>>> means 4 >>>> days of all modern FreeBSD desktop systems being broken, and possibly >>>> other systems with kernel modules from ports as well. >>>> >>>> >>>> Another question, how hard would it be to expose how the kernel was >>>> built to modules built from ports, so that they can figure out stuff >>>> like SMP and others, that might affect the module build? >>> Point the KERNBUILDDIR variable to the directory of the kernel build. >>> This is the directory where *.o and opt*.h are located.  Then >>> everything >>> would just work. >>> >> >> Is the solution that we require everyone to build a kernel before >> they can >> build the standalone modules or am I missing something here? >> > > Hi, > > Here is a temporary fix: > https://svnweb.freebsd.org/changeset/base/336025 > > Like Konstantin says this issue needs to be revisited. > this patch has been stable for me for a couple days now after rebuilding drm-next under the new kernel containing this update.  we may want to kick-off an update of the drm-next pkg if that hasn't happened already.  the old package caused periodic kernel-panics on my end. cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sun Jul 8 19:08:10 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 7ED761048F81 for ; Sun, 8 Jul 2018 19:08:10 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1383A83C7A for ; Sun, 8 Jul 2018 19:08:09 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw0-x230.google.com with SMTP id l189-v6so5836208ywb.10 for ; Sun, 08 Jul 2018 12:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OtdwG+cZmORZQoVs3dRRvB6HIBcvsQLS2M3JHfEzGYM=; b=kHAaCOFG/7k4sMsqgWSg1b3dkPF9eJz/zluS75X/zt7pGUGNHSYUXB4/616A09Z+0A K/395VZWLp5cWTR993xv7joL46JhfJcRMiT+E6Z3GMwxno0OAmqwle04+HghMgFiOrBk epKSrAPqUZIt9N3dda2Jdgl/lw5d2WW0HVITra4THREnT7bBB3XuZKxFEhgwdlZgBOAI /vAqUnBwlnA3tjdQLbwKABQtSrQmzzWGZxm2Hc563qBkY2+JJHvtDb2IMHBP8m/NoKLX 6A0baB2pSLxdCV0L1hULlYVwlZ2jkuiLV8AKDkyLdEwCUCnst9CmsTjjdeGM8vfYzJKf /Spw== 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=OtdwG+cZmORZQoVs3dRRvB6HIBcvsQLS2M3JHfEzGYM=; b=XJwaAiPDGULElgPy6HVej7fT7nEJb1JXORa4BS8fm0mh70WS1YI3g/68HRTIElhozg hTPol6nBItZrCJK20xWDqShEFvMQ3My8ulPIFSiti6fTMJg0S/8HGLDLpqBHxxqJnMXr HPNmW3pyvfC11FbukzJL7dLanIg3H0lZIfjDo+/3tC93yOlhNbrgc+PSRlreTQst3AJs gjU+38Uyw/Ki1vyRHLB1HXxZF4MzsVnwozKjwWIJsVtyxRis6NR9bg0Cutgq6+jX3gmP Mcj6dEgGxKl03QjxPL6Kg9lj0+W0mmHCKUnayDUXPSXFDNIcW+tymyfOsHe6uFFXZImT Nb0Q== X-Gm-Message-State: APt69E0cLJPxjPJ3UO/cvA5UeTNH3190RHz9mhoOpixmt3MSwuOG4uDn I/6zoRg6zZnvt+qvDk/MxsNFN9a3HeqMOPClBnQv2A== X-Google-Smtp-Source: AAOMgpfexSHKswLLafBn2SXIXxzUGDNqWP2C67BQBOqpoXJI8sm2t7NazHs6Hc55w6rfbrWHG2/qsXPV9XAQV+U2vsQ= X-Received: by 2002:a81:93c6:: with SMTP id k189-v6mr7976806ywg.41.1531076888907; Sun, 08 Jul 2018 12:08:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:b90:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 12:08:08 -0700 (PDT) In-Reply-To: <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> From: Oliver Pinter Date: Sun, 8 Jul 2018 21:08:08 +0200 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 19:08:10 -0000 Hi! Have you or Warner any update on this code? On Thursday, April 12, 2018, Eric McCorkle wrote: > I'm in the middle of moving to a new apartment right now. It's going to > be a bit before I can get to this. > > On 04/11/2018 20:31, Warner Losh wrote: > > OK. I've pushed in the main part of it. The additional work I have > > shouldn't affect any of this stuff. I was going to look at what part(s) > > of your open reviewed needed to be redone tomorrow and send you > > feedback, but if you wanted to get a start before then, I'm happy to > > answer questions. All the rest of my work is going to be selecting the > > root partition when we're told to us a specific partition, so will be > > very constrained. > > > > Warner > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > > wrote: > > > > I think the thing to do at this point is to wait for the current > work on > > loader.efi to land, then adapt my patches to apply against that work. > > > > On 04/11/2018 15:06, Warner Losh wrote: > > > Still reviewing the code. I'm worried it's too i386 specific and it > > > conflicts with some work I'm doing. I'll have a list of actionable > > > critiques this week. > > > > > > Warner > > > > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > > > > > > >> > > > wrote: > > > > > > Hi! > > > > > > Is there any update regarding the rebase or the inclusion to > base > > > system? > > > On 3/28/18, Eric McCorkle eric@metricspace.net> > > > >> > wrote: > > > > I'll do another rebase from head just to be sure > > > > > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh < > imp@bsdimp.com > > > >> 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" < > tommi.pernila@iki.fi > > > >> > 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 < > eric@metricspace.net > > > >> > > > >>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. > > > > _______________________________________________ > > > > 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 Jul 8 19:31: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 2569D10266BD for ; Sun, 8 Jul 2018 19:31:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8733A850D7 for ; Sun, 8 Jul 2018 19:31:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 8e72dd70-82e5-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 8e72dd70-82e5-11e8-8837-614b7c574d04; Sun, 08 Jul 2018 19:31:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w68JVlMl031740; Sun, 8 Jul 2018 13:31:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531078307.1336.22.camel@freebsd.org> Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? From: Ian Lepore To: Oliver Pinter , Eric McCorkle Cc: Warner Losh , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Date: Sun, 08 Jul 2018 13:31:47 -0600 In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 19:31:54 -0000 On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote: > Hi! > > Have you or Warner any update on this code? > > On Thursday, April 12, 2018, Eric McCorkle > wrote: > Are you aware of https://reviews.freebsd.org/D15743 ? That's my changes to add geli support to loader(8) in an architecture- agnostic way, so that "it just works" for all platforms and flavors of loader. It has been succesfully tested on armv6/7 (ubldr) and on x86 using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The only variations that aren't tested yet are the uefi flavors, because the current rootgen.sh script for assembling test images is still using boot1.efi and I don't know enough about efi myself to update the script to make it assemble images the new way Warner envisions. -- Ian > > > > I'm in the middle of moving to a new apartment right now.  It's > > going to > > be a bit before I can get to this. > > > > On 04/11/2018 20:31, Warner Losh wrote: > > > > > > OK. I've pushed in the main part of it. The additional work I > > > have > > > shouldn't affect any of this stuff.  I was going to look at what > > > part(s) > > > of your open reviewed needed to be redone tomorrow and send you > > > feedback, but if you wanted to get a start before then, I'm happy > > > to > > > answer questions. All the rest of my work is going to be > > > selecting the > > > root partition when we're told to us a specific partition, so > > > will be > > > very constrained. > > > > > > Warner > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > > net > > > > wrote: > > > > > >     I think the thing to do at this point is to wait for the > > > current > > work on > > > > > >     loader.efi to land, then adapt my patches to apply against > > > that work. > > > > > >     On 04/11/2018 15:06, Warner Losh wrote: > > >     > Still reviewing the code. I'm worried it's too i386 > > > specific and it > > >     > conflicts with some work I'm doing. I'll have a list of > > > actionable > > >     > critiques this week. > > >     > > > >     > Warner > > >     > > > >     > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > >     > > >      > > >      > >     >> > > >     > wrote: > > >     > > > >     >     Hi! > > >     > > > >     >     Is there any update regarding the rebase or the > > > inclusion to > > base > > > > > >     >     system? > > >     >     On 3/28/18, Eric McCorkle > > > eric@metricspace.net> > > > > > >     >      > > et>>> > > wrote: > > > > > >     >     > I'll do another rebase from head just to be sure > > >     >     > > > >     >     > On March 28, 2018 3:23:23 PM EDT, Warner Losh < > > imp@bsdimp.com > > > > > >     >     >> 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" < > > tommi.pernila@iki.fi > > > > > >     >      > > fi>>> > > 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 < > > eric@metricspace.net > > > > > >     >      > > et>>> > > >     >     >>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" > > >      > > >     >      > > et>> > > >     >     >>>> >> > >      > >     >>> > > >     >     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/freeb > > > sd- > > current > > > > > >      > > >     >      > > rent > > >     > > > >     >     >>>> > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@ > > > > > >     >     >>>> freebsd.org > > > " > > >     >     >>>> > > > >     >     >>>> > > >     >     >>> > > >     >     > > > >     >     > -- > > >     >     > Sent from my Android device with K-9 Mail. Please > > > excuse my > > brevity. > > > > > >     >     > _______________________________________________ > > >     >     > freebsd-current@freebsd.org > > >      > > >      > >     > > > >     >     mailing list > > >     >     > https://lists.freebsd.org/mailman/listinfo/freebsd-cu > > > rrent > > >      > > >     >      > > rent > > >     > > > >     >     > 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 Jul 8 19:38: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 64FBA1027480 for ; Sun, 8 Jul 2018 19:38:45 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 E5E17858BD for ; Sun, 8 Jul 2018 19:38:44 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yb0-x229.google.com with SMTP id y11-v6so6408288ybm.7 for ; Sun, 08 Jul 2018 12:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QU/J6UlFhav5uGhVsY7tLEy20/uHJGSgKFkIVkjDH8g=; b=fX3JZOFHNrQm58CE6LNMm6uaGP+5c8STFDJWZKPcAPdqdugPLofIKjjnYrKEA6f25R rxOF8N52yBcvlxzrZvzXWr/pDPycfwoucterbeZ/TceZlxgiEF2PqpYgnOYdGHyfyGhe ElhfpPlk3xhuNVc6gbOIxqG1kN48MUP7/NQm/3ivjjAWyIXhi3n09gsSGqxP0aiXnUfh hnyEzF2M7DHaMvcqlDBsE8wZ+sxOviuxW6ns6QLSrxs3Gc7gKPbtioi02j4mvfYGPGK8 IU4x+imAQ8k1P0JJpt62a4yiZShJ7GiIttjNdxop8Fmvw4HVN081mIxozlNaD19Uj1Xg /GhQ== 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=QU/J6UlFhav5uGhVsY7tLEy20/uHJGSgKFkIVkjDH8g=; b=WZMpAu5HUHpPv+2SczuprkAK+YjcDI5G0yhpNTIIQ7ZIIfWBCgoZFDaKVq5ShvCnPM Fm20LEAPNM/xzSgtrmykeBos7btEYCeg9b01+HKg4N/gxP/7Eolbo83prv3AhfktSVd+ T6Dxyb9XLWoGCZ6N0UMFG5ivKTGv7ddZGkzwF8qpQ2vstzVQn41NlGzSvM6P2t2P4YdQ Y2bMa40TyxueKMX5YVyiUh0uN1L13x8YVYhDhqbt/IzOT2Z3qJBcKp83hsuRAK+QyAbo 9OUrU7HgA/5bHg/8FAEQdJADaoBlk7zb/h56PDxctB/Fg5UjRhza5C46yQchm9Zj05Nb SF4w== X-Gm-Message-State: APt69E2EMFrWh/s7DyGh0KUyaj5xHMXqBe6vHC3IK867RH0vt2rKWjl8 Yk28l9EDi6VjmzdhMbAheV0TNYVGJBQ9dmik2S1Ikw== X-Google-Smtp-Source: AAOMgpcZR1Ry9XPzSamThBsgG10ltdVYhicRov3b6Z3+HOmF60ndEdhQKNON7IVHckW7RsUCpHReZU2s8mJYgMBa34I= X-Received: by 2002:a25:a2c8:: with SMTP id c8-v6mr9521987ybn.300.1531078724376; Sun, 08 Jul 2018 12:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:b90:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 12:38:43 -0700 (PDT) In-Reply-To: <1531078307.1336.22.camel@freebsd.org> References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> <1531078307.1336.22.camel@freebsd.org> From: Oliver Pinter Date: Sun, 8 Jul 2018 21:38:43 +0200 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Ian Lepore Cc: Eric McCorkle , Warner Losh , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 19:38:45 -0000 On Sunday, July 8, 2018, Ian Lepore wrote: > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote: > > Hi! > > > > Have you or Warner any update on this code? > > > > On Thursday, April 12, 2018, Eric McCorkle > > wrote: > > > > Are you aware of https://reviews.freebsd.org/D15743 ? > > That's my changes to add geli support to loader(8) in an architecture- > agnostic way, so that "it just works" for all platforms and flavors of > loader. It has been succesfully tested on armv6/7 (ubldr) and on x86 > using qemu. The x86 tests cover ufs and zfs, legacy bios and uefi. The > only variations that aren't tested yet are the uefi flavors, because > the current rootgen.sh script for assembling test images is still using > boot1.efi and I don't know enough about efi myself to update the script > to make it assemble images the new way Warner envisions. > > Not yet, but thanks for the link! > -- Ian > > > > > > > I'm in the middle of moving to a new apartment right now. It's > > > going to > > > be a bit before I can get to this. > > > > > > On 04/11/2018 20:31, Warner Losh wrote: > > > > > > > > OK. I've pushed in the main part of it. The additional work I > > > > have > > > > shouldn't affect any of this stuff. I was going to look at what > > > > part(s) > > > > of your open reviewed needed to be redone tomorrow and send you > > > > feedback, but if you wanted to get a start before then, I'm happy > > > > to > > > > answer questions. All the rest of my work is going to be > > > > selecting the > > > > root partition when we're told to us a specific partition, so > > > > will be > > > > very constrained. > > > > > > > > Warner > > > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > > > net > > > > > wrote: > > > > > > > > I think the thing to do at this point is to wait for the > > > > current > > > work on > > > > > > > > loader.efi to land, then adapt my patches to apply against > > > > that work. > > > > > > > > On 04/11/2018 15:06, Warner Losh wrote: > > > > > Still reviewing the code. I'm worried it's too i386 > > > > specific and it > > > > > conflicts with some work I'm doing. I'll have a list of > > > > actionable > > > > > critiques this week. > > > > > > > > > > Warner > > > > > > > > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > > > > > > > > > > > > > > >> > > > > > wrote: > > > > > > > > > > Hi! > > > > > > > > > > Is there any update regarding the rebase or the > > > > inclusion to > > > base > > > > > > > > > system? > > > > > On 3/28/18, Eric McCorkle > > > > > eric@metricspace.net> > > > > > > > > > > > > et>>> > > > wrote: > > > > > > > > > > I'll do another rebase from head just to be sure > > > > > > > > > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh < > > > imp@bsdimp.com > > > > > > > > > >> 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" < > > > tommi.pernila@iki.fi > > > > > > > > > > > > fi>>> > > > 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 < > > > eric@metricspace.net > > > > > > > > > > > > et>>> > > > > > >>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" > > > > > > > > > > > > et>> > > > > > >>>> >> > > > > > > >>> > > > > > 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/freeb > > > > sd- > > > current > > > > > > > > > > > > > > > > rent > > > > > > > > > > >>>> > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@ > > > > > > > > > >>>> freebsd.org > > > > " > > > > > >>>> > > > > > > >>>> > > > > > >>> > > > > > > > > > > > > -- > > > > > > Sent from my Android device with K-9 Mail. Please > > > > excuse my > > > brevity. > > > > > > > > > > _______________________________________________ > > > > > > freebsd-current@freebsd.org > > > > > > > > > > > > > > > > > mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-cu > > > > rrent > > > > > > > > > > > > rent > > > > > > > > > > > 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 Jul 8 20:36:53 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 7FEA6102DBD0 for ; Sun, 8 Jul 2018 20:36:52 +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 10B3B8878E; Sun, 8 Jul 2018 20:36:52 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.82.210.19] (mobile-166-172-61-192.mycingular.net [166.172.61.192]) (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 A3B8C3486; Sun, 8 Jul 2018 20:36:49 +0000 (UTC) Date: Sun, 08 Jul 2018 16:36:47 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <1531078307.1336.22.camel@freebsd.org> References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> <1531078307.1336.22.camel@freebsd.org> MIME-Version: 1.0 Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Ian Lepore , Oliver Pinter CC: Warner Losh , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh From: Eric McCorkle Message-ID: <8AFC01EE-A37A-4D89-9A67-8707AA3184DD@metricspace.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 20:36:53 -0000 I intend to endorse this patch over my own once I'm able to test it out on = my test images=2E My approach is highly EFI-specific, and it made sense to do it that way wh= en boot1=2Eefi was still a thing=2E The architecture agnostic method makes = more sense now that it's gone=2E=20 On July 8, 2018 3:31:47 PM EDT, Ian Lepore wrote: >On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote: >> Hi! >>=20 >> Have you or Warner any update on this code? >>=20 >> On Thursday, April 12, 2018, Eric McCorkle >> wrote: >>=20 > >Are you aware of=C2=A0https://reviews=2Efreebsd=2Eorg/D15743=C2=A0? > >That's my changes to add geli support to loader(8) in an architecture- >agnostic way, so that "it just works" for all platforms and flavors of >loader=2E It has been succesfully tested on armv6/7 (ubldr) and on x86 >using qemu=2E =C2=A0The x86 tests cover ufs and zfs, legacy bios and uefi= =2E The >only variations that aren't tested yet are the uefi flavors, because >the current rootgen=2Esh script for assembling test images is still using >boot1=2Eefi and I don't know enough about efi myself to update the script >to make it assemble images the new way Warner envisions=2E > >-- Ian > >> >=20 >> > I'm in the middle of moving to a new apartment right now=2E=C2=A0=C2= =A0It's >> > going to >> > be a bit before I can get to this=2E >> >=20 >> > On 04/11/2018 20:31, Warner Losh wrote: >> > >=20 >> > > OK=2E I've pushed in the main part of it=2E The additional work I >> > > have >> > > shouldn't affect any of this stuff=2E=C2=A0=C2=A0I was going to loo= k at what >> > > part(s) >> > > of your open reviewed needed to be redone tomorrow and send you >> > > feedback, but if you wanted to get a start before then, I'm happy >> > > to >> > > answer questions=2E All the rest of my work is going to be >> > > selecting the >> > > root partition when we're told to us a specific partition, so >> > > will be >> > > very constrained=2E >> > >=20 >> > > Warner >> > >=20 >> > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > > > net >> > > > wrote: >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0I think the thing to do at this point is to= wait for the >> > > current >> > work on >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0loader=2Eefi to land, then adapt my patches= to apply against >> > > that work=2E >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0On 04/11/2018 15:06, Warner Losh wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0> Still reviewing the code=2E I'm worried i= t's too i386 >> > > specific and it >> > > =C2=A0=C2=A0=C2=A0=C2=A0> conflicts with some work I'm doing=2E I'l= l have a list of >> > > actionable >> > > =C2=A0=C2=A0=C2=A0=C2=A0> critiques this week=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0> Warner >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0> On Wed, Apr 11, 2018 at 1:03 PM, Oliver P= inter >> > > =C2=A0=C2=A0=C2=A0=C2=A0> > > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0>= > >> > > =C2=A0=C2=A0=C2=A0=C2=A0> wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Hi! >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Is there any= update regarding the rebase or the >> > > inclusion to >> > base >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0system? >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0On 3/28/18, = Eric McCorkle > > > > > eric@metricspace=2Enet> >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > et>>> >> > wrote: >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> I'll do an= other rebase from head just to be sure >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> On March 2= 8, 2018 3:23:23 PM EDT, Warner Losh < >> > imp@bsdimp=2Ecom >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>It's on my= list for nexr, finally=2E I have an >> > > alternate patch >> > for >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>loader=2Ee= fi >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>from ESP, = but i don't think it will affect the GELI >> > > stuff=2E I >> > have some >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>time >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>slotted fo= r integration issues though=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>I am quite= mindful of the freeze dates=2E=2E=2E=2E I=C2=A0=C2=A0have >> > > some uefi >> > boot >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>loader >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>protocol c= hanges that I need to get in=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>Warner >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>On Feb 21,= 2018 11:18 PM, "Tommi Pernila" < >> > tommi=2Epernila@iki=2Efi >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > fi>>> >> > wrote: >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> Awesome,= thanks for the update and the work that >> > > you have >> > done! >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> Now we j= ust need some more reviewers eyes on the >> > > code :) >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> Br, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> Tommi >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> On Thu, = 22 Feb 2018 at 2=2E03, Eric McCorkle < >> > eric@metricspace=2Enet >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > et>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> FYI, I = just IFC'ed everything, and the current >> > > patches >> > > =C2=A0=C2=A0=C2=A0=C2=A0are still >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>fine=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> Also, t= he full GELI + standalone loader has been >> > > deployed >> > > =C2=A0=C2=A0=C2=A0=C2=A0on one of >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>my >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> laptops= for some time now=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> On 02/2= 1/2018 18:15, Eric McCorkle wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > The G= ELI work could be merged at this point, >> > > though it >> > > =C2=A0=C2=A0=C2=A0=C2=A0won't be >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>usable >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > witho= ut an additional patch to enable loader- >> > > only >> > > =C2=A0=C2=A0=C2=A0=C2=A0operation=2E=C2=A0=C2=A0The >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > patch= es are currently up for review: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > This = is the order in which they'd need to be >> > > merged: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > https= ://reviews=2Efreebsd=2Eorg/D12732 >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > This = one changes the efipart device=2E=C2=A0=C2=A0Toomas >> > > Soome >> > > =C2=A0=C2=A0=C2=A0=C2=A0identified >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0some >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > probl= ems, which I have addressed=2E=C2=A0=C2=A0He has not >> > > =C2=A0=C2=A0=C2=A0=C2=A0re-reviewed it, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>however=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > https= ://reviews=2Efreebsd=2Eorg/D12692 >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > This = adds some crypto code needed for GELI=2E=C2=A0=C2=A0It >> > > simply >> > > =C2=A0=C2=A0=C2=A0=C2=A0adds new >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>code, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > and d= oesn't conflict with anything=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > https= ://reviews=2Efreebsd=2Eorg/D12698 >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > This = adds the EFI KMS interface code, and has >> > > the EFI >> > > =C2=A0=C2=A0=C2=A0=C2=A0loader pass >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>keys >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > into = the keybuf interface=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > I can= 't post the main GELI driver until those >> > > get >> > > =C2=A0=C2=A0=C2=A0=C2=A0merged, as it >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>depends >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > on th= em=2E=C2=A0=C2=A0It can be found on the geli branch on >> > > my >> > > =C2=A0=C2=A0=C2=A0=C2=A0github freebsd >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > repos= itory, however=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > Addit= ionally, you need this patch, which allows >> > > =C2=A0=C2=A0=C2=A0=C2=A0loader=2Eefi to >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>function >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > when = installed directly to the ESP: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > https= ://reviews=2Efreebsd=2Eorg/D13497 >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > On 02= /20/2018 22:56, Tommi Pernila wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> Hi E= ric, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> coul= d you provide a brief update how the work >> > > is going? >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> Br, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> Tomm= i >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> On N= ov 16, 2017 04:29, "Eric McCorkle" >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > et>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> > > > =C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0wrote: >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Right, so basically, the remaining GELI >> > > patches >> > > =C2=A0=C2=A0=C2=A0=C2=A0are against >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> loader,= and >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0most of them can go in independently of the >> > > work >> > > =C2=A0=C2=A0=C2=A0=C2=A0on removing >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>boot1=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0There's a unanimous consensus on getting >> > > rid of >> > > =C2=A0=C2=A0=C2=A0=C2=A0boot1 which >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> include= s its >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0original author, so that's going to happen=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0For GELI, we have the following (not >> > > necessarily >> > > =C2=A0=C2=A0=C2=A0=C2=A0in order): >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0a) Adding the KMS interfaces, pseudo- >> > > device, and >> > > =C2=A0=C2=A0=C2=A0=C2=A0kernel >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>keybuf >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0interactions >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0b) Modifications to the efipart driver >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0c) boot crypto >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0d) GELI partition types (not strictly >> > > necessary) >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Then there's the GELI driver itself=2E=C2=A0=C2= =A0(a) >> > > and (c) >> > are >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0good to >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> land, (= b) >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0needs some more work after Toomas Soome >> > > pointed >> > out a >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>legitimate >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0problem, and (d) actually needs a good bit >> > > more >> > > =C2=A0=C2=A0=C2=A0=C2=A0code (but >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>again, >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> it's >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0more cosmetic)=2E=C2=A0=C2=A0Additionally, the G= ELI >> > > driver >> > > =C2=A0=C2=A0=C2=A0=C2=A0will need >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>further >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> mods to >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0efipart to be written (nothing too >> > > big)=2E=C2=A0=C2=A0But we >> > > =C2=A0=C2=A0=C2=A0=C2=A0could go >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>ahead >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> with (a= ) >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0and (c), as they've already been proven to >> > > work=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0I'd wanted to have this stuff shaped up >> > > sooner, >> > > =C2=A0=C2=A0=C2=A0=C2=A0but I'm >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> preoccu= pied with >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0the 7th RISC-V workshop at the end of the >> > > month=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Once this stuff is all in, loader should >> > > handle >> > > =C2=A0=C2=A0=C2=A0=C2=A0any GELI >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>volumes it >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0finds, and it should Just Work once boot1 >> > > is gone=2E >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > _____= __________________________________________ >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > freeb= sd-current@freebsd=2Eorg >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> mai= ling list >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > https= ://lists=2Efreebsd=2Eorg/mailman/listinfo/freeb >> > > sd- >> > current >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > rent >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > To un= subscribe, send any mail to >> > "freebsd-current-unsubscribe@ >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> freebsd= =2Eorg >> > > " >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> > >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> -- >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Sent from = my Android device with K-9 Mail=2E Please >> > > excuse my >> > brevity=2E >> > >=20 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> __________= _____________________________________ >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> freebsd-cu= rrent@freebsd=2Eorg >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0mailing list >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> https://li= sts=2Efreebsd=2Eorg/mailman/listinfo/freebsd-cu >> > > rrent >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > rent >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> To unsubsc= ribe, send any mail to >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"freebsd-cur= rent-unsubscribe@freebsd=2Eorg >> > > =C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0>" >> > > =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > > =C2=A0=C2=A0=C2=A0=C2=A0> >> > >=20 >> > >=20 >> >=20 >> _______________________________________________ >> 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 Sun Jul 8 23:10:30 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 41B611041591 for ; Sun, 8 Jul 2018 23:10:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 BDC2B71AE8 for ; Sun, 8 Jul 2018 23:10:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8AWWRPcVM1lMSv62SsvJhEF4tYIHwWLqcOUr1Zdx48x3bl_qHs8Fbr3Zx4VVTQb mp1AfWKCbkOQc897NwR4Fc6wZg.lNTWKnUTmSe5wqQHRZgpKozZ4nZGxuZZK1Lzv6gVSi.wrOtwi Hlws2ScJzs1vTTnAlJygxfnJBM0p5Mdujm44RgRwk39EIlJgEqPCxG74e2XXtWQRxy1z06A53.r7 8oMm49iR1OJTFbstrrg_SavUjiS.fRb7.34God8DKmxffuBpfz40d2I5SAMliJrj1xntwVY6XZ_S pfYTX.wtETIyo_72iu5TDymHyOLWNt.VlobtM_50PTHqZnqXA8t.292Xc5jZRizqi5NcJZKJqr_k NWpM6UU3u9DZC9wxtfA5qO9W8uZm27sW0S6m3BiDYZh9A392ocIQWZYNjYBhg5dbgM4gWLfrh6UF tQ30MV861hQceS2OKoyzK1SYNNUJuNkNaApuETH7r1TUUxfma1GMeheT0Fe2U9zwn8fwJg0mJesW DCA23yrJDsmWfbDZqZ9FHAMv7uZVE61Gu___70dFGQ667ycsHfW0FwuaEvr0PZRzqrjUW26VfYMe F16uLUauPg9ss75c5NQkyXlDPB7_QaUjeVUw0mFv731Me.BV5d2bbgXMVuNgFM6ee3_o8N_3baZY xaYbsBlmMXzYYf7pm8HhwHV7pUPKr5MkEDqZqYNZgJeLpmePOueYkULLhznLe9.LMslrddfD763y u6LDYjqD6afPKm9ScVB3fClw.tKIn1HXlWSpsvM6LcfLw0Xk3eCNJ5_P87EDS436fIyjlTparhnm Ot4NXxNfbPmqNyf_ILUUCTwzWQpR4QgwgVnaYqPwuGfgzC.AQrklNDZslFPYzQxpaCEs9DEafht3 0nLcpEigAdgx.E9Fak4pkeh3wJzCBRhrddCOjcox_HCHqKmaMXIsMUAEJFFB9uiB3ukCZETEU754 T2bXu4HaAXxPWUejBJUNS751_DdRJYHCI.uhTWd.7hWibWXWc6g8JbUZ4qfsxaauTMu0Leg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Jul 2018 23:10:28 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e23d720e7c01344b787537e197b6fb72; Sun, 08 Jul 2018 22:50: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.4 \(3445.8.2\)) Subject: -r336099 and later: broke ci.freebsd.prg's FreeBSD-head-amd64-build Message-Id: <6EA9A549-7508-467C-BED2-AF0C136C752D@yahoo.com> Date: Sun, 8 Jul 2018 15:50:09 -0700 To: Warner Losh , FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 23:10:30 -0000 https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9386/consoleText = shows: =3D=3D=3D> zlib (install) install -T release -o root -g wheel -m 555 zlib.ko = /usr/obj/usr/src/amd64.amd64/release/dist/kernel/boot/kernel/ install -T debug -o root -g wheel -m 555 zlib.ko.debug = /usr/obj/usr/src/amd64.amd64/release/dist/kernel/usr/lib/debug/boot/kernel= / kldxref /usr/obj/usr/src/amd64.amd64/release/dist/kernel/boot/kernel kldxref: Parse error of description string U16:vendor; U16:device *** Error code 1 Stop. make[4]: stopped in /usr/src/sys/modules Note the "U16:vendor; U16:device" reference and such text in the below (and other check-ins after it). . . Author: imp Date: Sun Jul 8 20:39:38 2018 New Revision: 336099 URL:=20 https://svnweb.freebsd.org/changeset/base/336099 Log: Add PNP info to PCI attachment of ena driver . . . Modified: head/sys/dev/ena/ena.c head/sys/dev/ena/ena.h Modified: head/sys/dev/ena/ena.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/ena/ena.c Sun Jul 8 20:39:23 2018 = (r336098) +++ head/sys/dev/ena/ena.c Sun Jul 8 20:39:38 2018 = (r336099) @@ -3947,6 +3947,8 @@ static driver_t ena_driver =3D { =20 devclass_t ena_devclass; DRIVER_MODULE(ena, pci, ena_driver, ena_devclass, 0, 0); +MODULE_PNP_INFO("U16:vendor; U16:device", pci, ena, = ena_vendor_info_array, + sizeof(ena_vendor_info_array[0]), nitems(ena_vendor_info_array) - = 1); MODULE_DEPEND(ena, pci, 1, 1, 1); MODULE_DEPEND(ena, ether, 1, 1, 1); . . . =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 Jul 8 23:13: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 F32F61041B94 for ; Sun, 8 Jul 2018 23:13:12 +0000 (UTC) (envelope-from wlosh@bsdimp.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 9206C72074 for ; Sun, 8 Jul 2018 23:13:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id q19-v6so15442631ioh.11 for ; Sun, 08 Jul 2018 16:13:12 -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=2RX1Lzcbr7wA3pWz0XncdmwK5+lARUSbZdgquy74hGY=; b=RbIlCEjG1iAm/DzipFGNjI/VXZplmW/nNGXrcBgNe1Z9nooA7VBj4XR+MLnJ+9qInW IvibGKXWfdbeZX2IvQcA2f49LzRKJUaCl8yqJ8p5Yl1Tc3SafmGTMcDNvWbVhnS4hevb 0e3tj0nhRxgnOsRT/XikLGhbxTbPLJ8ZvtYUvXJtYUKzl6NvUIxOLDXFEyWSVjy8WSXt BEyUArQE7+trlh6oAr4sEig0S1gUHDEVIeY3p5/Ths3TevNOfz7zY01A4VNfQI79S1MC UQXW/N6awJiV+7tpFwMWzzHljnMzVuTZ+Cv3YjqwQ5sh9SS9Z1qKNXcz+mRrDVe2/ati 8+4Q== 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=2RX1Lzcbr7wA3pWz0XncdmwK5+lARUSbZdgquy74hGY=; b=mSKzwoZQaBW0x2x5JXxhjXz416PAnw6paCdeoVo9IIZi4cPxYzi2MKRQBvqwESOShm RVhIIEcyr/fJIcX3e+R266aSLIq7azt7QMGNfPMCM85Dt3TRSyCFc1XMsbLvK/Rc37J7 2S5cNoDkk0LoC9IqyBe6VWWfWkRMlhQjKEjiWJEi4uP9eqd6AffP+wYBx4+trnfOkb4u f57ahCqLhR7nnKUaTE0LZ2ujJ4pbEtW+4+BZRpUZybKXrEj1OwQRk2D0ZrEO0uVzfJsP Lo4MbyOYpbHJ2dJY54TRhxSd1J2UytaKgMeUqV8JgZ2otdLEOS3PdphQ4Qz3cmncUUf7 pS5g== X-Gm-Message-State: APt69E2KKyRHamMQFcGET2urtwCS4DdIK3ihHUXsPJC6UQ9qJlvOqfeD 2fvoEWv1Ou2BrQDIADXJBKg3XzS5f+D1s7Mv7YZjmg== X-Google-Smtp-Source: AAOMgpea1AYyeyOOpJ+Ly16NqrcOIGLnFqZY98R1LxgWb0k3A9/PcXl/q4gsb/vKFj7Ckm66E9cjZIW8tuPhNmJ157E= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr14910023ioa.299.1531091591616; Sun, 08 Jul 2018 16:13:11 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:1183:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 16:13:11 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <6EA9A549-7508-467C-BED2-AF0C136C752D@yahoo.com> References: <6EA9A549-7508-467C-BED2-AF0C136C752D@yahoo.com> From: Warner Losh Date: Sun, 8 Jul 2018 17:13:11 -0600 X-Google-Sender-Auth: 5MkCQyWNXFL1Z03IhFq7TkM1_Zc Message-ID: Subject: Re: -r336099 and later: broke ci.freebsd.prg's FreeBSD-head-amd64-build To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 08 Jul 2018 23:13:13 -0000 Yea, there's a stray space in that string. r336114 should fix that. Warner On Sun, Jul 8, 2018 at 4:50 PM, Mark Millard wrote: > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9386/consoleText > shows: > > ===> zlib (install) > install -T release -o root -g wheel -m 555 zlib.ko > /usr/obj/usr/src/amd64.amd64/release/dist/kernel/boot/kernel/ > install -T debug -o root -g wheel -m 555 zlib.ko.debug > /usr/obj/usr/src/amd64.amd64/release/dist/kernel/usr/lib/ > debug/boot/kernel/ > kldxref /usr/obj/usr/src/amd64.amd64/release/dist/kernel/boot/kernel > kldxref: Parse error of description string U16:vendor; U16:device > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/sys/modules > > > Note the "U16:vendor; U16:device" reference and such text in > the below (and other check-ins after it). . . > > > Author: imp > Date: Sun Jul 8 20:39:38 2018 > New Revision: 336099 > URL: > https://svnweb.freebsd.org/changeset/base/336099 > > > Log: > Add PNP info to PCI attachment of ena driver > . . . > > Modified: > head/sys/dev/ena/ena.c > head/sys/dev/ena/ena.h > > Modified: head/sys/dev/ena/ena.c > ============================================================ > ================== > --- head/sys/dev/ena/ena.c Sun Jul 8 20:39:23 2018 (r336098) > +++ head/sys/dev/ena/ena.c Sun Jul 8 20:39:38 2018 (r336099) > @@ -3947,6 +3947,8 @@ static driver_t ena_driver = { > > devclass_t ena_devclass; > DRIVER_MODULE(ena, pci, ena_driver, ena_devclass, 0, 0); > +MODULE_PNP_INFO("U16:vendor; U16:device", pci, ena, ena_vendor_info_array, > + sizeof(ena_vendor_info_array[0]), nitems(ena_vendor_info_array) - 1); > MODULE_DEPEND(ena, pci, 1, 1, 1); > MODULE_DEPEND(ena, ether, 1, 1, 1); > > . . . > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > From owner-freebsd-current@freebsd.org Mon Jul 9 00:11: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 EEBF21048000 for ; Mon, 9 Jul 2018 00:11:51 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 7DADF7484D for ; Mon, 9 Jul 2018 00:11:51 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id r16-v6so9125774wrt.11 for ; Sun, 08 Jul 2018 17:11:51 -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=8oOX3LhVd23cIJbzCkIohY+Zq7fReGkDye4wPjNpwm4=; b=RCJ5QsQQOjMoZYF30Z4q3wOqmZr/PtFt5npB1uzKSqHw8Axk3+Z0ATVSrjzyk9UBXe NIiXu27Zsmz2014QqVX0ZTCDxornix+iAyyqBpsOB4SS39tgmBCD6+f48KDWiRIypKhh 43ULTnq4fPIcMT5ZEUQFbgSRLAjrhsuvljz/MybG5apq9zx2TRKGPi8dvY8UISG+34lX lrbfUq3LrK36Jv6hidSmIzVBIO8/UkQCmLB/TNC42KXbxdFxHY0Bvq4fPYbcsWh94YQf xxanj1ptdeM30tJHryzGHfxkCNheOev9FEvFtiQpKQh1JcLY8JKBM4TxMIjeSp9tssTu 60zw== X-Gm-Message-State: APt69E1CEAmikP1IVmKRVD4YmMvTDzdHV7vcms0qBMO02tG4BK8qpQNB xcQ4tOBDfO6SZGkO4vsy4gKjSiizL2ExQkQaIF4= X-Google-Smtp-Source: AAOMgpfFMFSjXuZvNTAqLfvNlY5Gxvz1+WPBZq2EzltgPid/NcM5DyrqqN6v54PhZ7xO8m1VxDy02nS20czQfAd6drI= X-Received: by 2002:adf:ea0a:: with SMTP id q10-v6mr13293182wrm.224.1531094638678; Sun, 08 Jul 2018 17:03:58 -0700 (PDT) MIME-Version: 1.0 References: <76841358-DBB1-4400-9E99-9B7375245DD2@yahoo.com> In-Reply-To: <76841358-DBB1-4400-9E99-9B7375245DD2@yahoo.com> From: Li-Wen Hsu Date: Mon, 9 Jul 2018 01:03:46 +0100 Message-ID: Subject: Re: ci.freebsd.org's FreeBSD-head-i386-testvm fails for: pkg: No packages available to install matching 'scapy' have been found in the repositories To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 00:11:52 -0000 On Thu, Jul 5, 2018 at 11:51 PM Mark Millard wrote: > > https://ci.freebsd.org/job/FreeBSD-head-i386-testvm/6978/console shows: > > 22:34:39 All repositories are up to date. > 22:34:39 + sudo chroot ufs pkg install -y kyua perl5 scapy ksh93 python > 22:34:39 Updating FreeBSD repository catalogue... > 22:34:39 FreeBSD repository is up to date. > 22:34:39 All repositories are up to date. > 22:34:39 Updating database digests format: . done > 22:34:39 pkg: No packages available to install matching 'scapy' have been found in the repositories > 22:34:39 Build step 'Execute shell' marked build as failure > 22:34:39 FTP: Current build result is [FAILURE], not going to run. > > There is a: > > https://svnweb.freebsd.org/ports/head/net/scapy/ > It's not in head's pkg repository because it was skipped in last completed pkg build: http://beefy12.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p473790_s335878 (ipv6 only) The reason is libdnet did not build, which needs this: https://svnweb.freebsd.org/changeset/base/335928 The on-going pkg build will have scapy restored: http://beefy12.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p474051_s336054 Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Mon Jul 9 09:58: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 3B4C41038DC2 for ; Mon, 9 Jul 2018 09:58:20 +0000 (UTC) (envelope-from tobik@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 CDEA38ED39 for ; Mon, 9 Jul 2018 09:58:19 +0000 (UTC) (envelope-from tobik@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 47F7121B6F for ; Mon, 9 Jul 2018 05:58:19 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 09 Jul 2018 05:58:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=8KXAgTyUuoH4amwhVHz1TveJrgl7e PA6Ipb/Oy/8dnk=; b=El0RrBAT38SmBXAoVQGixqW8v8Q9R1a47NX9zedOl3xVl pX+icUG7e1X4GEFRBVYQ+rlKtA+efJ7lOn/l/1eRyd/g6ehvbZhN0msN6tZWmOTI dbxHTXdNCIbcMQfUo+RyBr3L0yKNJ05aDGFWPP0BBmAT5itFIP+pyrIRd9uym4y4 tW9uTR6i2kgwXJssidqnefHxfk3biWq1J79J2JxxLby3U3EU6gbUWiQ4Ib9xPeD0 7p5laToLYa9CMYRgEGQuKhCqjKLQA6liZxzI/urge6MjiR9scbh82pLruovltyfJ qtakhp1MJMTwn5R0yIACK6l+xQuLOH4++Vh2MeS6w== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DF46994116; Mon, 9 Jul 2018 05:58:18 -0400 (EDT) Message-Id: <1531130298.3054575.1434404056.514ED8A8@webmail.messagingengine.com> From: Tobias Kortkamp To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Mon, 09 Jul 2018 11:58:18 +0200 Subject: New conflict between the FreeBSD-libnv-development and FreeBSD-runtime-development packages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 09:58:20 -0000 Hi, there's a new conflict between the FreeBSD-{libnv,runtime}-development base packages. This was for r336096 but the problem must have been introduced after r335966 as the packages from that revision were fine. Checking integrity... done (1 conflicting) - FreeBSD-libnv-development-12.0.s20180708222113 [base] conflicts with FreeBSD-runtime-development-12.0.s20180708222113 [installed] on /usr/include/sys/cnv.h From owner-freebsd-current@freebsd.org Mon Jul 9 10:55:41 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 21366103E411 for ; Mon, 9 Jul 2018 10:55:41 +0000 (UTC) (envelope-from jhs@berklix.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 A7A9D90EDC for ; Mon, 9 Jul 2018 10:55:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6849A103E410; Mon, 9 Jul 2018 10:55:40 +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 556B0103E40F for ; Mon, 9 Jul 2018 10:55:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C06A990EDA for ; Mon, 9 Jul 2018 10:55:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (pD9FA8EA3.dip0.t-ipconnect.de [217.250.142.163]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w699oEpi068130 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jul 2018 09:50:18 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w699oDr8047896 for ; Mon, 9 Jul 2018 11:50:14 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w699o1jF022468 for ; Mon, 9 Jul 2018 11:50:13 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201807090950.w699o1jF022468@fire.js.berklix.net> To: current@freebsd.org Subject: sys/Makefile .if defined(MODULES_WITH_WORLD) From: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Mon, 09 Jul 2018 11:50:01 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 10:55:41 -0000 Hi current@ src/sys/dev/amdsbwd/amdsbwd.c broke src/sys/modules Is it immediately intuitive & well known to developers working in sys/dev to enable MODULES_WITH_WORLD before a test make all before a commit ? Or what should we do to increase the liklehood of commiters catching modules/ errors before a commit ? With src/ .ctm_status src-cur 13573 .svn_revision 335362 sys/Makefile has .if defined(MODULES_WITH_WORLD) SUBDIR+=modules & nothing from cd /usr/src; find . -name \*src.conf\* & no default /etc/src.conf with no MODULES_WITH_WORLD=YES so make all does not build /sys/modules/ so this not seen from /sys/modules/ ===> amdsbwd (all) cc -O2 -pipe -DBERKLIX=YES -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/data/release/s1/usr/src/sys -I/data/release/s1/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.amdsbwd.o -MTamdsbwd.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c -o amdsbwd.o /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c:52:10: fatal error: 'opt_amdsbwd.h' file not found #include "opt_amdsbwd.h" PS With .ctm_status src-cur 13601 .svn_revision 336117 nothing from find . -name opt_amdsbwd.h but this has src/sys/dev/amdsbwd/amdsbwd.c #include "opt_amdsbwd.h" I haven't yet upgraded my src/ yet to see if it still fails. Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich Brexit Referendum stole 3.7 million votes inc. from 700,000 British in EU. UK Goverment lies it's democratic in Article 50 paragraph 3 of letter to EU. http://berklix.eu/queen/ https://www.peoples-vote.uk 193,000 @ 8 Jul 2018 From owner-freebsd-current@freebsd.org Mon Jul 9 11:54: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 4053C1043309 for ; Mon, 9 Jul 2018 11:54:49 +0000 (UTC) (envelope-from jhs@berklix.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 D1E0F93818 for ; Mon, 9 Jul 2018 11:54:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8F1781043304; Mon, 9 Jul 2018 11:54:48 +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 6C8D910432FE for ; Mon, 9 Jul 2018 11:54:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 00C0893816 for ; Mon, 9 Jul 2018 11:54:47 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (pD9FA8EA3.dip0.t-ipconnect.de [217.250.142.163]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w69BsWDY072446 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2018 11:54:46 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w69BsVR4048771; Mon, 9 Jul 2018 13:54:32 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w69Bs7Ha024391; Mon, 9 Jul 2018 13:54:31 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201807091154.w69Bs7Ha024391@fire.js.berklix.net> To: current@freebsd.org cc: "Julian H. Stacey" Subject: How to add su to /rescue ? From: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Mon, 09 Jul 2018 13:54:07 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 11:54:49 -0000 Hi current@ I want to add su to /rescue, but got stuck on pam. Old unix su didn't suffer from pam. There's no #define in su to turn off pam. Man src.conf says WITHOUT_PAM is deprecated & does nothing. Can someone please offer a solution ? Or better to include a simple BSD su pre pam ? I would happily develop a patch for that. Notes to explain the need, & patches from my http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/rescue/ --------- Patch[es] below to solve this emailed scenario: > Please on prison-host cp /lib/libc.so.7 /tank/ezjail/my-domain/lib/libc.so.7 > I am logged in on jail-host, but only as normal-user, not root, so I cannot run > /rescue/cp /usr/obj/usr/src/lib/libc/libc.so.7 /lib/libc.so.7 > > a my make installworld on jail-host.my-domain previously failed with > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > install: /lib/libc.so.7: chflags: Operation not permitted > *** Error code 71 > (might or not be an artifact of being in a jail) > > unfortunately I had run the command as > xs make installworld > (xs is my own little root wrapper) > so when it exited, I was just normal-user not root, & I had forgotten to > open another xterm & leave it logged in as root, > & I found no /rescue/su *** 12.0-CURRENT/usr/src/rescue/rescue/Makefile.orig Tue Jun 19 14:43:47 2018 --- new-generic/usr/src/rescue/rescue/Makefile Mon Jul 9 12:21:47 2018 *************** *** 188,193 **** --- 188,195 ---- CRUNCH_PROGS_usr.bin+= less CRUNCH_ALIAS_less= more + CRUNCH_PROGS_usr.bin+= su + CRUNCH_PROGS_usr.bin+= xz CRUNCH_ALIAS_xz= unxz lzma unlzma xzcat lzcat ----- Patch above fails with: cc -O2 -pipe -DBERKLIX=YES -std=gnu99 -Qunused-arguments -static -o reue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo. ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv. pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo st.lo sync.lo test.lo csh.lo camcontrol.lo clri.lo devfs.lo dmesg.lo dump.lo dums.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo om.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldcoig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdos.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfssdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo savecore.lshutdown.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ccdconfig.lping6.lo rtsol.lo ipf.lo routed.lo rtquery.lo zfs.lo zpool.lo bsdlabel.lo fdislo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo ! gzip.lo bzip2.lo less.lo suo xz.lo zstd.lo tar.lo nc.lo vi.lo id.lo iscsictl.lo zdb.lo chroot.lo chown.loscsid.lo /data/release/s1/usr/obj/data/release/s1/usr/src/amd64.amd64/rescue/rcue/../librescue/exec.o /data/release/s1/usr/obj/data/release/s1/usr/src/amd64md64/rescue/rescue/../librescue/getusershell.o /data/release/s1/usr/obj/data/rease/s1/usr/src/amd64.amd64/rescue/rescue/../librescue/login_class.o /data/relse/s1/usr/obj/data/release/s1/usr/src/amd64.amd64/rescue/rescue/../librescue/pen.o /data/release/s1/usr/obj/data/release/s1/usr/src/amd64.amd64/rescue/rescu../librescue/rcmdsh.o /data/release/s1/usr/obj/data/release/s1/usr/src/amd64.a64/rescue/rescue/../librescue/sysctl.o /data/release/s1/usr/obj/data/release/susr/src/amd64.amd64/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail kvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias -lcam -lncursesw -ldevsta-lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair -lpthread -luutil -lume-lgeom -lbsdxml -lkiconv ! -lmt -lsbuf -lufs -lz -lbz2 -lprivatezstd -larchive -rypto -lmd -lm /usr/bin/ld: error: undefined symbol: pam_start >>> referenced by su.lo:(_$$hide$$ su.lo main) /usr/bin/ld: error: undefined symbol: pam_set_item >>> referenced by su.lo:(_$$hide$$ su.lo main) Patch below does not solve problem above *** 12.0-CURRENT/usr/src/rescue/librescue/Makefile.orig Mon Jul 9 13:02:43 2018 --- new-generic/usr/src/rescue/librescue/Makefile Mon Jul 9 13:03:59 2018 *************** *** 16,21 **** --- 16,22 ---- .PATH: ${SRCTOP}/lib/libc/gen \ ${SRCTOP}/lib/libc/net \ ${SRCTOP}/lib/libc/stdlib \ + ${SRCTOP}/lib/libpam/libpam \ ${SRCTOP}/lib/libutil LIB= rescue --- changing libpam/libpam to libpam also fails. ------- Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich Brexit Referendum stole 3.7 million votes inc. from 700,000 British in EU. UK Goverment lies it's democratic in Article 50 paragraph 3 of letter to EU. http://berklix.eu/queen/ https://www.peoples-vote.uk 200,000 @ 9 Jul 2018 From owner-freebsd-current@freebsd.org Mon Jul 9 13:06: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 4FBD110245F6 for ; Mon, 9 Jul 2018 13:06:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F260A96817; Mon, 9 Jul 2018 13:06:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8DBAFADF5; Mon, 9 Jul 2018 13:06:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f45.google.com with SMTP id i15-v6so15171755lfc.2; Mon, 09 Jul 2018 06:06:26 -0700 (PDT) X-Gm-Message-State: APt69E0JzWmhFzbfs858NtXma2DdOcURcuUaBWuXEfKT1JJwm6nB5Ptn TJElvXhNkWEHSEe6UHXcLGRuH0QWxEQui0UIrmw= X-Google-Smtp-Source: AAOMgpeRG8O5t0mXXH//1Ksuyou640wlIu9o4LFfCOwdetjM6rfgqgmfRIMhNfyh0fq7qpycNlfwbOY8NmBpWwwQIP4= X-Received: by 2002:a19:9481:: with SMTP id o1-v6mr14852549lfk.38.1531141585064; Mon, 09 Jul 2018 06:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 06:06:04 -0700 (PDT) In-Reply-To: <1531130298.3054575.1434404056.514ED8A8@webmail.messagingengine.com> References: <1531130298.3054575.1434404056.514ED8A8@webmail.messagingengine.com> From: Kyle Evans Date: Mon, 9 Jul 2018 08:06:04 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: New conflict between the FreeBSD-libnv-development and FreeBSD-runtime-development packages To: Tobias Kortkamp Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 13:06:27 -0000 On Mon, Jul 9, 2018 at 4:58 AM, Tobias Kortkamp wrote: > Hi, > > there's a new conflict between the FreeBSD-{libnv,runtime}-development > base packages. This was for r336096 but the problem must have been > introduced after r335966 as the packages from that revision were > fine. > > Checking integrity... done (1 conflicting) > - FreeBSD-libnv-development-12.0.s20180708222113 [base] conflicts > with FreeBSD-runtime-development-12.0.s20180708222113 [installed] > on /usr/include/sys/cnv.h > Hi, Indeed- there's a patch in flight that will alleviate this that will hopefully land later today. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Mon Jul 9 14:19: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 7FB71102A246 for ; Mon, 9 Jul 2018 14:19:19 +0000 (UTC) (envelope-from ian@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 162AB71A6A for ; Mon, 9 Jul 2018 14:19:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CA37F102A21A; Mon, 9 Jul 2018 14:19: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 B6125102A219 for ; Mon, 9 Jul 2018 14:19:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 39EF171A69 for ; Mon, 9 Jul 2018 14:19:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 0a729390-8383-11e8-b829-b3adae557cda X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 0a729390-8383-11e8-b829-b3adae557cda; Mon, 09 Jul 2018 14:19:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w69EJ5uM033553; Mon, 9 Jul 2018 08:19:07 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531145945.1336.23.camel@freebsd.org> Subject: Re: sys/Makefile .if defined(MODULES_WITH_WORLD) From: Ian Lepore To: "Julian H. Stacey" , current@freebsd.org Date: Mon, 09 Jul 2018 08:19:05 -0600 In-Reply-To: <201807090950.w699o1jF022468@fire.js.berklix.net> References: <201807090950.w699o1jF022468@fire.js.berklix.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 14:19:19 -0000 On Mon, 2018-07-09 at 11:50 +0200, Julian H. Stacey wrote: > Hi current@ > src/sys/dev/amdsbwd/amdsbwd.c broke src/sys/modules > > Is it immediately intuitive & well known to developers working in > sys/dev > to enable MODULES_WITH_WORLD before a test make all before a commit ? > > Or what should we do to increase the liklehood of commiters catching > modules/ errors before a commit ? > > With src/ > .ctm_status src-cur 13573 > .svn_revision 335362 > sys/Makefile has > .if defined(MODULES_WITH_WORLD) > SUBDIR+=modules > & nothing from cd /usr/src; find . -name \*src.conf\* > & no default /etc/src.conf with no > MODULES_WITH_WORLD=YES > so make all does not build /sys/modules/  > so this not seen from /sys/modules/ > ===> amdsbwd (all) > cc  -O2 -pipe -DBERKLIX=YES  -fno-strict-aliasing -Werror -D_KERNEL > -DKLD_MODULE -nostdinc   -I. -I/data/release/s1/usr/src/sys > -I/data/release/s1/usr/src/sys/contrib/ck/include -fno-common  -fno- > omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  - > MF.depend.amdsbwd.o -MTamdsbwd.o -mcmodel=kernel -mno-red-zone -mno- > mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables > -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer- > arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error- > tautological-compare -Wno-error-empty-body -Wno-error-parentheses- > equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno- > error-shift-negative-value -Wno-address-of-packed-member  -mno-aes > -mno-avx  -std=iso9899:1999 -c > /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c -o amdsbwd.o > /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c:52:10: fatal > error:  >       'opt_amdsbwd.h' file not found > #include "opt_amdsbwd.h" > > > PS With  > .ctm_status src-cur 13601 > .svn_revision 336117 > nothing from > find . -name opt_amdsbwd.h > but this has > src/sys/dev/amdsbwd/amdsbwd.c > #include "opt_amdsbwd.h" > I haven't yet upgraded my src/ yet to see if it still fails. > > Cheers, > Julian Should be fixed in r336134. -- Ian From owner-freebsd-current@freebsd.org Mon Jul 9 16:28: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 597BB1037622 for ; Mon, 9 Jul 2018 16:28:55 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0280177B53; Mon, 9 Jul 2018 16:28:55 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from Ticonderoga.HML3.ScaleEngine.net (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: allanjude) by smtp.freebsd.org (Postfix) with ESMTPSA id AB5F0C242; Mon, 9 Jul 2018 16:28:54 +0000 (UTC) (envelope-from allanjude@freebsd.org) Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Ian Lepore , Oliver Pinter , Eric McCorkle Cc: Warner Losh , Tommi Pernila , freebsd-current , Warner Losh References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> <1531078307.1336.22.camel@freebsd.org> From: Allan Jude Message-ID: <06cb8190-7a04-5c92-8fb9-637d1a80758f@freebsd.org> Date: Mon, 9 Jul 2018 12:28:33 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1531078307.1336.22.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 16:28:55 -0000 I will look at updating the rootgen.sh script this evening, to support creating more flexible ESP partitions, so we can drop the loader.efi into an msdosfs directly. On 07/08/2018 15:31, Ian Lepore wrote: > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote: >> Hi! >> >> Have you or Warner any update on this code? >> >> On Thursday, April 12, 2018, Eric McCorkle >> wrote: >> > > Are you aware of https://reviews.freebsd.org/D15743 ? > > That's my changes to add geli support to loader(8) in an architecture- > agnostic way, so that "it just works" for all platforms and flavors of > loader. It has been succesfully tested on armv6/7 (ubldr) and on x86 > using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The > only variations that aren't tested yet are the uefi flavors, because > the current rootgen.sh script for assembling test images is still using > boot1.efi and I don't know enough about efi myself to update the script > to make it assemble images the new way Warner envisions. > > -- Ian > >>> >>> I'm in the middle of moving to a new apartment right now.  It's >>> going to >>> be a bit before I can get to this. >>> >>> On 04/11/2018 20:31, Warner Losh wrote: >>>> >>>> OK. I've pushed in the main part of it. The additional work I >>>> have >>>> shouldn't affect any of this stuff.  I was going to look at what >>>> part(s) >>>> of your open reviewed needed to be redone tomorrow and send you >>>> feedback, but if you wanted to get a start before then, I'm happy >>>> to >>>> answer questions. All the rest of my work is going to be >>>> selecting the >>>> root partition when we're told to us a specific partition, so >>>> will be >>>> very constrained. >>>> >>>> Warner >>>> >>>> On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle >>> net >>>> > wrote: >>>> >>>>     I think the thing to do at this point is to wait for the >>>> current >>> work on >>>> >>>>     loader.efi to land, then adapt my patches to apply against >>>> that work. >>>> >>>>     On 04/11/2018 15:06, Warner Losh wrote: >>>>     > Still reviewing the code. I'm worried it's too i386 >>>> specific and it >>>>     > conflicts with some work I'm doing. I'll have a list of >>>> actionable >>>>     > critiques this week. >>>>     > >>>>     > Warner >>>>     > >>>>     > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter >>>>     > >>>      >>>>     >>>     >> >>>>     > wrote: >>>>     > >>>>     >     Hi! >>>>     > >>>>     >     Is there any update regarding the rebase or the >>>> inclusion to >>> base >>>> >>>>     >     system? >>>>     >     On 3/28/18, Eric McCorkle >>> >> eric@metricspace.net> >>>> >>>>     >     >>> et>>> >>> wrote: >>>> >>>>     >     > I'll do another rebase from head just to be sure >>>>     >     > >>>>     >     > On March 28, 2018 3:23:23 PM EDT, Warner Losh < >>> imp@bsdimp.com >>>> >>>>     >     >> 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" < >>> tommi.pernila@iki.fi >>>> >>>>     >     >>> fi>>> >>> 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 < >>> eric@metricspace.net >>>> >>>>     >     >>> et>>> >>>>     >     >>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" >>>>      >>>>     >     >>> et>> >>>>     >     >>>> >> >>>      >>>     >>> >>>>     >     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/freeb >>>> sd- >>> current >>>> >>>>      >>>>     >     >>> rent >>>>     > >>>>     >     >>>> > To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@ >>>> >>>>     >     >>>> freebsd.org >>>> " >>>>     >     >>>> > >>>>     >     >>>> >>>>     >     >>> >>>>     >     > >>>>     >     > -- >>>>     >     > Sent from my Android device with K-9 Mail. Please >>>> excuse my >>> brevity. >>>> >>>>     >     > _______________________________________________ >>>>     >     > freebsd-current@freebsd.org >>>>      >>>>     >>>     > >>>>     >     mailing list >>>>     >     > https://lists.freebsd.org/mailman/listinfo/freebsd-cu >>>> rrent >>>>      >>>>     >     >>> rent >>>>     > >>>>     >     > 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" -- Allan Jude From owner-freebsd-current@freebsd.org Mon Jul 9 19:13: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 C0613104808B for ; Mon, 9 Jul 2018 19:13:43 +0000 (UTC) (envelope-from guy.helmer@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 562EC80526 for ; Mon, 9 Jul 2018 19:13:43 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 151681048085; Mon, 9 Jul 2018 19:13:43 +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 E1B661048084 for ; Mon, 9 Jul 2018 19:13:42 +0000 (UTC) (envelope-from guy.helmer@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 6CFE180522 for ; Mon, 9 Jul 2018 19:13:42 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: by mail-io0-x229.google.com with SMTP id i18-v6so2316802ioj.13 for ; Mon, 09 Jul 2018 12:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x8YFbBe2vg8OUiAegsQir+NJcUuWvn0FTI6ZGVdIoF4=; b=AnfEx7oieUhL9GBJdv+Xlij9VdYmKJ3Q9VlS58syEZ0ZuECiUumfuChi0l9OHnZ/D4 3sqdAR3E9/9xNJ95yf9GNKzRX+kW2cq7qLnSLfX7GxVFoGDzYIaha1OLGsDsAnwQKwt2 wJAj2oS5TLDvtdrj8frrE1Izfe4lGnErMXsD7ZFPKZ8wJZvfp4OrcelPJ+cIp+ywMEe4 /H1HPUsxTxAdnyqjwmBAbaubnc/DDJMNkxcozX/7eVmTaR8o0VlviGzj22iTfdAKrI4i crsGTApyUeaL1e/+DN7QOlykKO6UkJkB9Cri7hTg23IgFQbKVILMuZTo7XRh6iSnjV6x LyIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x8YFbBe2vg8OUiAegsQir+NJcUuWvn0FTI6ZGVdIoF4=; b=Obv0DPgIJWzUy35zEk4ch3ihOguiTl2hYQ3PkJVsSQijjfvJ5h1f0Wk5rq2Wk/p+41 LY981up+Tm95xmoy8KWtZU6ad/+T+vPOg38/8cXCuEeJe3cSTx0Hzf5MWVYUC4VTNd8n 4HD1Hig9eF0eVhQ4OLIBNw9VKno1mPVTbT4/zzKXI1lWf9gwZI9gzlj/stB6A9yC9FPA gInkmhUstk5Y9oqKJkItMHU7Who+RHpJ7gku4ecviTEqaX5J9u8aAUpwdvlpKgw2IOI5 BWytRxirY86CoaFUhnGf4h838OcXTVe/j5Xq+cNuDKBJP/5XVkxgo0mALJUgKFvtX7I4 aDBQ== X-Gm-Message-State: AOUpUlEZWqC0n9hQJsEoIuhQpec/4Q/T+8pteMSQiPnYtfRewrbg8MuA aJ/Ga5KWV+FdE6Adv3/XQkSgdknZ X-Google-Smtp-Source: AAOMgpeQ9Pm9UL19FlwUy/LlGinY8tkxidfOoqyUUUHlimioG9TmdnSqqSW2RlKhtK/YopaeEwyQrA== X-Received: by 2002:a6b:1741:: with SMTP id 62-v6mr16456522iox.1.1531163621799; Mon, 09 Jul 2018 12:13:41 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by smtp.gmail.com with ESMTPSA id l26-v6sm605724ioh.27.2018.07.09.12.13.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 12:13:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: How to add su to /rescue ? From: Guy Helmer In-Reply-To: <201807091154.w69Bs7Ha024391@fire.js.berklix.net> Date: Mon, 9 Jul 2018 14:13:40 -0500 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2ACD0DE9-3C43-48DE-BD5A-E074E1A4740E@gmail.com> References: <201807091154.w69Bs7Ha024391@fire.js.berklix.net> To: "Julian H. Stacey" X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Mon, 09 Jul 2018 20:36:33 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 19:13:44 -0000 > On Jul 9, 2018, at 6:54 AM, Julian H. Stacey wrote: >=20 > Hi current@ > I want to add su to /rescue, but got stuck on pam. > Old unix su didn't suffer from pam. > There's no #define in su to turn off pam. > Man src.conf says WITHOUT_PAM is deprecated & does nothing. >=20 > Can someone please offer a solution ? > Or better to include a simple BSD su pre pam ? > I would happily develop a patch for that. Hi, Aside from not being able to use pam from a static executable, please = don=E2=80=99t try to make the crunched hard-linked executable in /rescue = setuid-root (su is useless without it). That would mean anyone running = /rescue/sh gets a root shell :-) Conceptually, a separate crunchgen binary could be made for setuid-root = purposes, but having a setuid-root binary in /rescue (outside of the = normal hierarchy) makes me nervous. Regards, Guy=20 >=20 > Notes to explain the need, & patches from my > http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/rescue/ > --------- >=20 > Patch[es] below to solve this emailed scenario: >> Please on prison-host cp /lib/libc.so.7 = /tank/ezjail/my-domain/lib/libc.so.7 >> I am logged in on jail-host, but only as normal-user, not root, so I = cannot run >> /rescue/cp /usr/obj/usr/src/lib/libc/libc.so.7 /lib/libc.so.7 >>=20 >> a my make installworld on jail-host.my-domain previously failed with >> =3D=3D=3D> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> install: /lib/libc.so.7: chflags: Operation not permitted >> *** Error code 71 >> (might or not be an artifact of being in a jail) >>=20 >> unfortunately I had run the command as >> xs make installworld >> (xs is my own little root wrapper) >> so when it exited, I was just normal-user not root, & I had forgotten = to >> open another xterm & leave it logged in as root, >> & I found no /rescue/su >=20 From owner-freebsd-current@freebsd.org Mon Jul 9 22:05: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 49CF01035ECB for ; Mon, 9 Jul 2018 22:05:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 C34338A3D9 for ; Mon, 9 Jul 2018 22:05:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id g4-v6so11596334iti.1 for ; Mon, 09 Jul 2018 15:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uIgercgav3VE7yA/uyyEWYm59CaiMV+WCiMoaj4UWLM=; b=N1fIV69KWbAdMxKpxwcsIYoynjusL2snNBzNVGorVFjqUn5nhIOtGM3EHAL6KA6tCJ tdaQIGzEhD1HpYRuNsiNkhyxPpwq3ztnWIf8kZL00FajrCp+IxlAmQ3zz6bc5omAGUoY 03Xo4k+MQPX/rCGZNz1Xa67h/afZWAN6HUUIHbI73xH2U0sz5bJRc8C5tmYOU2qpgs/d shMpCEDhSjaTZhC3E66fPg1o9JHDEYHptpB5oG0ZjwOac8j9AughCYfJwJZBOWoGtoVR Ic4uqHUB6EODQxiyMh9t0Hx0a4paM9abyUWvRUji8J5kibCm+8pcTd7ztfeK605LM1cG +LZA== 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=uIgercgav3VE7yA/uyyEWYm59CaiMV+WCiMoaj4UWLM=; b=qWmZnA0nYT0oZ0zhkrx3lkpU48smeNpWjBdEMjHIB0eb9jb1hrFWaLu0eNuM/LBDBQ Z9axwfZ8FKoV7/Y7qbOenlfsN7u2RuVvj4MAV0eUSxIdAigxWOq3Q8B1lIGpu4TWO8MG 2verSmMDYwMxSJWzHCaEw7RrlErdGx8UOsnL8EZ9wBCydwd7k+qCShiEI8kChY7KK1r3 0IoyTxsqwmd+nFRA28I31I/WP+cFWFjOGbDPUeRo+qZNyyrHXF/rv2zM35p6939j2trh SyI8xU0TjiGZfB1Qnax7rxqALzRfuQBt7YHiJT9s7KCjpHTX5TeWmbGZldrlqiuFZ+d3 rXIw== X-Gm-Message-State: APt69E2Ju1RGelcdFj6q5XzT8SIuZ1yidsc6caRhc4CMzIw+7NRC613F 79flPbXUJEQnrlZRKHVuQEafPzE/rLm7M2vUWdintw== X-Google-Smtp-Source: AAOMgpfa2AO8XolLYH+OcUY/1vN+0SyOKGLa781PrcHCMI3TFQnxEGq4tejY8wxNKL4LREtEu3pTtsu66f8MszKZu5w= X-Received: by 2002:a02:3344:: with SMTP id k4-v6mr3150639jak.45.1531173927924; Mon, 09 Jul 2018 15:05:27 -0700 (PDT) MIME-Version: 1.0 References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> <1531078307.1336.22.camel@freebsd.org> <06cb8190-7a04-5c92-8fb9-637d1a80758f@freebsd.org> In-Reply-To: <06cb8190-7a04-5c92-8fb9-637d1a80758f@freebsd.org> From: Warner Losh Date: Mon, 9 Jul 2018 16:05:16 -0600 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Allan Jude Cc: Ian Lepore , Oliver Pinter , Eric McCorkle , Tommi Pernila , freebsd-current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 09 Jul 2018 22:05:29 -0000 I have this in my tree already... Warner On Mon, Jul 9, 2018, 10:28 AM Allan Jude wrote: > I will look at updating the rootgen.sh script this evening, to support > creating more flexible ESP partitions, so we can drop the loader.efi > into an msdosfs directly. > > On 07/08/2018 15:31, Ian Lepore wrote: > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote: > >> Hi! > >> > >> Have you or Warner any update on this code? > >> > >> On Thursday, April 12, 2018, Eric McCorkle > >> wrote: > >> > > > > Are you aware of https://reviews.freebsd.org/D15743 ? > > > > That's my changes to add geli support to loader(8) in an architecture- > > agnostic way, so that "it just works" for all platforms and flavors of > > loader. It has been succesfully tested on armv6/7 (ubldr) and on x86 > > using qemu. The x86 tests cover ufs and zfs, legacy bios and uefi. The > > only variations that aren't tested yet are the uefi flavors, because > > the current rootgen.sh script for assembling test images is still using > > boot1.efi and I don't know enough about efi myself to update the script > > to make it assemble images the new way Warner envisions. > > > > -- Ian > > > >>> > >>> I'm in the middle of moving to a new apartment right now. It's > >>> going to > >>> be a bit before I can get to this. > >>> > >>> On 04/11/2018 20:31, Warner Losh wrote: > >>>> > >>>> OK. I've pushed in the main part of it. The additional work I > >>>> have > >>>> shouldn't affect any of this stuff. I was going to look at what > >>>> part(s) > >>>> of your open reviewed needed to be redone tomorrow and send you > >>>> feedback, but if you wanted to get a start before then, I'm happy > >>>> to > >>>> answer questions. All the rest of my work is going to be > >>>> selecting the > >>>> root partition when we're told to us a specific partition, so > >>>> will be > >>>> very constrained. > >>>> > >>>> Warner > >>>> > >>>> On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle >>>> net > >>>> > wrote: > >>>> > >>>> I think the thing to do at this point is to wait for the > >>>> current > >>> work on > >>>> > >>>> loader.efi to land, then adapt my patches to apply against > >>>> that work. > >>>> > >>>> On 04/11/2018 15:06, Warner Losh wrote: > >>>> > Still reviewing the code. I'm worried it's too i386 > >>>> specific and it > >>>> > conflicts with some work I'm doing. I'll have a list of > >>>> actionable > >>>> > critiques this week. > >>>> > > >>>> > Warner > >>>> > > >>>> > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > >>>> > >>>> > >>>> >>>> >> > >>>> > wrote: > >>>> > > >>>> > Hi! > >>>> > > >>>> > Is there any update regarding the rebase or the > >>>> inclusion to > >>> base > >>>> > >>>> > system? > >>>> > On 3/28/18, Eric McCorkle >>>> >>> eric@metricspace.net> > >>>> > >>>> > >>>> et>>> > >>> wrote: > >>>> > >>>> > > I'll do another rebase from head just to be sure > >>>> > > > >>>> > > On March 28, 2018 3:23:23 PM EDT, Warner Losh < > >>> imp@bsdimp.com > >>>> > >>>> > >> 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" < > >>> tommi.pernila@iki.fi > >>>> > >>>> > >>>> fi>>> > >>> 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 < > >>> eric@metricspace.net > >>>> > >>>> > >>>> et>>> > >>>> > >>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" > >>>> > >>>> > >>>> et>> > >>>> > >>>> >> >>>> >>>> >>> > >>>> > 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/freeb > >>>> sd- > >>> current > >>>> > >>>> > >>>> > >>>> rent > >>>> > > >>>> > >>>> > To unsubscribe, send any mail to > >>> "freebsd-current-unsubscribe@ > >>>> > >>>> > >>>> freebsd.org > >>>> " > >>>> > >>>> > > >>>> > >>>> > >>>> > >>> > >>>> > > > >>>> > > -- > >>>> > > Sent from my Android device with K-9 Mail. Please > >>>> excuse my > >>> brevity. > >>>> > >>>> > > _______________________________________________ > >>>> > > freebsd-current@freebsd.org > >>>> > >>>> >>>> > > >>>> > mailing list > >>>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-cu > >>>> rrent > >>>> > >>>> > >>>> rent > >>>> > > >>>> > > 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" > > -- > Allan Jude > From owner-freebsd-current@freebsd.org Tue Jul 10 15:28:15 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 8B6801030BC4 for ; Tue, 10 Jul 2018 15:28:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (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 11C827BBA3 for ; Tue, 10 Jul 2018 15:28:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 76qu4mEVM1kK0LPIAN8TXbHxcZYaDgQuenUL0n6joNe4tvo4.RAlzBEyVqQY3RJ j9j2CjOUfh1kG62oE_JY82EacpJAe2328ixigG5ucWjqaEs5VsMuw7E3mVH1ztAxaMAKjFKXk1.7 uPaqRtfQeCkMFlBKEaWzmncmnb1oArc5ivEHL2Bs_f44fs1Qn6CuSR9FyL3q5opPA8apqHqHD0HP I54_M7W3zvD609xoOEzM4piUGt4mHr5GKm8Fv7Gz1SXFAASKe_mx0ugfdjX5Dh_uh46tQyMbpG0Z MI1zZr57IB7K86I6AA.UF107L.W0VXXGuBo8J6NuzU92_FudWJvw_Lo4hP_gGgUKsyDUipFSXuWz dOlmixnSTCb6noZaLzchKlULI0ld1HeefRW_ia8lUvbSC21f4.3KeNfoj0tcGPjZQ4A8UdDzLsT. XvzxWi86f7uVX_yrzuqCOb8UkQ3iKM1vr_bksuaa.vM4lEk9AqcDKbamW2zsZ8gufcPK3VcGqkXB TdfHt9FukXss_KbQfODpoCDRtCH1doJ17TCZmFuV4r39r5G0HyHbIIQxR9c44kX2wBEac74nQZHX fpfIN0nfjmvENJ41U5lJPU5MbVabNoaqBmHtp7Lpo.Ui6jejs7KC4ZRc84pwoANbV0b9UcgWd5kL Sruhv3KI6wtlxkjzoZBwZHITqWZDQT8ODJZ_E5PW2Dc6Vz7yQIHMMXWTbYyxtW7jyfh1evImIBp8 shXaoRykLvNBfSlcWFMYd5NC1C0WVXz3SPjec4njoFR64hZLGOnD8RFGu5ziJV8rNUdEDGp_bpdP FzkdJLY3_dJSLrl4ZUyOe_fYX1g1a3kKMH.bqskh7klzgoHukIwfv0yq37JZiVNzeiGRZZcgCN99 gbdto0MEGm8WC_ZwBUkIW_RnUy0V7uv5zwTH8BAMT.YqFzR6COMEk4UA81MWLGcBI6wNbCryPq6. afj6JsaHyvfgxDvQ7mZUxPb0pzodAieNowK51Qx631JUqCaiSpXVBTwnT5leGrVGKuKotAAngwA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Jul 2018 15:28:08 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1f633149f47a2b2e7fdd9c7be98422cd; Tue, 10 Jul 2018 15:28:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: All the builds on arthur.nyi.freebsd.org seem to be getting PostBuildScript having: . . . libpython3.6m.so.1.0: Undefined symbol "getrandom@FBSD_1.5" Message-Id: <01DBB928-E9E1-4E10-933C-B000C3ABF5FE@yahoo.com> Date: Tue, 10 Jul 2018 08:28:03 -0700 To: FreeBSD Current , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 10 Jul 2018 15:28:15 -0000 [PostBuildScript] - Executing post build scripts. [FreeBSD-head-armv6-build] $ /bin/sh -xe /tmp/jenkins5219713071838772045.sh + ./freebsd-ci/artifact/post-link.py /usr/local/lib/libpython3.6m.so.1.0: Undefined symbol "getrandom@FBSD_1.5" Build step 'Execute Scripts' changed build result to UNSTABLE I looked around at a bunch of yellow-status vs. green-status builds and yellow was always from arthur.nyi.freebsd.org in what I looked at. But I did not eliminate all others in the process. Everything that I found from arthur.nyi.freebsd.org was yellow-status. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Jul 10 21:50:16 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 7B9A0103079C; Tue, 10 Jul 2018 21:50:16 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.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 F13978DDAA; Tue, 10 Jul 2018 21:50:15 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr1-f43.google.com with SMTP id c13-v6so16066828wrt.1; Tue, 10 Jul 2018 14:50:15 -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=kU86yxQuAJPEbqbg+RILW+NVkd3RBvuyVOXePYnWnE4=; b=CaP7qhZasWwuSyqR4NpwbeyHEpMVNYP0mPYR4CtroOBAMvNbC3Fh7aLIfYQiVufQPq 6RdXFEYxY9jAj+I1jTkde7TuzchdAINI6AzwliJr5m/F7rfTRmRDKRcaGBYILSPv0vYm I7KzWT1NyZ1DkeiMGGPY3SmVtCBCYITAf/3Xq1/4NbM4e5KjmY1lc5zT0k23zJUMOkvn L8gfocVeUJxfx/JovrqgYb8JA5jMmvH5iCib6B/5EaOMvBe5VCPx0NvDRoIi+rcMw8oo XojYqwWg8AMwfIfUdxXAIJJ4bFeDwxqRHv5upbN6Q9iLgyH3TgS2g3j3O4udunCP+D9a aHcQ== X-Gm-Message-State: APt69E0hlO1+rh37jpDHBsxGmodn0EwHu9hK3CiebG8j9QZ61Gp0U1a+ ykqjBqQ84D3L2S/kXsujTs9z6VrFit7AtzGf02c= X-Google-Smtp-Source: AAOMgpde/8QiLRe9buQRO44ldaqc6XHnWenBfsRiPt9QSTCN6pnE1mk/aegyB7GzUVfJAUNeB7kOUXiYiFxnz7X8K80= X-Received: by 2002:adf:d842:: with SMTP id k2-v6mr18505232wrl.26.1531259408667; Tue, 10 Jul 2018 14:50:08 -0700 (PDT) MIME-Version: 1.0 References: <01DBB928-E9E1-4E10-933C-B000C3ABF5FE@yahoo.com> In-Reply-To: <01DBB928-E9E1-4E10-933C-B000C3ABF5FE@yahoo.com> From: Li-Wen Hsu Date: Wed, 11 Jul 2018 05:49:58 +0800 Message-ID: Subject: Re: All the builds on arthur.nyi.freebsd.org seem to be getting PostBuildScript having: . . . libpython3.6m.so.1.0: Undefined symbol "getrandom@FBSD_1.5" To: Mark Millard Cc: FreeBSD Current , svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 10 Jul 2018 21:50:16 -0000 On Tue, Jul 10, 2018 at 11:30 PM Mark Millard wrote: > > > [PostBuildScript] - Executing post build scripts. > [FreeBSD-head-armv6-build] $ /bin/sh -xe /tmp/jenkins5219713071838772045.sh > + ./freebsd-ci/artifact/post-link.py > /usr/local/lib/libpython3.6m.so.1.0: Undefined symbol "getrandom@FBSD_1.5" > Build step 'Execute Scripts' changed build result to UNSTABLE > > > > I looked around at a bunch of yellow-status vs. green-status builds and > yellow was always from arthur.nyi.freebsd.org in what I looked at. But > I did not eliminate all others in the process. Everything that I found > from arthur.nyi.freebsd.org was yellow-status. > This is because of the ABI incompatible between different versions of -CURRENT, on pkg build cluster and the arthur.nyi. It has been fixed. Thanks, Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Wed Jul 11 06:22: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 66EC3103A963 for ; Wed, 11 Jul 2018 06:22:55 +0000 (UTC) (envelope-from gurenchan@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 F1D44800E7 for ; Wed, 11 Jul 2018 06:22:54 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x229.google.com with SMTP id l14-v6so12639344iob.7 for ; Tue, 10 Jul 2018 23:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wYOXp8duYzYDwmmPJUAFBWz7+zMmLQQL+CoOe5V8PnY=; b=fPLJINocc5BppDo2zaV2fzuE1PUYVbyEgQPZf37BnzcLG7ZcXyL4gyzAs0l0H1U1Up lEXyxS3jj9qOZPLfq7OYw1FgVPfMyYUUR+whTFgu+C9opes19hWqbvbjCRJgj0Pg3/yP tVZZN56ekwJsZbJXqLfXUNhtouuAqZNCz4GpK2/turMSn8bwer1SipyNbxBPO17apIZb oEFN/VEvprJclP32qwwDmDGYS9FNeEByY062LkRV4o9RiBrAYJV9gmFHvtLFh+WsfmX7 wo7iOjDBZZVCOWqd2jXxd7T49AmeNrHi4/qNfXpvIINs7hCsRlWcF7sfHwNI/NTJNIBV Jidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wYOXp8duYzYDwmmPJUAFBWz7+zMmLQQL+CoOe5V8PnY=; b=gU8quj8Nia+dSmXikD9STymNo2buX442TF2mnRBth26cXH1i3jX6W1gK1K0xPZkJIR 2PD+kqHgCnlnT7sl8/Yyo4Nvkj1UcSkS76u7rg/sYIyNO2BDVMfbwG/IPZyeh1lotuEC 2en6STKcyQRGNEo8b+K96QdrJo2SzLT8WnQOtCSS7Mv2avMiPdFRTlIq0Sl5sDxwRHr+ KzEl4SNEQ/hVS/MpH99S/8QPPLL9jIvhAIxaJxssnU3oE+UCSJExhgMHDsak81YTMbkC 243kMWtP8Vkt+4nW36H98+fZjtQNXO0RisEK/GLH1oCjF7W8TeDl6uTRa6PTCWdOdUY8 Z4nA== X-Gm-Message-State: AOUpUlG1ZEvsyv1y2Ro+lHkVASw+z2j4ymmXm8u8Bb8OV9T+pt4YvW4I +mrpE+fjGxXGQ174vCMMzfch5DTs8BkRkXQz1Ap8J28q X-Google-Smtp-Source: AAOMgpcMiythpK/qYvAbDQoPcJfZy7kF1xgGU6UHpGYLMgd20Jwdj/bfHLVoAHQuWDy5zEg36/F1ktaP5zKwbu8xilA= X-Received: by 2002:a6b:2c82:: with SMTP id s124-v6mr2219919ios.136.1531290174073; Tue, 10 Jul 2018 23:22:54 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Wed, 11 Jul 2018 14:22:42 +0800 Message-ID: Subject: Make buildworld fails To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 11 Jul 2018 06:22:55 -0000 Why am I getting these errors? error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] ---------------------- In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:477: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:796:29: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:802:32: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const wchar_t *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:808:33: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char16_t *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:814:33: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char32_t *__str, size_t __len) _NOEXCEPT ^ In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4046:24: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4052:27: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const wchar_t *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4058:28: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char16_t *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4064:28: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char32_t *__str, size_t __len ) ^ 8 errors generated. *** Error code 1 From owner-freebsd-current@freebsd.org Wed Jul 11 08:09: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 453CC10438C5 for ; Wed, 11 Jul 2018 08:09:48 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 97D82840A2 for ; Wed, 11 Jul 2018 08:09:47 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 48801 invoked by uid 89); 11 Jul 2018 08:09:39 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@93.104.93.233) by mail.grem.de with ESMTPA; 11 Jul 2018 08:09:39 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Make buildworld fails From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Wed, 11 Jul 2018 10:09:38 +0200 Cc: FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: blubee blubeeme X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 11 Jul 2018 08:09:48 -0000 > On 11. Jul 2018, at 08:22, blubee blubeeme wrote: >=20 > Why am I getting these errors? >=20 > error: user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] >=20 > ---------------------- > In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: > In file included from > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:477: > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:796:29: > error: user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string_view operator "" sv(const char *__str, size_t __len)= > _NOEXCEPT > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:802:32: > error: user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string_view operator "" sv(const wchar_t *__str, size_t > __len) _NOEXCEPT > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:808:33: > error: user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string_view operator "" sv(const char16_t *__str, > size_t __len) _NOEXCEPT > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:814:33: > error: user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string_view operator "" sv(const char32_t *__str, > size_t __len) _NOEXCEPT > ^ > In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4046:24: error:= > user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string operator "" s( const char *__str, size_t __len ) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4052:27: error:= > user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string operator "" s( const wchar_t *__str, size_t __len= > ) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4058:28: error:= > user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string operator "" s( const char16_t *__str, size_t > __len ) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4064:28: error:= > user-defined literal suffixes not starting with '_' are reserved > [-Werror,-Wuser-defined-literals] > basic_string operator "" s( const char32_t *__str, size_t > __len ) > ^ > 8 errors generated. > *** Error code 1 > _______________________________________________ > 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"= Which version/checkout (svn info and svn status), how do you build (and wher= e), what does your /etc/make.conf look like?= From owner-freebsd-current@freebsd.org Wed Jul 11 11:42: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 021E81030D45; Wed, 11 Jul 2018 11:42:58 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 9C26E8CC47; Wed, 11 Jul 2018 11:42:57 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 00E9E20FAD; Wed, 11 Jul 2018 07:42:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 11 Jul 2018 07:42:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=grd00StZFjYRV2JhI8bO4K6Ux271Wjh3unsDzk81i+E=; b=qWhnS58z i53wLYdRBwmbi9cG8SUfi36lfQCoFdA2RVyz4kHlhRQFyaPUpdKp+XzaT5+XiYw4 mmdc0v2X3zDgWBcknuVFjtuWjUVmRpEuWhx8HZ34UQgyjBNwzxKb57QD7D176sc+ AP77GH8OgNPE8xww0dbYYKelqmG7jmsu62k/s3hy1PP5/PkfCPIjSDk/5ddEoQD1 wGNiMRLFru3HFXchTWIbh4a+QK63qUkswSGOXxlBVf5zX1GS9+b90Ml5/rbyEQVy 4tzWjiqsVsY6LzMPc+wmU98HjvB49IgUJp95upfFDOezKv8CtuwKfBEQtNt457h/ N0Qhy+SiiJ3Y0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=grd00StZFjYRV2JhI8bO4K6Ux271W jh3unsDzk81i+E=; b=idEsUhA+3FsOWzwGLDjXhRUuEPW47Djsr7Xyjnl/Bmr0C TEhTox/TK/rtw546eJ0es8WIcpruE/PHWBTvDGIvMpwlf/gL1SROmDMq5HG2hgID zTF+IY7E/YuNsWZ9IttZKCYMeVyRA0rbngdIRQlUyMhSUw3xV365ejW05RQECnPw 4C+guYDHYe5/zbmMlzxdtxhSP2GJH05rxA4sU9AId+FlqEmaAdUb+ISQCXiafnKD NapR6fggUPvV11tBbO8VsPCoMNHda2pa4lo318SEggXe07htmKcug60mkQAm0pKa t52UI1B6czk3A4uNQD4yPLENGCYmgX2ynuA+JcyCw== X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D574E4072; Wed, 11 Jul 2018 07:42:56 -0400 (EDT) To: freebsd-arm@freebsd.org Cc: FreeBSD Current From: tech-lists Subject: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 Organization: none Message-ID: Date: Wed, 11 Jul 2018 12:42:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 11 Jul 2018 11:42:58 -0000 Hello lists [x-posted to -current where it's also relevant] 12-current-arm64 fails to build generic-nodebug kernel context: 12.0-CURRENT #0 r336134: Mon Jul 9 GENERIC arm64 (this is the older rpi3B+) root@rpi3:/usr/src# svnlite info Path: . Working Copy Root Path: /ext/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 336195 Node Kind: directory Schedule: normal Last Changed Author: eugen Last Changed Rev: 336195 Last Changed Date: 2018-07-11 10:41:50 +0100 (Wed, 11 Jul 2018) Some dirs on /usr are symlinked to a 1TB external disk. Swap is on the external disk. Made sure there was no src.conf or make.conf present: root@rpi3:/root# cd /etc root@rpi3:/etc# mv src.conf old.src.conf root@rpi3:/etc# mv make.conf old.make.conf root@rpi3:/etc# cd /usr/src root@rpi3:/usr/src# rm -rf /ext/obj root@rpi3:/usr/src# mkdir /ext/obj root@rpi3:/usr/src# ls -lah /usr total 72 drwxr-xr-x 12 root wheel 512B Jul 10 11:15 . drwxr-xr-x 20 root wheel 512B Jul 10 18:45 .. drwxr-xr-x 2 root wheel 7.5K Jul 9 20:45 bin drwxr-xr-x 2 root wheel 512B Jul 10 11:15 home drwxr-xr-x 56 root wheel 6.5K Jul 9 20:44 include drwxr-xr-x 10 root wheel 16K Jul 9 20:45 lib drwxr-xr-x 5 root wheel 512B Jul 9 20:28 lib32 drwxr-xr-x 5 root wheel 512B Jul 9 20:28 libdata drwxr-xr-x 9 root wheel 1.5K Jul 9 20:45 libexec lrwxr-xr-x 1 root wheel 10B Jul 10 11:43 local -> /ext/local lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 obj -> /ext/obj lrwxr-xr-x 1 root wheel 10B Jul 10 11:41 ports -> /ext/ports drwxr-xr-x 2 root wheel 5.0K Jul 9 20:45 sbin drwxr-xr-x 29 root wheel 512B Jul 9 20:28 share lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 src -> /ext/src drwxr-xr-x 15 root wheel 512B Jul 9 20:46 tests root@rpi3:/usr/src# make -j10 cleanworld && make -j10 cleandir && make -j10 clean <--- just to make absolutely sure [...] RPI3 is just a copy of GENERIC-NODEBUG. it looks like this: include GENERIC ident RPI3 nooptions INVARIANTS nooptions INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIPSPIN nooptions DEADLKRES nooptions USB_DEBUG root@rpi3:/usr/src# make -j1 buildkernel KERNCONF=RPI3 [...] ===> armv8crypto (all) [Creating objdir /ext/obj/ext/src/arm64.aarch64/sys/RPI3/modules/ext/src/sys/modules/armv8crypto...] machine -> /ext/src/sys/arm64/include ln -sf /ext/obj/ext/src/arm64.aarch64/sys/RPI3/opt_bus.h opt_bus.h awk -f /ext/src/sys/tools/makeobjops.awk /ext/src/sys/kern/device_if.m -h awk -f /ext/src/sys/tools/makeobjops.awk /ext/src/sys/kern/bus_if.m -h awk -f /ext/src/sys/tools/makeobjops.awk /ext/src/sys/opencrypto/cryptodev_if.m -h cc -target aarch64-unknown-freebsd12.0 --sysroot=/ext/obj/ext/src/arm64.aarch64/tmp -B/ext/obj/ext/src/arm64.aarch64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /ext/obj/ext/src/arm64.aarch64/sys/RPI3/opt_global.h -I. -I/ext/src/sys -I/ext/src/sys/contrib/ck/include -g -fPIC -I/ext/obj/ext/src/arm64.aarch64/sys/RPI3 -MD -MF.depend.genoffset.o -MTgenoffset.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -std=iso9899:1999 /ext/src/sys/kern/genoffset.c sh /ext/src/sys/kern/genoffset.sh genoffset.o > offset.inc cc -target aarch64-unknown-freebsd12.0 --sysroot=/ext/obj/ext/src/arm64.aarch64/tmp -B/ext/obj/ext/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /ext/obj/ext/src/arm64.aarch64/sys/RPI3/opt_global.h -I. -I/ext/src/sys -I/ext/src/sys/contrib/ck/include -fno-common -g -fPIC -I/ext/obj/ext/src/arm64.aarch64/sys/RPI3 -MD -MF.depend.armv8_crypto.o -MTarmv8_crypto.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -std=iso9899:1999 -c /ext/src/sys/crypto/armv8/armv8_crypto.c -o armv8_crypto.o ctfconvert -L VERSION -g armv8_crypto.o cc -target aarch64-unknown-freebsd12.0 --sysroot=/ext/obj/ext/src/arm64.aarch64/tmp -B/ext/obj/ext/src/arm64.aarch64/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -DHAVE_KERNEL_OPTION_HEADERS -include /ext/obj/ext/src/arm64.aarch64/sys/RPI3/opt_global.h -I. -I/ext/src/sys -I/ext/src/sys/contrib/ck/include -fno-common -g -fPIC -I/ext/obj/ext/src/arm64.aarch64/sys/RPI3 -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -std=iso9899:1999 -Werror -march=armv8-a+crypto /ext/src/sys/crypto/armv8/armv8_crypto_wrap.c In file included from /ext/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: /usr/lib/clang/6.0.1/include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found #include ^~~~~~~~~~ 1 error generated. *** [armv8_crypto_wrap.o] Error code 1 make[4]: stopped in /ext/src/sys/modules/armv8crypto 1 error make[4]: stopped in /ext/src/sys/modules/armv8crypto *** [all_subdir_armv8crypto] Error code 2 make[3]: stopped in /ext/src/sys/modules 1 error make[3]: stopped in /ext/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /ext/obj/ext/src/arm64.aarch64/sys/RPI3 1 error make[2]: stopped in /ext/obj/ext/src/arm64.aarch64/sys/RPI3 *** [buildkernel] Error code 2 make[1]: stopped in /ext/src 1 error make[1]: stopped in /ext/src *** [buildkernel] Error code 2 make: stopped in /ext/src 1 error make: stopped in /ext/src -- J. From owner-freebsd-current@freebsd.org Wed Jul 11 16:21:23 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 BD0FF1022B1C for ; Wed, 11 Jul 2018 16:21:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.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 E9A3B79CB8 for ; Wed, 11 Jul 2018 16:21:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: FzJZtDsVM1laMAzoMkgUJmeFZ6LTReUB_EPmfqM5J.d7wN.T8PO50DKdWjWW6PQ HFPmtlGGF1bNTlDeUJ4WVe.TdNEntkXpgNfsynFUUTDqrb7hWpo7G5ZxvoIANsUkRyEn.NiiTgTc m2QXfNoV1BTsx13xD3FHqpQK7Vi5xanxmZVI.EoAZItS4CaOONvLqMnJHx1R7.999_KCkyVycRCq akZRbs007.fWVKxTjX3D_qnVLTCondgKxZDLGlDUG3znUW3R8pu0.lQQX2noT0uBGhYWmxJ24Qpd wLAcOmKAUCqNyRBo2e5QWD_n2QG7I_SV8yR02nZhwSzOmvFVwIix5rN1gORnAt3byWW.ehYhcZAq G947MTWvQyghblVL6NSzlrHgoe1TpF2G2n48eMHNNYcNnWK6oSVkY7rpHRhZBbkSamLeGuXiVb9P vMswX0F5AIfjh2N4Dp11Hj9GgNyZMIiDIJBksZwNzoo.BPLrPYmQlmhkIihV1BT9Hkm16q4qBmJo rL0vh9AJ8MCZtiahifO93T3pIed5UWXULBC8AAvvx2xETOsnbJDKbA2n.LqXzQgq8uysCsBYoUCd 6xYmug83ceU9c6t51a18.QV2PF7M5N6DhLWqo.JZFPfpUnyC2mysZZ1k6_E2FRWVoi6Tvv0nZ1C7 jVENf0dhK8qBljpT_xbjtdS5ursbSqiPJAuqw1_kC.aQ3dk0lUi5bU0DsFo4_p9vII9t_hMQkVa8 oAoRJlMoAzWuROzVupO501Wq0N5pMHLwoXuJRGh.bQynTbU8l4eIN7LuB0Fzp9Tv_XTZ_yo86dMs ki9qZSgXy_MI1jLew7iT1nNgIrAX.r_fxRdaKd_rkMPDNJr5MCWN.rNzLXBVVbvuyz39e3hhVlj9 sbUXCd0wiTbrc2wrIlzRgkDrwH5kHFCnOJp8.jNny_T34IuDdvn_IuNCKnzk5i2B_ocdkivTCnqm LwTaFF1UZOVpft2B1eSckkwFaMAvb.h0LTzGCJb2r31lakuXIAnrKUtQ17wSDqQEZhA5CShs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 11 Jul 2018 16:21:22 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ccafd419de053a23f276ec87f9262c21; Wed, 11 Jul 2018 16:21:19 +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.5 \(3445.9.1\)) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 Message-Id: Date: Wed, 11 Jul 2018 09:21:17 -0700 To: FreeBSD Current , freebsd-arm , FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 11 Jul 2018 16:21:24 -0000 tech-lists tech-lists at zyxst.net wrote on Wed Jul 11 11:42:58 UTC 2018 : > Hello lists [x-posted to -current where it's also relevant] >=20 > 12-current-arm64 fails to build generic-nodebug kernel >=20 > context: > 12.0-CURRENT #0 r336134: Mon Jul 9 GENERIC arm64 (this is the older = rpi3B+) >=20 >=20 > root at rpi3 > :/usr/src# svnlite info > Path: . > Working Copy Root Path: /ext/src > URL:=20 > https://svn.freebsd.org/base/head >=20 > Relative URL: ^/head > Repository Root:=20 > https://svn.freebsd.org/base >=20 > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 336195 > Node Kind: directory > Schedule: normal > Last Changed Author: eugen > Last Changed Rev: 336195 > Last Changed Date: 2018-07-11 10:41:50 +0100 (Wed, 11 Jul 2018) >=20 > Some dirs on /usr are symlinked to a 1TB external disk. Swap is on the=20= > external disk. Made sure there was no src.conf or make.conf present: >=20 >=20 > root at rpi3 > :/root# cd /etc >=20 > root at rpi3 > :/etc# mv src.conf old.src.conf >=20 > root at rpi3 > :/etc# mv make.conf old.make.conf >=20 > root at rpi3 > :/etc# cd /usr/src >=20 >=20 > root at rpi3 > :/usr/src# rm -rf /ext/obj >=20 > root at rpi3 > :/usr/src# mkdir /ext/obj >=20 > root at rpi3 > :/usr/src# ls -lah /usr > total 72 > drwxr-xr-x 12 root wheel 512B Jul 10 11:15 . > drwxr-xr-x 20 root wheel 512B Jul 10 18:45 .. > drwxr-xr-x 2 root wheel 7.5K Jul 9 20:45 bin > drwxr-xr-x 2 root wheel 512B Jul 10 11:15 home > drwxr-xr-x 56 root wheel 6.5K Jul 9 20:44 include > drwxr-xr-x 10 root wheel 16K Jul 9 20:45 lib > drwxr-xr-x 5 root wheel 512B Jul 9 20:28 lib32 > drwxr-xr-x 5 root wheel 512B Jul 9 20:28 libdata > drwxr-xr-x 9 root wheel 1.5K Jul 9 20:45 libexec > lrwxr-xr-x 1 root wheel 10B Jul 10 11:43 local -> /ext/local > lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 obj -> /ext/obj > lrwxr-xr-x 1 root wheel 10B Jul 10 11:41 ports -> /ext/ports > drwxr-xr-x 2 root wheel 5.0K Jul 9 20:45 sbin > drwxr-xr-x 29 root wheel 512B Jul 9 20:28 share > lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 src -> /ext/src > drwxr-xr-x 15 root wheel 512B Jul 9 20:46 tests >=20 >=20 > root at rpi3 > :/usr/src# make -j10 cleanworld && make -j10 cleandir && make=20 > -j10 clean <--- just to make absolutely sure >=20 > [...] >=20 > RPI3 is just a copy of GENERIC-NODEBUG. it looks like this: >=20 > include GENERIC >=20 > ident RPI3 >=20 > nooptions INVARIANTS > nooptions INVARIANT_SUPPORT > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > nooptions DEADLKRES > nooptions USB_DEBUG >=20 >=20 > root at rpi3 > :/usr/src# make -j1 buildkernel KERNCONF=3DRPI3 >=20 > [...] [Like a answered in freebsd-arm . . .] Bugzilla 220125 (from over a year ago) is a non-fixed report about this = for the likes of: make kernel-toolchain buildkernel Over the time since then the workaround was to use: make buildworld buildkernel buildworld put the needed stdint.h in place, kernel-toolchain did not. If kernel-toolchain was in use, then the recent bugzilla 229702 and this exchange is a duplicate. If buildworld was in use then 229702 and this exchange is new. [Added note . . .] It seems from the quoted material that neither kernel-toolchain nor build world was done before buildkernel . My understanding is that the intent is that one or the other be done first. (But for aarch64 currently only buildworld works.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 12 09:44: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 9FB4010479BC; Thu, 12 Jul 2018 09:44:11 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 3886B867A8; Thu, 12 Jul 2018 09:44:11 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DEA442FF; Thu, 12 Jul 2018 05:44:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 12 Jul 2018 05:44:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=EMaXimHYrrdwjfoLDZYA2Mh9PsoDZ fqkBUQyA1Xm27g=; b=BpHBge6vwlsNpJToPgMayqyEEJJOv4vZiV1AT3iRJiFO8 i9UqhltNg7ZkL53dXwYqdpohQA5ueRPYT+XjO8nU+4Oc9Iyh1gqmI7ome6m//uJx cQiSkvrSR673IImoqPH2sqv8ER03ailK2F0lk08/7yiZ5BEfrEiF+JYvjmlJ1Uvd R75uoOseWu9Khz7HWOLa03xxtZu9MdIL5/6kXlj+MauXay09AmM6UcYqDEKAzbZc kdlgz6WLLQ3cMMZYatK6Mk55hqJh53AjxED789u5Y9cA5Nj77o5oKB1UZ++/82sr GaVDulsoVvBQAmq4hSXygFjF+0krG449OY7syrn+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EMaXim HYrrdwjfoLDZYA2Mh9PsoDZfqkBUQyA1Xm27g=; b=M2EAaGPZ1sYNbvnFjuTRjD 9q5qpHm1TjmqOsv0tp/dyO6T2Y05da1V1a4KvCsdzBTROoqSOLDCdkrFkDFxD+MN RrFJLwXV4c2cz6JzBZzRRlpslYkXRCC0I+3b1LAKO15zcNYv0o2ayJF2J7A4Xca5 NfTdP+mU8IfYQKJ23jsbuNwXh8ds2DDP3/siroPdw/Bt+R8EhuMsSLvXE/sF29jS TaGjY8bdvgiOlimbq/02g0zbVyLdkJlgExdWWcCDI1d9sLQfpQ8ekaPhN72CmQ/r TwljdAPkleiEuGb0feoNrJLkDERWvLNCP/s5EYD3acNDm86ZjlKdF72IVCLkoKLA == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 56A871026B; Thu, 12 Jul 2018 05:44:01 -0400 (EDT) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 To: Mark Millard , FreeBSD Current , freebsd-arm , FreeBSD Toolchain References: From: tech-lists Organization: none Message-ID: Date: Thu, 12 Jul 2018 10:44:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 09:44:11 -0000 On 11/07/2018 17:21, Mark Millard wrote: > It seems from the quoted material that neither kernel-toolchain nor > build world was done before buildkernel . My understanding is that > the intent is that one or the other be done first. (But for aarch64 > currently only buildworld works.) Thanks for this. I'm running a buildworld now. For how long has it been the case that buildworld is needed for buildkernel? Coming from amd64 and before that, i386, in situations where I've only wanted to install a custom kernel, I was firstly used to making and installing it from /sys/{i386,amd64}/conf. Then that broke a number of years ago. Then got used to making kernel in /usr/src with make buildkernel && make installkernel. And now this is broken, on aarch64-arm64. Nobody knows if it's accidental or policy. -- J. From owner-freebsd-current@freebsd.org Thu Jul 12 12:43:15 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 4CE651032488 for ; Thu, 12 Jul 2018 12:43:15 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF1EE8F490 for ; Thu, 12 Jul 2018 12:43:14 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Thu, 12 Jul 2018 14:42:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1531399393; bh=Qsjg9oaDuLf6/fSKubXkQVTXaAOTLBtnj2lGquQuiLg=; h=Date:From:To:Subject:References:In-Reply-To; b=VZqDjdRMZhjNIkU8sMD+bPaIW92d/4b1uPfV+SQ0MpkmYmKPxTT4XHWBJgokSaSjB pKf0pR2Y8ugz3k5/iFCwc4kB2xgGK6nGzyPaF2bNo4OOs8nu/xGCVjROMTFa/vzmJ/ 8bYNvIj+YmEEfJTgcgBTYnztvwyCYgP3byOxYe1fFpBpx6p9jlXg1WLZdJ74PfMWxD qMASgFSLm9tnI6RASJw3R1ZxsoDVJxa+i4ma3a3v98c0xFiDNc3nVdv7BgqoBNlbhe fMo7GHXI2rRDL8A2YkagwvE5+59NVKvSw+wpIBs/Swcx8G00aRd0EUAhE9W0hxbfy7 rWve3JzACHiWA== Message-ID: <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-current@freebsd.org Subject: Re: Deadlocks / hangs in ZFS References: <20180522101749.Horde.Wxz9gSxx1xArxkYMQqTL0iZ@webmail.leidinger.net> <20180522122924.GC1954@zxy.spb.ru> <20180522161632.Horde.ROSnBoZixBoE9ZBGp5VBQgZ@webmail.leidinger.net> <20180522144055.GD1954@zxy.spb.ru> <20180527194159.v54ox3vlthpuvx4q@jo> <20180527220612.GK1926@zxy.spb.ru> <20180528090201.Horde._E4JZcuEaZHfj_BNzWjci2O@webmail.leidinger.net> <20180603211450.Horde.pI-Fom6S1tUcaHvTF4MUjin@webmail.leidinger.net> <20180603192814.GP1926@zxy.spb.ru> <20180604223108.Horde.RcVquaVKWdNzNidD_5aJz7E@webmail.leidinger.net> In-Reply-To: <20180604223108.Horde.RcVquaVKWdNzNidD_5aJz7E@webmail.leidinger.net> User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_2USRmY-6FpJfuASgA9OC6Zt"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 12:43:15 -0000 This message is in MIME format and has been PGP signed. --=_2USRmY-6FpJfuASgA9OC6Zt Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alexander Leidinger (from Mon, 04=20=20 Jun=202018 22:31:08 +0200): > Quoting Slawa Olhovchenkov (from Sun, 3 Jun 2018=20=20 >=2022:28:14 +0300): > >> On Sun, Jun 03, 2018 at 09:14:50PM +0200, Alexander Leidinger wrote: >> >>> Quoting Alexander Leidinger (from Mon, 28 >>> May 2018 09:02:01 +0200): >>> >>>> Quoting Slawa Olhovchenkov (from Mon, 28 May 2018 >>>> 01:06:12 +0300): >>>> >>>>> On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote: >>>>> >>>>>> On 05/22, Slawa Olhovchenkov wrote: >>>>>>> > It has been a while since I tried Karl's patch the last time, and= I >>>>>>> > stopped because it didn't apply to -current anymore at some point= . >>>>>>> > Will what is provided right now in the patch work on -current? >>>>>>> >>>>>>> I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g >>>>>>> I am don't know how to have two distinct patch (for stable and >>>>>>> current) in one review. >>>>>> >>>>>> I'm experiencing these issues sporadically as well, would you mind >>>>>> to publish this patch for fresh current? >>>>> >>>>> Week ago I am adopt and publish patch to fresh current and stable, is >>>>> adopt need again? >>>> >>>> I applied the patch in the review yesterday to rev 333966, it >>>> applied OK (with some fuzz). I will try to reproduce my issue with >>>> the patch. >>> >>> The behavior changed (or the system was long enough in this state >>> without me noticing it). I have a panic now: >>> panic: deadlkres: possible deadlock detected for 0xfffff803766db580, >>> blocked for 1803003 ticks >> >> Hmm, may be first determinate locked function >> >> addr2line -ie /boot/kernel/kernel 0xfffff803766db580 >> >> or >> >> kgdb >> x/10i 0xfffff803766db580 > > Both don'T produce any sensible output: > (kgdb) x/10i 0xfffff803766db580 > 0xfffff803766db580: subb $0x80,-0x78(%rsi) > 0xfffff803766db584: (bad) > 0xfffff803766db585: (bad) > 0xfffff803766db586: (bad) > 0xfffff803766db587: incl -0x7f7792(%rax) > 0xfffff803766db58d: (bad) > 0xfffff803766db58e: (bad) > 0xfffff803766db58f: incl -0x7f7792(%rax) > 0xfffff803766db595: (bad) > 0xfffff803766db596: (bad) > > > Seems I need to provoke a real kernel dump instead of a textdump for this= . Finally... time to recompile the kernel with crashdump-compress=20=20 support=20and changing from textdump to normal dump and to install a=20=20 recent=20gdb from ports... The dump is with r336194 and the zfs patch as of 20180527. ---snip--- # kgdb -c /var/crash/vmcore.2 /boot/kernel/kernel GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from=20=20 /usr/lib/debug//boot/kernel/kernel.debug...done. done. Unread=20portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x20 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff81391fbe stack pointer =3D 0x0:0xfffffe0000457b10 frame pointer =3D 0x0:0xfffffe0000457bb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 15 (arc_reclaim_thread) trap number =3D 12 panic: page fault cpuid =3D 1 time =3D 1531394214 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0000457= 7d0 vpanic() at vpanic+0x1a3/frame 0xfffffe0000457830 panic() at panic+0x43/frame 0xfffffe0000457890 trap_fatal() at trap_fatal+0x35f/frame 0xfffffe00004578e0 trap_pfault() at trap_pfault+0x62/frame 0xfffffe0000457930 trap() at trap+0x2ba/frame 0xfffffe0000457a40 calltrap() at calltrap+0x8/frame 0xfffffe0000457a40 --- trap 0xc, rip =3D 0xffffffff81391fbe, rsp =3D 0xfffffe0000457b10, rbp= =20=20 =3D 0xfffffe0000457bb0 --- arc_reclaim_thread() at arc_reclaim_thread+0x42e/frame 0xfffffe0000457bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe0000457bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000457bf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- Uptime: 38m3s Dumping 2378 out of 8037 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..9= 1% __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) bt #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80485e11 in kern_reboot (howto=3D260) at=20=20 /usr/src/sys/kern/kern_shutdown.c:446 #3=20 0xffffffff804863f3 in vpanic (fmt=3D, ap=3D0xfffffe000= 0457870) at /usr/src/sys/kern/kern_shutdown.c:863 #4 0xffffffff80486443 in panic (fmt=3D) at=20=20 /usr/src/sys/kern/kern_shutdown.c:790 #5=20 0xffffffff8075279f in trap_fatal (frame=3D0xfffffe0000457a50,=20=20 eva=3D32) at /usr/src/sys/amd64/amd64/trap.c:892 #6 0xffffffff80752812 in trap_pfault (frame=3D0xfffffe0000457a50,=20=20 usermode=3D) at /usr/src/sys/amd64/amd64/trap.c:728 #7 0xffffffff80751e1a in trap (frame=3D0xfffffe0000457a50) at=20=20 /usr/src/sys/amd64/amd64/trap.c:427 #8=20 #9 0xffffffff81391fbe in arc_check_uma_cache (lowest=3D-1011712) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 #10 arc_reclaim_thread (unused=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4657 #11 0xffffffff8044ca74 in fork_exit (callout=3D0xffffffff81391b90=20=20 ,=20arg=3D0x0, frame=3D0xfffffe0000457c00) at /usr/src/sys/kern/kern_fork.c:1057 #12 (kgdb) up 9 #9 0xffffffff81391fbe in arc_check_uma_cache (lowest=3D-1011712) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 4532 lowest +=3D=20=20 uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone); (kgdb)=20list 4527 int iter =3D 4; 4528 int step =3D 1 << (SPA_MAXBLOCKSHIFT=20= =20 -=20SPA_MINBLOCKSHIFT - 3); 4529 int n =3D (SPA_MAXBLOCKSIZE >>=20=20 SPA_MINBLOCKSHIFT)=20- 1; 4530 4531 while (n >=3D 0) { 4532 lowest +=3D=20=20 uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone); 4533=20 if (lowest >=3D 0) 4534 return lowest; 4535 n -=3D step; 4536 if(--iter =3D=3D 0) { (kgdb) print n $1 =3D 32767 (kgdb) print zio_data_buf_cache[n] $2 =3D (kmem_cache_t *) 0x0 (kgdb) ---snip--- Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_2USRmY-6FpJfuASgA9OC6Zt Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbR0y1AAoJEKrxQhqFIICE5ZcP/2osqMauBIm9L+hZyCFGt8Nq j0WZ6OD+FeqW9OzJN+ucmyTTCERRxfi1sYUWn9TIpmvjBy33HBMb98+J6Wldk0Vg WbmGBIzDaI095e+H6wHF0GpPEVgvUvIMwkgYSpLGfty8m05fbsqAhs/uE+JX7UGF JO/YVvicUa0NjWLS1Hz7BECpRgyaNPClALouT8FTY88lZFFfNB4oqx6uQS2HARKV OztSJhhgC8X9pddNK0TOFPv2xsq08E6F24U718UvdvRLwy30r8DYB2EO/hz/oLhe djAB2waNTXF5jd2q0pTlq4Jfd5kEeTKpspEmRCZBZ78ZOLHlpUm3Nbt7NalZvyEU TOtxdORfiRkqJ1PZY6vvK79QObbw5QzccE+VCId2HuZejuC7qlANIUQzhGp0TKnD ZHexRTPNsr2aAr/3phTdL9qBYObwEbQIggyyNQhVczrSSEjLPKObMJ/lJ9j6dStl SKe8L2W3mAc790rte4OuMsUk7B3s6/129WbHmrd6ksj/SXZDNxSjti/tEE6zsAf0 RLzKQGACQKr9RaKZVH3TU5i62ZfwiveN+rHOAjB4auoAKS7egtXnL+q2rFYwB45c zYgHuFs6ihRccnuJfxHTqjHytYfAZ3TljVeWdsbvnGJxVjKtRKjsSXpEIrN3jDEm 0Qxn/v6PbDu+4TdQ9l5e =1F0l -----END PGP SIGNATURE----- --=_2USRmY-6FpJfuASgA9OC6Zt-- From owner-freebsd-current@freebsd.org Thu Jul 12 13:34: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 742CF1039D1F for ; Thu, 12 Jul 2018 13:34:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 ED03C917B2 for ; Thu, 12 Jul 2018 13:34:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OEY7IvoVM1le6b8GP7GhYjAG4CyYHT3qP1VlNmQ3sxV8jd3Ezvfrj7rHc0guaFk pLHrvaOTp.YOJ8ohWiphXmu0Hr.4bNMRJ6k8aAC1JYdNtiBAsspnuBkxDv4IzrZso.d9NVXhUJLe G15UtsLMRBfn6bWmGMaOfHguahm0KKKHc2PSLSYSU9ku9nXR92cBWhv2hrA3WL_CR4X22PIjIQUz KUOBlA2rGiYqDkHeMOHm.b3IUa42oDH3H2xQSyQ5WxfzW7IQjOPiy0FpxYmsJ6tQFadllm8nVHlo edC6Oa95qGHwLirSwXEaWkHUQCHgTqbaaU0DFRgUWiWdjsD9bq86Ajzj22.0J2YG0gObRdAFTWPT RLTeXwO.SMttMBpCU918G0pQGGDofqOcete.G0yTlijtbKKZqYnUaqiI3j4gkiNnOUF4IxHaIxYt yq3_b5dffO2bSakQSUJAz10kT9GkTrP_vJaM9jimb5R7AcKaHFB5jWoNfj53Zv58q_RAfZNVkLhZ esBBnG0XU0OcX7FXbqybiwoOU1VOzfYxiqI7uuA2Fuuw6SGrN5DY5HXaAEld3U9xaCSpsy_SGr5g qQGV2eeKXTfwtsLITZ3mUMvyHIbOlnc0cWriwkZgPB38L02zx.xImrPYPXrLCaO.9bSgd9e8qY8K s2xzGkZxIiRnjuhuXAMhCHX2bokDkNl75R4fL1qOAeq1F66hDlGMkQ.B9os3N5w.zipnaaIxKLGN IvO9ZmSfgclVmhuuPAlGcSi7TBRa0fOLGGaeCEVl6yia4dOwXubr3S5.FdaPZs1hdoF007yoTMk5 psY6qtTFy6Fys7XbElqT9gKcinjibJ6LHP9rLKuUsynmlRHgdcOv7OfSddJMc9oocYqo4zQHnSCH hgniFp.bCIWPwPm7G_qTG.25M_UIraMHAmeL89CD01sjuaJTpdMxbaM74QogvvWudQUu3RkAGuHu afA0gItpgfkW9NGotujA9S9WHwox_zlvEqRQu3x.dyE._VGf3WtRTW7xnszN33NrMhTdi Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 12 Jul 2018 13:34:00 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a5dfb848dc8c05f45d2906755df2006c; Thu, 12 Jul 2018 13:23:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 From: Mark Millard In-Reply-To: Date: Thu, 12 Jul 2018 06:23:49 -0700 Cc: FreeBSD Current , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> References: To: tech-lists X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 13:34:02 -0000 On 2018-Jul-12, at 2:44 AM, tech-lists wrote: > On 11/07/2018 17:21, Mark Millard wrote: >> It seems from the quoted material that neither kernel-toolchain nor >> build world was done before buildkernel . My understanding is that >> the intent is that one or the other be done first. (But for aarch64 >> currently only buildworld works.) >=20 > Thanks for this. I'm running a buildworld now. >=20 > For how long has it been the case that buildworld is needed for = buildkernel? Coming from amd64 and before that, i386, in situations = where I've only wanted to install a custom kernel, I was firstly used to = making and installing it from /sys/{i386,amd64}/conf. Then that broke a = number of years ago. Then got used to making kernel in /usr/src with = make buildkernel && make installkernel. And now this is broken, on = aarch64-arm64. Nobody knows if it's accidental or policy. It has been true since clang added use of stdint.h to the kernel build. Prior to this stdint.h was not needed to build the kernel for any architecture (as far as I know). As I remember, in C99 or later stdint.h is one of the headers required for a conforming freestanding implementation of C99+. stdint.h was added to C in C99. It was intended to be the subset of the older inttypes.h that was suitable for freestanding environments. inttypes.h is defined to include stdint.h for C99 and later as I remember (or to behave as-if it had?). https://www.freebsd.org/cgi/man.cgi?build(7) is very explicit about what is supposed to be the case relative to kernel-toolchain use: kernel-toolchain Rebuild the tools needed for kernel compilation. = Use this if you did not do a buildworld first. In other words: buildkernel is not intended to be = self-contained/sufficient according to the build documentation but buildworld should not be = required. Note the difference in the buildkernel and buildworld descriptions, = given the above: buildkernel Rebuild the kernel and the kernel modules. The = object directory can be changed from the default = /usr/obj by setting the MAKEOBJDIRPREFIX make(1) variable. vs. buildworld Build everything but the kernel, configure files = in etc, and release. The object directory can be changed = from the default /usr/obj by setting the = MAKEOBJDIRPREFIX make(1) variable. The actual build location = prefix used is ${MAKEOBJDIRPREFIX}${.CURDIR} for native = builds, and ${MAKEOBJDIRPREFIX}/${TARGET}${.CURDIR} for cross = builds and native builds with variable = CROSS_BUILD_TESTING set. Currently, overall, FreeBSD does not meet its own criteria for aarch64 = relative to kernel-toolchain . As far as I can tell the issue can be summarized relative to = kernel-toolchain by saying that kernel-toolchain does not currently establish a (full) freestanding C99 environment relative to the headers but clang requires (at least) one of the missing items ( stdint.h ) for aarch64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 12 18:32: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 4689C103134A; Thu, 12 Jul 2018 18:32:48 +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 CE46877ADC; Thu, 12 Jul 2018 18:32:47 +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 6F3285701C; Thu, 12 Jul 2018 20:32:39 +0200 (CEST) From: Dimitry Andric Message-Id: <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_538A729A-DF98-48DA-807D-508A89EBF62C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 Date: Thu, 12 Jul 2018 20:32:30 +0200 In-Reply-To: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> Cc: tech-lists , freebsd-arm , FreeBSD Current , FreeBSD Toolchain To: Mark Millard References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 18:32:48 -0000 --Apple-Mail=_538A729A-DF98-48DA-807D-508A89EBF62C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain = wrote: >=20 > On 2018-Jul-12, at 2:44 AM, tech-lists = wrote: >=20 >> On 11/07/2018 17:21, Mark Millard wrote: >>> It seems from the quoted material that neither kernel-toolchain nor >>> build world was done before buildkernel . My understanding is that >>> the intent is that one or the other be done first. (But for aarch64 >>> currently only buildworld works.) >>=20 >> Thanks for this. I'm running a buildworld now. >>=20 >> For how long has it been the case that buildworld is needed for = buildkernel? Coming from amd64 and before that, i386, in situations = where I've only wanted to install a custom kernel, I was firstly used to = making and installing it from /sys/{i386,amd64}/conf. Then that broke a = number of years ago. Then got used to making kernel in /usr/src with = make buildkernel && make installkernel. And now this is broken, on = aarch64-arm64. Nobody knows if it's accidental or policy. >=20 > It has been true since clang added use of stdint.h to the kernel = build. > Prior to this stdint.h was not needed to build the kernel for any > architecture (as far as I know). No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes , an intrinsics header, which in turn requires . This was introduced in https://svnweb.freebsd.org/changeset/base/308921, and at the time resulted in similar build failures, specifically when one attempted to build a new kernel, without building world or a new toolchain first. -Dimitry --Apple-Mail=_538A729A-DF98-48DA-807D-508A89EBF62C 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW0eevgAKCRCwXqMKLiCW o2PxAKDD0fu/b9FzE0adQQw7NOoggolVPgCfWlY233kbNrNJXnvnQCIFOD4OAhY= =e9Ml -----END PGP SIGNATURE----- --Apple-Mail=_538A729A-DF98-48DA-807D-508A89EBF62C-- From owner-freebsd-current@freebsd.org Thu Jul 12 18:58: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 BFBEB1034557 for ; Thu, 12 Jul 2018 18:58:13 +0000 (UTC) (envelope-from jhs@berklix.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 5BD79798F5 for ; Thu, 12 Jul 2018 18:58:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1A85B1034554; Thu, 12 Jul 2018 18:58:13 +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 079701034553 for ; Thu, 12 Jul 2018 18:58:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83D70798EB for ; Thu, 12 Jul 2018 18:58:11 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (pD9FA3756.dip0.t-ipconnect.de [217.250.55.86]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w6CIviDe025342 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2018 18:57:53 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w6CIviLT081356; Thu, 12 Jul 2018 20:57:44 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w6CIv7TX089208; Thu, 12 Jul 2018 20:57:24 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201807121857.w6CIv7TX089208@fire.js.berklix.net> To: Guy Helmer cc: current@freebsd.org cc: Diane Bruce Subject: Re: How to add su to /rescue ? From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Mon, 09 Jul 2018 14:13:40 -0500." <2ACD0DE9-3C43-48DE-BD5A-E074E1A4740E@gmail.com> Date: Thu, 12 Jul 2018 20:57:07 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 18:58:13 -0000 Guy Helmer wrote: > > On Jul 9, 2018, at 6:54 AM, Julian H. Stacey wrote: > > Hi current@ > > I want to add su to /rescue, but got stuck on pam. > > Old unix su didn't suffer from pam. > > There's no #define in su to turn off pam. > > Man src.conf says WITHOUT_PAM is deprecated & does nothing. > > > > Can someone please offer a solution ? > > Or better to include a simple BSD su pre pam ? > > I would happily develop a patch for that. > Hi, > Aside from not being able to use pam from a static executable, please don’t try to make the crunched hard-linked executable in /rescue setuid-root (su is useless without it). That would mean anyone running /rescue/sh gets a root shell :-) Thanks Guy ! Yes all SUID 0 would be very wrong. > Conceptually, a separate crunchgen binary could be made for setuid-root purposes, but having a setuid-root binary in /rescue (outside of the normal hierarchy) makes me nervous. In case other suid things are also needed later, I created a local src/rescue/suid/ with an old su.c pre PAM, Thanks to Diane Bruce, & a diff & Makefile to drive it. http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/rescue/ It works, but improvements welcome. Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich Brexit Referendum stole 3.7 million votes inc. 700,000 from British in EU. UK Goverment lies it's democratic in Article 50 paragraph 3 of letter to EU. http://exitbrexit.uk From owner-freebsd-current@freebsd.org Thu Jul 12 19:26: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 09BB7103A69B for ; Thu, 12 Jul 2018 19:26:01 +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 839F17B422 for ; Thu, 12 Jul 2018 19:26:00 +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 w6CJPrKR027566 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Jul 2018 12:25:53 -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 Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more To: freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> From: Yuri Message-ID: Date: Thu, 12 Jul 2018 12:25:52 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> 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.27 Precedence: 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, 12 Jul 2018 19:26:01 -0000 On 07/03/18 12:45, Yuri wrote: > I updated the laptop to r335884 last night, and 'service > wpa_supplicant start wlan0' doesn't succeed any more. > > kernel is supposed to create the network interface 'run0', but it > doesn't. This is the immediate reason why wpa_supplicant fails. > > The non-creation of 'run0' is a regression. I don't know of any > workaround. > > > The steps 'mergemaster -p' and 'mergemaster' were done during the > upgrade, so /etc is updated. Bug report for this problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 This is a very serious regression breaking WiFi. Yuri From owner-freebsd-current@freebsd.org Thu Jul 12 20:07: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 352C9103F5A0 for ; Thu, 12 Jul 2018 20:07:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-22.consmr.mail.gq1.yahoo.com (sonic311-22.consmr.mail.gq1.yahoo.com [98.137.65.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 2D00D7D22D for ; Thu, 12 Jul 2018 20:07:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: rm40ypUVM1nNNXMc5qhht29uIIVeK6g8VtwLjCllCZcpLOQ6Ml8cOrCZ3qzcYGA cBZc6qSqPawwK64Ib.46IvjG5xxX0W8Gb8XRNwRWqihFWkUHjNTW2hzBc6BQJZAe_fvYmuadxhUB IEs8kWmlM256WwqVNSqAEqzrcBE09GSzQLnqdqTJfmlWVGAqZsSu4X.ndsS8d6o315CTSsSqfjDv 8otGbWGLIRNVpns0Vi7LNOh.UP7WOEUxHJzsMv4HtTc5_3FomS0iodjiVeh1jA.vA1YJccIY6KMs Xgu56_Pqu31xqXrHMITm_lcgkHx8I9TQ89Vz1Zp8T16_3pGieAV_DavV7e_l7XWPslGNDXD1gGl0 OkYdjO3XqA8B8gSaqRpIJ9z3_6V7qem8aKSVDdlJ.ZWmJrMz88WWCbQ5Q.xrW.Npxb4LImfMPfN5 IsUuEEsliFMGN7fWs51KSfA4OxpgOOlmHHTmwnR7drg3wGbhMqjB0KEHq1MrMGpIXhLp_5oKjmSm LxoWZDoM8eSv3G4SAd4DsgI5qqBNSV5E3f9WiUT0BzPal3oRl8LuZK0y9lobAkGIISs2E7COALvS Mrd5XZg2Q8ryLP2rhOjyGIgNmjtO1Z8Vaz75nW7gY3QlPEBaGXEVvktzZtUBUWYDFnvpf5HUHcY6 WWaK9m4_f5szWm9QcDnfco.1Hc3rVLVDirzQsJsg2AspiUxJgR2Vuni0xLy.ex3idMV_2algS0oa FzqVbZO0rTke_cTwE0PgyNTbtIRATnx3UNlZwUXs1KXlilQ6epSMd3IVFn.t0AaQhIQtgBKfWby0 OTwF9ukLEwDGp7c7OZiFVFe7_Wr6Wr3anMAslWV1FPpNpfYJuYcTM6lKQzhDYjRVIECAnV8.0fpx ktLr5pX3NDXYJQVPWBS58vY.MIbIVqgsCL.cxMU0i6GyNtq_YzjV.VyL4PhJlfF_qGSa.Aj7cfIR rE8W2V4iBgLxQGT5.9zNZJspD9jk5zHz7Z67Gjv1fi7P9BnSrG6bTqrnsayEBw0hfqf5A Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 12 Jul 2018 20:07:35 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d319fa0f46a596cc767bf15d582c1f37; Thu, 12 Jul 2018 20:07:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 From: Mark Millard In-Reply-To: <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> Date: Thu, 12 Jul 2018 13:07:32 -0700 Cc: tech-lists , freebsd-arm , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3723A682-71BD-4654-9DCB-6FCBF12BEC49@yahoo.com> References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 12 Jul 2018 20:07:43 -0000 On 2018-Jul-12, at 11:32 AM, Dimitry Andric wrote: > On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain = wrote: >>=20 >> On 2018-Jul-12, at 2:44 AM, tech-lists = wrote: >>=20 >>> On 11/07/2018 17:21, Mark Millard wrote: >>>> It seems from the quoted material that neither kernel-toolchain nor >>>> build world was done before buildkernel . My understanding is that >>>> the intent is that one or the other be done first. (But for aarch64 >>>> currently only buildworld works.) >>>=20 >>> Thanks for this. I'm running a buildworld now. >>>=20 >>> For how long has it been the case that buildworld is needed for = buildkernel? Coming from amd64 and before that, i386, in situations = where I've only wanted to install a custom kernel, I was firstly used to = making and installing it from /sys/{i386,amd64}/conf. Then that broke a = number of years ago. Then got used to making kernel in /usr/src with = make buildkernel && make installkernel. And now this is broken, on = aarch64-arm64. Nobody knows if it's accidental or policy. >>=20 >> It has been true since clang added use of stdint.h to the kernel = build. >> Prior to this stdint.h was not needed to build the kernel for any >> architecture (as far as I know). >=20 > No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes > , an intrinsics header, which in turn requires . >=20 > This was introduced in = https://svnweb.freebsd.org/changeset/base/308921, > and at the time resulted in similar build failures, specifically when > one attempted to build a new kernel, without building world or a new > toolchain first. Sorry. I was distracted this morning and should have cross checked my claims instead of quickly babbling off the top of my head. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 12 20:38:41 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 5686810430F0 for ; Thu, 12 Jul 2018 20:38:41 +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 CB0547F031 for ; Thu, 12 Jul 2018 20:38:40 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-75-82-194-8.socal.res.rr.com [75.82.194.8]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id f01c30f1 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Thu, 12 Jul 2018 13:38:37 -0700 (PDT) Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more To: Yuri , freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> From: Pete Wright Message-ID: <83624f27-797d-6557-3f7e-8beac57c7d38@nomadlogic.org> Date: Thu, 12 Jul 2018 13:38:33 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: 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.27 Precedence: 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, 12 Jul 2018 20:38:41 -0000 On 07/12/2018 12:25, Yuri wrote: > On 07/03/18 12:45, Yuri wrote: >> I updated the laptop to r335884 last night, and 'service >> wpa_supplicant start wlan0' doesn't succeed any more. >> >> kernel is supposed to create the network interface 'run0', but it >> doesn't. This is the immediate reason why wpa_supplicant fails. >> >> The non-creation of 'run0' is a regression. I don't know of any >> workaround. >> >> >> The steps 'mergemaster -p' and 'mergemaster' were done during the >> upgrade, so /etc is updated. > > > Bug report for this problem: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 > > This is a very serious regression breaking WiFi. > sorry if i missed something (don't see details in the bug report) - is the issue that the run(4) kernel module is not being loaded?  is there an error when the system attempts to load the kernel module in the dmesg buffer?  if it is not being loaded automagically what happens when you manually load the module via "kldload" or by updating rc.conf? -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Jul 13 04:15: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 1C7DF104CF31 for ; Fri, 13 Jul 2018 04:15:47 +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 947547356D for ; Fri, 13 Jul 2018 04:15:46 +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 w6D4FiG6091643 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Jul 2018 21:15:45 -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 Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more To: Pete Wright , freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> <83624f27-797d-6557-3f7e-8beac57c7d38@nomadlogic.org> From: Yuri Message-ID: Date: Thu, 12 Jul 2018 21:15:43 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <83624f27-797d-6557-3f7e-8beac57c7d38@nomadlogic.org> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 04:15:47 -0000 On 07/12/18 13:38, Pete Wright wrote: > > sorry if i missed something (don't see details in the bug report) - is > the issue that the run(4) kernel module is not being loaded? is there > an error when the system attempts to load the kernel module in the > dmesg buffer?  if it is not being loaded automagically what happens > when you manually load the module via "kldload" or by updating rc.conf? No errors while the kernel module is loaded. The problem is that when the card is inserted wlan0 isn't automatically created. It also isn't created during boot with the card in. I think that there were some changes in devd that caused this regression. Yuri From owner-freebsd-current@freebsd.org Fri Jul 13 10:15: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 D6E21103244C; Fri, 13 Jul 2018 10:15:31 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 797D57E795; Fri, 13 Jul 2018 10:15:31 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 14A6D21FE5; Fri, 13 Jul 2018 06:15:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 13 Jul 2018 06:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=OippaRKapkCahOpgibX+QMrsj8rux X9DVzhDXdn4DBk=; b=CcIyeix5WyR1WXWVNWAJzgUSkbRMm7yiZraEuf/XiOmF9 FjoFw6fpb7kdFT1ITZeysTat4NmBozMgb0QqQi/Pk1OTrZILlvs23jsFa4hwQ6m0 SObHe4Q/2WRxEnKl1oCZh5f1N27kT1pV/QSiWzUIF/wjH3ldg621KnjKbcJVvDsy JBGqlRz5K29kK75JGUj4aBYVpHs86uQBHQiDQHg0C8DN95qfOUzQSmQWawOThpoo aFw+ntWkVpMS43HBiYMSn2spX4D0ryepuv60lx5xuRRXEYusp04aK6Z0szKPMtvK 19WFVXaZT8Yr8Y+2GR1RA1j8HYQnCKHIL9R65X37g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=OippaR KapkCahOpgibX+QMrsj8ruxX9DVzhDXdn4DBk=; b=HEv9AfKGy/2e/wguTFT+ZH +5lhtWKD+Y5JnMBBDz3Pnr0uorXnCxxAuroUq6XIxLyZrnLKQh6owWdC2oEVx0lw KmkZ65TQjTzTo48oxs1P8llBLYcVESbfzrzk8oDFLzEqRki62KHHZ4Q2MEDwQBeS eeflVOGNfp+Akzb7Eh8JJ5uhinlf0ZuGjIje+gJClvFgkvGtQdm+jk2N+5UgJ+4g eO68QmDef7xZX6fTsKnCDcNNoP0NhKr6xYZkuAqeP1TEcLax4TWLtMYTYiSkM7Be eTTR8zVsYuRxYIowEllOCZNNel9nbijp1vK7L6L+QxERiYbQO1yRRIImndpSH2Nw == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id E7F13E4636; Fri, 13 Jul 2018 06:15:23 -0400 (EDT) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 To: Dimitry Andric , Mark Millard Cc: freebsd-arm , FreeBSD Current , FreeBSD Toolchain References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> From: tech-lists Organization: none Message-ID: Date: Fri, 13 Jul 2018 11:15:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> 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.27 Precedence: 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, 13 Jul 2018 10:15:32 -0000 On 12/07/2018 19:32, Dimitry Andric wrote: > No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes > , an intrinsics header, which in turn requires . > > This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, > and at the time resulted in similar build failures, specifically when > one attempted to build a new kernel, without building world or a new > toolchain first. Hi, Ok, it's finished building and installing. The command I used was this: # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 and it all built, (so I'll close the PR I opened). Then I did make installkernel KERNCONF=RPI3 and because I thought might as well install everything now it's built, mergemaster -p and make installworld && mergemaster -Ui. So I take it then, that every time I want to build a kernel, I either have to do the above or use make kernel-toolchain. Is this correct? thanks, -- J. From owner-freebsd-current@freebsd.org Fri Jul 13 10:40: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 6E4E01033282; Fri, 13 Jul 2018 10:40:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE6D97F816; Fri, 13 Jul 2018 10:40:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkTSx-1gBcc21dSl-00cRqP; Fri, 13 Jul 2018 12:39:57 +0200 Date: Fri, 13 Jul 2018 12:39:56 +0200 From: "O. Hartmann" To: freebsd-acpi@freebsd.org, freebsd-current Subject: Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND Message-ID: <20180713123951.50440c9a@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:DEdGPyl0fMX00bmoT5fMEZ6UqY23rdSJ1gYXiFmRqeFwKRUz+SB qcs+97aiogNxFGLqqrdnK6BbxLMlg+TpMaVUBaJaykK9YzrcQ3DkALi7Q8vuzCL7wA9kg17 PnQkuKWfLxlPz24zOdpL2/WbFufv7An1G0CCk1KbYNVxMDEFNa/rWWZys6KoYyVI63bhQcV +HuZ1nAl8LAIKhSue7pPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:02SL6RqJ4C0=:S5CoCOGR37acVL94SBwJFY owiCmSP7d9htehKI7zu1/iPXReGcymt+akJRDc9Et6v4tIqkngmhbdRzGpL3gSz6RujnZ+ZyW nHBrS5wcdYK8xD7s6H6NlE+wFjIasS9dTrwFrOa2mQmTYyXmyMGy/jv0x+VGGGnNZ7G1NyQ48 gVgG8aM1jVAllULj0CkW14/2j+k17AUdqU5QHyAzhXB2/tlYqaXKCgU8rEgUxUshN2C0Y0glA vILx66CzqVfUEbqGq/SH1XSrqYfmBse4z0yKbt+/5px6E7UiUxuRFOije9/pMzVKzyW3tW9Nd UIhbcGXkrShxLhbPSacC4AtfL+DcGyFZhZpUm8wkDS6a9tavcWAbxkIbEXMmkzBFZX6ViV4Ng UxFMcz6+w8myJNZHHFMNZShV+8a+QAlrJIXDsJTxv+R4IHfC4J3U2Cw+28tdHLClBlbtW/I16 XXMPqObzrI2ZxoNRR0CBpDV7m2E2RqCFabz4LX1/FCHICbiyxJ4tiUTs7SOHwi7TH1SxRORIA igtcVw9/6WG6fV9EB34GAfBNBiCuE62h/9k0QkPpTpIq6M41om1Zn/q3uyBvKwVvAoelopjU2 GR2iFc8q4sZXP593f7elsBAXOFUeDdYx3/a++Quae7BofyJxKMBx9ZbWLO+XlPXZybB9M4tY6 6KRJXzYDSNd/peGwu8QhJlfgJevaYzFkzmhwPAQ55iwUBti97+vHy3B7TBCq0x0FcezPknrcn Hdlok1BFR/T/g2JPoO/fJENXQ6fwLNl7d9Z/qvJm9X1vwHtE1mOb3uHiq50zCwZMp5esAO79W F467HeQ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 10:40:07 -0000 Hello. The target host is a Fujitsu Esprimo Q956 Firmware V5.0.0.11 R1.26.0 for A3413-A1x Date 05/25/2018 BIOS Revision 1.26 FreeBSD 11.2-RELEASE and 12-CURRENT (ISO Image from 9th July 2018, r336134) are spamming the console with an annoying error: Jul 13 10:00:32 kernel: Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) Jul 13 10:00:32 kernel: ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND (20171214/psparse-677) Jul 13 10:00:32 kernel: Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) The error is repeated endless. Can this be fixed? Thanks in advance and kind regards, Oliver From owner-freebsd-current@freebsd.org Fri Jul 13 10:41: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 7D9431033384 for ; Fri, 13 Jul 2018 10:41:37 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 09CBE7F9FA for ; Fri, 13 Jul 2018 10:41:36 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7A196214; Fri, 13 Jul 2018 06:41:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 13 Jul 2018 06:41:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=daiipvtS9QDPjRMZSUCbOTRRqiGeN xKZCB/6taF5M6k=; b=F0Z3Tn+srbjJDn4hd0PBNhTOCPin0Nuop4U3HAztSMW+l cngNszOOgvYQQ4R6KRiJTAkSZDLmkaPzgjMc77kF/1XHg1i8RiYtCUYntvhYSA/z mpd05dftfYSYnfd35vsx8Jz25JhG6ZSQpcy/nEFu583hfHRDhF8dBAtqu0rKjQKw 5PT88UTwm3MGpO66jNSfvoKpBLcBYosiHPqI6Fwj1B+ga8iPzkaO1iAWMNNof4HE Qnd3UFqx3+eMufeGSbyWYdrQ6h+6wy97PKkyS0eBcMHgInESweHoxZKK3N1bls42 s2bhpizlBjmBZCLewj1gGKzui6Rj4dRJvB20weJ0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=daiipv tS9QDPjRMZSUCbOTRRqiGeNxKZCB/6taF5M6k=; b=wIXzB35nyub47b8K3z6yqr uEcxEvEBKX9qcy7OJz8V6hXAG/MXguR+HDe1aF1IYNMl+HxLS748V7JyZwdQy1eo wqlzVMgG16RqHU0CVixdJneTx+A6hWxL+5lEkqKhBZhIuSdF6hTeDzz9Agy65qUS zLcJYwoIGvVi//smpdGKxtPt9yBFKzZ1616dRvFDBsKa7AAJO3Q/h72GfrrObZL4 LGkorjqnzbuPHugwmg7uqmqfFpCetuvBxhVRQ84Fpr65zRoxIGznjRHBuCUItBj/ hTMatPBYlgt6GVm09jlhfW8ZIEYWAosIHbTZxgcZ7QUdv9CVS5t0YBaLupoShVUA == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.100.208]) by mail.messagingengine.com (Postfix) with ESMTPA id 903C5E48FF; Fri, 13 Jul 2018 06:41:33 -0400 (EDT) Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more To: Yuri , freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> From: Yuri Pankov Message-ID: Date: Fri, 13 Jul 2018 13:41:32 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.27 Precedence: 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, 13 Jul 2018 10:41:37 -0000 Yuri wrote: > On 07/03/18 12:45, Yuri wrote: >> I updated the laptop to r335884 last night, and 'service >> wpa_supplicant start wlan0' doesn't succeed any more. >> >> kernel is supposed to create the network interface 'run0', but it >> doesn't. This is the immediate reason why wpa_supplicant fails. >> >> The non-creation of 'run0' is a regression. I don't know of any >> workaround. >> >> >> The steps 'mergemaster -p' and 'mergemaster' were done during the >> upgrade, so /etc is updated. > > > Bug report for this problem: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 > > This is a very serious regression breaking WiFi. It's likely the switch from using usb.conf to devmatch.conf (see r329148). I can confirm the problem, inserting the ralink usb wifi dongle doesn't do anything (I'm not using it anymore so I didn't notice the problem), though the action in devmatch.conf is executed, so it might be the problem somewhere below in devmatch(8). From owner-freebsd-current@freebsd.org Fri Jul 13 11:00: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 DFD881033D91 for ; Fri, 13 Jul 2018 11:00:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B89C80223 for ; Fri, 13 Jul 2018 11:00:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LtIZH-1g2vdJ23nH-012sEy for ; Fri, 13 Jul 2018 13:00:02 +0200 Date: Fri, 13 Jul 2018 13:00:01 +0200 From: "O. Hartmann" To: freebsd-current Subject: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:r1ivH10fWqe+xZnUId6MtXowSRrTOx4eOG3TEa78rbE7ranJoWE d9HhUJPQkaGn6qGr6H2iYQdTOd+u48egNX07WpwSClCxSz13fZgy0sn22HCm7bPRK6Asgnp ftuUpPIQXOiOSy9qet9MvfUf3rCqPSlk0I61bMKwuYmd4P1QbAj8uGzdUa98RreOg1SoyUp ZQeKfASvUL+u2vqUfsItg== X-UI-Out-Filterresults: notjunk:1;V01:K0:VJlegpgL9is=:JnwGe4JAkbLtz2v5Vs9nzC ujrERmwmYCa5e96MKQfUmI0rGli6DCf9FC7DJUkNvpBcwaXElV5g3f4DJhsg2QvFiM5XiSrcS xV5zQSyeNubzVg/QntUcUha32ePQESzXowjbu2yuNgnQZxevFKATcUhkMq2/o5R4UbEJgw0Fz dJiqJs5nwN/eedpJRYQkhdqwQ7WFrNS0zoKa27dkJ4DpfgAOBvfN5c2UicI9ujq+vyL3Q2kvu HD61SYavTgZBXX8A1PFui80aNpiFLGGJwTtMxFqkq5HZaAxrxrqu/L7oQGVzpbT8BVaGXE7f/ tYJ5orl1QqXSHD2hu7Kucm0DAtRSOp08D2UOqEObOl+48eXUE8+LvdIIGZwGpQzwl89izAa5l zeNISRuPKq6jskIlIyXe01/YyCDcGC3mSWvoRvQtxCg2C0Vo7lDmCVwRndXaCURzGWWgJSPY6 GH1/GRALKC91KTNTJZRlZqEY7/rqnsEtEaBud1EKo5PRhjfLUQsQIuHm5PsrgGyYz3fgbD9Zq 8D2f55ZbXJ4BOtbK9S0GnEL+Tvz84OkuM7XwIb5vTOSBq3yABPNYOITkk2Kl1Irm/zXK1pn2+ luhh39c7DHF0zQmhYuf6kVrU6ifE/6qA7VrgJ9mLBKnOoZwdUbSK5PGocig1f/XYrNkKAX7+b OYxRepuMQ7p5M0PAwuERZ4gbVvaNBXkIEyh5x5/Qm2rCdhjQx4tPdSBXq20k6+Q350HmZlml8 Vf9arHFlr6SiTiB2+S1wVUvl9hYHFp1vweS7mx7fSwi1e0pcvrhu1G4Odrb9Pe7p9thQGIHMj rfKA4ec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 11:00:11 -0000 The problem is some kind of weird. I face UEFI boot problems on GPT drives where the first partition begins at block 40 of the hdd/ssd. I have two host in private use based on an outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LGA1155). Both boards are equipted with the lates official available AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision for the Spectre/Meltdown mitigation is available, but I didn't test that. But please read. The third box I realised this problem is a brand new Fujitsu Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 20180525). Installing on any kind of HDD or SSD manually or via bsdinstall the OS using UEFI-only boot method on a GPT partitioned device fails. The ASRock boards jump immediately into the firmware, the Fujitsu offers some kind of CPU/Memory/HDD test facility. If on both type of vendor/boards CSM is disabled and UEFI boot only is implied, the MBR partitioned FreeBSD installation USB flash device does boot in UEFI! I guess I can assume this when the well known clumsy 80x25 char console suddenly gets bright and shiny with a much higher resoltion as long the GPU supports EFI GOP. Looking with gpart at the USB flash drives reveals that the EFI partition starts at block 1 of the device and the device has a MBR layout. I haven't found a way to force the GPT scheme, when initialised via gpart, to let the partitions start at block 1. This might be a naiv thinking, so please be patient with me. I do not know whether this is a well-known issue. On the ASRock boards, I tried years ago some LinuxRed Hat and Suse with UEFI and that worked - FreeBSD not. I gave up on that that time. Now, having the very same issues with a new Fujitsu system, leaves me with the impression that FreeBSD's UEFI implementation might have problems I'm not aware of. Can someone shed some light onto this? Thanks in advance, Oliver From owner-freebsd-current@freebsd.org Fri Jul 13 11:04:12 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 C1F1610341EC for ; Fri, 13 Jul 2018 11:04:12 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 574BF80666 for ; Fri, 13 Jul 2018 11:04:12 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 26DF6336; Fri, 13 Jul 2018 07:04:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 13 Jul 2018 07:04:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=s1eMMaVIydMvNqJZIjG4GT4XtZmY5 oUOW5s6zuUo6O0=; b=sjWYRDDjRHTvCzrvvxdWK6aQ08dbsZ/G69dk9uTB2mkHt lGtsDjktB6t9YZigmqJKbh/z3BrQ/ALPEKdRBKE51uZiyhT55MCdqYM9/ttB62L5 ykCZXnITudmNv/aqKKU7gts3+xKJK3Nif8o0QCC6NLRgf1ON77mdNlRPSL5vzjDo qoBJGjw4VMSHbx/wRBNxxiDm5viS62wOc+geoNeDrjQdsX0Sr+5QCsLxneQq9R/J hfrK8iaE0pSiCXhidjckauOmfriDr7BXi4ifIg2+hE0nk4qepEQUbKEdqac5fKLD VL9FwnPPDCVFjAcOMWFODFq02YcXZlHT82InBNXJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=s1eMMa VIydMvNqJZIjG4GT4XtZmY5oUOW5s6zuUo6O0=; b=lp1rsYCBDJFjqx0Q/oU0S2 hm0JSqItspf6VoE/l6KLrZcnvE/ySL2b8qFONUmyyrf6AIOql4DabjEOKw0RBZ/m /VYKHtb+EQu/auLXAXmmG9lxizkTJwH0G7IH0ToT+L5x8p8AM2ajz0BfLBPFYO++ 8JKU2kd7Bh2r42MT4yl6SIPvHbScILlKj6jqvRyZwlSr4VslE8/NqJec/oKACQCV fkxdsM2ZykSYDdtUvfJ267HAKA0YEGtIqfzXG+jLykKRBHSQ+f3uYd2DUu8OBkRR uk3r/tKKIPJmgsb4K9cWHpcmfB6BuWLWm0AxYpitA2Y6O2VbGaj971/OGWwglEQQ == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.100.208]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C919E49E9; Fri, 13 Jul 2018 07:04:08 -0400 (EDT) Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more From: Yuri Pankov To: Yuri , freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> Message-ID: <963c38fb-1c08-62bc-198d-309953c39eb1@yuripv.net> Date: Fri, 13 Jul 2018 14:04:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.27 Precedence: 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, 13 Jul 2018 11:04:13 -0000 Yuri Pankov wrote: > Yuri wrote: >> On 07/03/18 12:45, Yuri wrote: >>> I updated the laptop to r335884 last night, and 'service >>> wpa_supplicant start wlan0' doesn't succeed any more. >>> >>> kernel is supposed to create the network interface 'run0', but it >>> doesn't. This is the immediate reason why wpa_supplicant fails. >>> >>> The non-creation of 'run0' is a regression. I don't know of any >>> workaround. >>> >>> >>> The steps 'mergemaster -p' and 'mergemaster' were done during the >>> upgrade, so /etc is updated. >> >> >> Bug report for this problem: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 >> >> This is a very serious regression breaking WiFi. > > It's likely the switch from using usb.conf to devmatch.conf (see r329148). > > I can confirm the problem, inserting the ralink usb wifi dongle doesn't > do anything (I'm not using it anymore so I didn't notice the problem), > though the action in devmatch.conf is executed, so it might be the > problem somewhere below in devmatch(8). And looks like it's fixed in r335763 (for me, at least). From owner-freebsd-current@freebsd.org Fri Jul 13 11:10: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 EF034103486D; Fri, 13 Jul 2018 11:10:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C58C8092F; Fri, 13 Jul 2018 11:10:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id D4FBF3B7; Fri, 13 Jul 2018 14:10:29 +0300 (MSK) To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Reply-To: lev@FreeBSD.org From: Lev Serebryakov Subject: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT) Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> Date: Fri, 13 Jul 2018 14:10:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EBIXtxr7rVoRcdPZi3HEwbyOgHHm6nemK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 11:10:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EBIXtxr7rVoRcdPZi3HEwbyOgHHm6nemK Content-Type: multipart/mixed; boundary="PcwgMvgnizSgzT5hBe2ScY4L07u5LCvUp"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> Subject: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT) --PcwgMvgnizSgzT5hBe2ScY4L07u5LCvUp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs CURRENT for very long time (from 11-CURRENT times), and recently it start to consume much more CPU on same traffic =E2=80=94 to the point whe= n it becomes unresponsive in shell (via ssh, not local console). I have rather complex ipfw ruleset, but this ruleset is the same for many years. Revisions before r333989 worked normally, I never seen any problem with shell, no matter how much traffic is processed Revision r334649 with same configuration, same firewall ruleset, etc., becomes completely unresponsive under network load (pure transit traffic)= =2E when system is unresponsive I see this in `top -SH` 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1} 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0} And it is new to me. --=20 // Lev Serebryakov --PcwgMvgnizSgzT5hBe2ScY4L07u5LCvUp-- --EBIXtxr7rVoRcdPZi3HEwbyOgHHm6nemK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAltIiKRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R4+XbBAAheeXBurSySuoii2PY9Wdbd/tYFmPcrmAEZR6R4vplpz5NOpt7OV8eBm9 3wDsAS4g3DizVTOnxdm+3Z6k4x3S2I4sxGXCvUIGMbp66o6cwbm3jRjLNi6Dy5o8 tNNrhfsrfUZZW/ntNjKF+iccukRPZzqRyREgIT6us4sQy7idXNzmY7NjjLcm7JDG 54ZQsKCLNgd4CufMeS0jMyLCHANExzGVk+dKtEwjUwOUM76Ow3AFbCBMgIz5ZmaP QGimmKQmJsqfz8+hayWwest9nZFSAdTUwJ97MylXHhkN9XeKK6OIwYVWq7S2HqVD S/GZ3e1TdD+mhFMCOoQ7eCJtZhn7M8weuDEHVKsuEmA8Rdau7RYEw8mACjff6xaA /Ry1FSNhZLJM+b5HrzACu70Jwt7hf+WY+gTp5Juu1B8Tx5wg0FGmxxbg4Eje4E4B WYN1eBswDmktemoI4ZRp0QHf9Z4FRnK6k4Eizx1uvScnZ1Ado4sUqR6YKwumtNjx nGv/0RxxMngB3XmWRswNFKDKfJCD5YwNhVLUBqmB7kg7yNyr9EzK8BuTuCOVcpVJ jyVc/iFgHnsV3W/5OZ2f8nGZ4kmmz6EeWYq3akSBTbTboAlt6EodGh/gyxAlj6v8 65UbS3o/cAgD8rXoC1XbrCOnCPn/ZXlzEAcOd/7w9DvLiZCyL5Q= =whTC -----END PGP SIGNATURE----- --EBIXtxr7rVoRcdPZi3HEwbyOgHHm6nemK-- From owner-freebsd-current@freebsd.org Fri Jul 13 11:28:36 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 5FF371035116; Fri, 13 Jul 2018 11:28:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE400812AF; Fri, 13 Jul 2018 11:28:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 4686A3BB; Fri, 13 Jul 2018 14:28:35 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT) From: Lev Serebryakov To: freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <4cfd6e7f-6da3-5248-4d39-4d08e491b233@FreeBSD.org> Date: Fri, 13 Jul 2018 14:28:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FRb8MdIhvWmNvqWat3zxY9dB7Sqvq40ma" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 11:28:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FRb8MdIhvWmNvqWat3zxY9dB7Sqvq40ma Content-Type: multipart/mixed; boundary="XacfbG67KtmwrPjzzpNtQ40DgaZwoUZDE"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <4cfd6e7f-6da3-5248-4d39-4d08e491b233@FreeBSD.org> Subject: Re: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT) References: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> In-Reply-To: <6d8b301b-8ee9-0e8b-80b5-6aced15ca843@FreeBSD.org> --XacfbG67KtmwrPjzzpNtQ40DgaZwoUZDE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 13.07.2018 14:10, Lev Serebryakov wrote: > when system is unresponsive I see this in `top -SH` >=20 > 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1= } > 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0= } >=20 > And it is new to me. Oh, this MoBo has (and uses) two em0 adapters: em0@pci0:2:0:0: class=3D0x020000 card=3D0x202c8086 chip=3D0x10d38086 rev=3D= 0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82574L Gigabit Network Connection' class =3D network subclass =3D ethernet em1@pci0:1:0:0: class=3D0x020000 card=3D0x202c8086 chip=3D0x10d38086 rev=3D= 0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82574L Gigabit Network Connection' class =3D network subclass =3D ethernet --=20 // Lev Serebryakov --XacfbG67KtmwrPjzzpNtQ40DgaZwoUZDE-- --FRb8MdIhvWmNvqWat3zxY9dB7Sqvq40ma Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAltIjOJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R49YkBAAhVKDXUV0b8AC6DrxUCbbzhNyCwccrTMLzzkBn2c72YQhQPmGzO8TkuFT 0zxAsGwtKUgh/tjV4KM4EL7aMJWSPTjW5Zs2zmgRUoC/MuFT9wTFeGhm1Pze6F+H lNmTpN6rLopFjnKQWjcr8TzTtbaWYINvJJ9FFAYGjrGlxeb5DsObqvtTEyZqfzkD i5yu/xzcGWP8Do3XS5lZ2V6rfik7x5SsKcAUUkPsdZE8ZedZJv4dQoPYEqPhYXHi 3ytXGn+mIuPWtsZ5fbjlLMuRGoGSaSXrgL1kN0LV7oowFqVGYImYkPUuNc3ckfZc wLYeHMuYJ6TduFZFufAKDqBuwY5tZytGTlhsEIpgTE0hZeBMujhxdga2G51cNM1h tuOTwEsoahEVUk8K0SNBhTzvGtXEwUnqAfy3N8TBCM38E6ASz01rmIr2wItV5/Ry YS6V7wzcD6ML/+X9+P36Y9lYnYAFd8PAbUttUbGXnDcPyXTu52ky/6DX2YYGZroI layYSvuqv/DcMufVvmT/xuVuRTL3xtxdzZ8QaEzKW9mdY5GGugzf3wus6lDvDiBZ 13w0AcESu+6XSDAlZ/vMb3IMBQFPMHLh8TvU/xCxcF5GsUP3EB6daCh4vKMbZy5T eetgjXrZFQdjyvNQ/ZtbpfqqNoFRqQeH7Nyn3WjEDbJvioQCjlM= =QEPu -----END PGP SIGNATURE----- --FRb8MdIhvWmNvqWat3zxY9dB7Sqvq40ma-- From owner-freebsd-current@freebsd.org Fri Jul 13 12:14: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 686991039DB6 for ; Fri, 13 Jul 2018 12:14:09 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) 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 079AA82FC4 for ; Fri, 13 Jul 2018 12:14:09 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: by mailman.ysv.freebsd.org (Postfix) id B71AF1039DB5; Fri, 13 Jul 2018 12:14: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 A466A1039DB4 for ; Fri, 13 Jul 2018 12:14:08 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: from smtp.kcbark.net (static-212-247-41-80.cust.tele2.se [212.247.41.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A3FD82FC3 for ; Fri, 13 Jul 2018 12:14:07 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: from [100.89.91.61] (m83-185-91-61.cust.tele2.se [83.185.91.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.kcbark.net (Postfix) with ESMTPSA id 6096366E6F for ; Fri, 13 Jul 2018 14:13:53 +0200 (CEST) From: Kalle Carlbark Mime-Version: 1.0 (1.0) Date: Fri, 13 Jul 2018 14:13:52 +0200 Subject: HD Audio Emulation For Bhyve Message-Id: <8EA0050D-E83E-4DB0-9ADD-A1EE485BCFC9@kcbark.net> To: current@freebsd.org X-Mailer: iPhone Mail (15F79) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 12:14:09 -0000 Hi! First post to the mailing list.=20 I was trying out the https://reviews.freebsd.org/D12419 on a recent FreeBSD c= urrent (>=3D 336229) but didn=E2=80=99t get it to work using debian 9 as a g= uest. Mpg123 just hangs when trying to play a mp3. Also tried Ubuntu 18 but t= hat just hangs at boot time at =E2=80=9CDetecting sound card=E2=80=9D. I=E2=80= =99ve compiled bhyve WITHOUT_CAPSICUM but that doesn=E2=80=99t seem to solve= anything. Also built with DEBUG_HDA and that doesn=E2=80=99t output any err= ors. Sound works just fine on the host system. Any hints? Thanks!=20 From owner-freebsd-current@freebsd.org Fri Jul 13 12:18:30 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 3767B103A094 for ; Fri, 13 Jul 2018 12:18:30 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2B688322B; Fri, 13 Jul 2018 12:18:29 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Fri, 13 Jul 2018 14:17:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1531484308; bh=IkmhXigHm5LJewzWzw5JBSnJvCwdFOeVAbmL+hTy9s0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gQ++U1RXyWENj+DRnUX+PtDC3sCUYaIkFc+3UvTctchBBdhpS5BPK0tPCFk8kAwu+ LYoNeoyqR/0rugDF/icWWc644zDvN36EebTOkTHoGDAHjmoiMNsgA5BFCQcx7kC/pI QJo7fjsDhzPeayAPtOni7K5Ws/A17iVzV72uAsGp5d1aAQOPC1dG/0FxhfQHjPoEYi sEGXrSrDD260AVHeYVZspQQsSYdCtu58rnEwTGf4KyBGj9SK4KUFVokG30/VBFy7M+ hjGHsf8aNCTSUyQcYwLjhvvx3t4/9OPL3pUHgfQCfwVWnc3Uh6b0q4q58f2SKcffWd p1zaGtCQzR1hg== Message-ID: <20180713141756.Horde.fBMrBpf878-dzloMbGlo6N1@webmail.leidinger.net> From: Alexander Leidinger To: Andriy Gapon Cc: freebsd-current@freebsd.org Subject: Re: Deadlocks / hangs in ZFS References: <20180522101749.Horde.Wxz9gSxx1xArxkYMQqTL0iZ@webmail.leidinger.net> <20180522122924.GC1954@zxy.spb.ru> <20180522161632.Horde.ROSnBoZixBoE9ZBGp5VBQgZ@webmail.leidinger.net> <20180522144055.GD1954@zxy.spb.ru> <20180527194159.v54ox3vlthpuvx4q@jo> <20180527220612.GK1926@zxy.spb.ru> <20180528090201.Horde._E4JZcuEaZHfj_BNzWjci2O@webmail.leidinger.net> <20180603211450.Horde.pI-Fom6S1tUcaHvTF4MUjin@webmail.leidinger.net> <20180603192814.GP1926@zxy.spb.ru> <20180604223108.Horde.RcVquaVKWdNzNidD_5aJz7E@webmail.leidinger.net> <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> <6254a3ca-6740-c1b2-7125-7ac8a708e757@FreeBSD.org> In-Reply-To: <6254a3ca-6740-c1b2-7125-7ac8a708e757@FreeBSD.org> User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_ff_UE6Lfku4ucr9Di3iH_kZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 12:18:30 -0000 This message is in MIME format and has been PGP signed. --=_ff_UE6Lfku4ucr9Di3iH_kZ Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Andriy Gapon (from Fri, 13 Jul 2018 14:50:48 +030= 0): > On 12/07/2018 15:42, Alexander Leidinger wrote: >> #9=C2=A0 0xffffffff81391fbe in arc_check_uma_cache (lowest=3D-1011712) >> =C2=A0=C2=A0=C2=A0 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/f= s/zfs/arc.c:4532 > > Do you have any local modifications to ZFS code? Yes, this is with https://reviews.freebsd.org/D7538 Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_ff_UE6Lfku4ucr9Di3iH_kZ Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbSJh0AAoJEKrxQhqFIICEIKEQAItCCvKViucKffxXHzMKdB2K 9VHUJrcmzkKqT2Tn9vdwEwMl0WkdMcTb4ovTmita5KBsz9UY43g+o5Trdt/pkDCL O5khidrov//bDdPEX260bTfH9oBiJ0LTTnmu/MZ43S7JiffR8d6lGOcEQpwg3kLG 0wLqYiKE2TzfG9IKcdsjsvBVsD/HoSuyN6axQ4fpucUZzhlveD9qfGOpZr1Z5RD4 5aBMTrVFFd+B0vogj2Pm0sAwVlfSk3TgMEfanYENCFoO+cNmApBApHpiiIE8AwCN tNjianfHidjClzV+ry7WcmhggajxNUfP1j+Af2E7CNmcdpDjlmpQG2Cc2Qw6hMEh rEHmQu3iBnw5W1t4LPWK40V8ovj5fTBlWu6pI6E9oXkzaUp70s3Kl5cJUwW32k8w F4Di46i2LSWiPKR+rS7qlHUUSvVa8Xk5At/uLUBlWxhd0gNFw4r/HjErN6Ug6/iB QigoEPGv3ylzDVYae/IiJVG4Vw8wgdAoTh1K1w2r2hDCrnRGMR/VZlgMLwpBE0v6 lyk2GllbQXXLQsFJWdBRYIKxR9Fp7RHTOI1iZOt1WQOSmX6w9zqIXNqEgSv8TQFM P9G0ejxq7VeYMwT4IKVVmLknKTOe8MAtDPlfYl1bDZF5yWLbEPBaKDb+hzFOtg2s 9gmY4HR/yzD/JnZ1+D76 =V8os -----END PGP SIGNATURE----- --=_ff_UE6Lfku4ucr9Di3iH_kZ-- From owner-freebsd-current@freebsd.org Fri Jul 13 12:27: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 A013F103A714 for ; Fri, 13 Jul 2018 12:27:17 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 489E383971 for ; Fri, 13 Jul 2018 12:27:17 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PBS00400XWS0600@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Fri, 13 Jul 2018 11:26:56 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PBS002V6YGSRF40@st13p35im-asmtp002.me.com>; Fri, 13 Jul 2018 11:26:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-07-13_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807130089 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> Date: Fri, 13 Jul 2018 14:26:51 +0300 Cc: freebsd-current Content-transfer-encoding: quoted-printable Message-id: <68505F98-E840-4148-9E48-BDB350F7431A@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 12:27:18 -0000 > On 13 Jul 2018, at 14:00, O. Hartmann wrote: >=20 > The problem is some kind of weird. I face UEFI boot problems on GPT = drives > where the first partition begins at block 40 of the hdd/ssd. >=20 > I have two host in private use based on an > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket = LGA1155). > Both boards are equipted with the lates official available AMI = firmware > revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 = (2013/7/23) > and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA = revision > for the Spectre/Meltdown mitigation is available, but I didn't test = that. But > please read. >=20 > The third box I realised this problem is a brand new Fujitsu Esprimo = Q956, also > AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or = 20180525). >=20 > Installing on any kind of HDD or SSD manually or via bsdinstall the OS = using > UEFI-only boot method on a GPT partitioned device fails. The ASRock = boards jump > immediately into the firmware, the Fujitsu offers some kind of = CPU/Memory/HDD > test facility. >=20 > If on both type of vendor/boards CSM is disabled and UEFI boot only is = implied, > the MBR partitioned FreeBSD installation USB flash device does boot in = UEFI! I > guess I can assume this when the well known clumsy 80x25 char console = suddenly > gets bright and shiny with a much higher resoltion as long the GPU = supports > EFI GOP. Looking with gpart at the USB flash drives reveals that the = EFI > partition starts at block 1 of the device and the device has a MBR = layout. I > haven't found a way to force the GPT scheme, when initialised via = gpart, to let > the partitions start at block 1. This might be a naiv thinking, so = please be > patient with me. >=20 > I do not know whether this is a well-known issue. On the ASRock = boards, I > tried years ago some LinuxRed Hat and Suse with UEFI and that worked - = FreeBSD > not. I gave up on that that time. Now, having the very same issues = with a new > Fujitsu system, leaves me with the impression that FreeBSD's UEFI > implementation might have problems I'm not aware of. >=20 > Can someone shed some light onto this?=20 >=20 The first thing to check is if the secure boot is disabled. We do not = support secure boot at all at this time.=20 If you have efi or bios version running - you can check from either = console variable value (it can have efi or vidconsole or comconsole) or = better yet, see if efi-version is set (show efi-version) - if = efi-version is not set, it is BIOS loader running. Another indirect way = is to see lsdev -v, with device paths present, it is uefi:) GPT partitions can never start from disk absolute sector 1; this is = because at sector 0 there is MBR (for compatibility), sector 1 is GPT = table and then sectors 2-33 have GPT partition table entries, so the = first possible data sector is 34 (absolute 34). Thats assuming 512B = sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. rgds, toomas From owner-freebsd-current@freebsd.org Fri Jul 13 12:45: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 3B913103B3E9 for ; Fri, 13 Jul 2018 12:45:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 9675984832 for ; Fri, 13 Jul 2018 12:45:51 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f170.google.com with SMTP id v9-v6so14126690ljk.4 for ; Fri, 13 Jul 2018 05:45:51 -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:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CF79ZWV4FY88V1d6M9GUMzj9m1a8t4Q+AXUssYQV/jc=; b=V9l1uqZ+2juQkaHYmbilEu0BziqQYaDa7i+P9bxFdKhJTLc6JyE9cGftnIqKWQVElp czmyHqYErN84wIcEr2OXv/on8topIZrnaH8fvOLyM6xhRSD/J2ynoyQymHjbDmNB0DpV Y1lDLb3x8JgwiEcWQ8muMy62EjJqPNnhTtFzJwuiNh/1ogrqOlWpxK4FaS5IdE/5aFq6 NWj7w6deEKIDl6iwd7NfSHKJlrQdj/aLyA7nyTE/RK5WB7zGN/tW0ICm9/kEIhEeszyN GHq5B9ZL6ZxXgsI4u24BOkLAZSzEby/uTye9aFwzhQUL5+0ON4zwiUXBYWXiTsiuYey3 iJzA== X-Gm-Message-State: AOUpUlE8Oez43oV1Jb5u0QvEzc3OFjyGeVKO5y6Z4wyRq/vRTFj/tP65 5ez+poARd2tfqScQ0itJtq9yN38Y X-Google-Smtp-Source: AAOMgpf5Ae8Ql+Q/Qwi+bldXkI/kV3lQ33F0dV6qKgUFO2SVGV9ROwHiaxZOebKIB4dGC4jJGGNusQ== X-Received: by 2002:a2e:9854:: with SMTP id e20-v6mr2935491ljj.143.1531482649482; Fri, 13 Jul 2018 04:50:49 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id x21-v6sm6623216lfe.70.2018.07.13.04.50.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 04:50:48 -0700 (PDT) Subject: Re: Deadlocks / hangs in ZFS To: Alexander Leidinger , freebsd-current@freebsd.org References: <20180522101749.Horde.Wxz9gSxx1xArxkYMQqTL0iZ@webmail.leidinger.net> <20180522122924.GC1954@zxy.spb.ru> <20180522161632.Horde.ROSnBoZixBoE9ZBGp5VBQgZ@webmail.leidinger.net> <20180522144055.GD1954@zxy.spb.ru> <20180527194159.v54ox3vlthpuvx4q@jo> <20180527220612.GK1926@zxy.spb.ru> <20180528090201.Horde._E4JZcuEaZHfj_BNzWjci2O@webmail.leidinger.net> <20180603211450.Horde.pI-Fom6S1tUcaHvTF4MUjin@webmail.leidinger.net> <20180603192814.GP1926@zxy.spb.ru> <20180604223108.Horde.RcVquaVKWdNzNidD_5aJz7E@webmail.leidinger.net> <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <6254a3ca-6740-c1b2-7125-7ac8a708e757@FreeBSD.org> Date: Fri, 13 Jul 2018 14:50:48 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 12:45:52 -0000 On 12/07/2018 15:42, Alexander Leidinger wrote: > #9  0xffffffff81391fbe in arc_check_uma_cache (lowest=-1011712) >     at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 Do you have any local modifications to ZFS code? I cannot find that function. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Jul 13 13:19: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 E35B9103C373 for ; Fri, 13 Jul 2018 13:19:53 +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 5ECFE85A7D for ; Fri, 13 Jul 2018 13:19:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1fdxz4-0006XS-DU; Fri, 13 Jul 2018 16:19:42 +0300 Date: Fri, 13 Jul 2018 16:19:42 +0300 From: Slawa Olhovchenkov To: Alexander Leidinger Cc: freebsd-current@freebsd.org Subject: Re: Deadlocks / hangs in ZFS Message-ID: <20180713131942.GA30893@zxy.spb.ru> References: <20180522122924.GC1954@zxy.spb.ru> <20180522161632.Horde.ROSnBoZixBoE9ZBGp5VBQgZ@webmail.leidinger.net> <20180522144055.GD1954@zxy.spb.ru> <20180527194159.v54ox3vlthpuvx4q@jo> <20180527220612.GK1926@zxy.spb.ru> <20180528090201.Horde._E4JZcuEaZHfj_BNzWjci2O@webmail.leidinger.net> <20180603211450.Horde.pI-Fom6S1tUcaHvTF4MUjin@webmail.leidinger.net> <20180603192814.GP1926@zxy.spb.ru> <20180604223108.Horde.RcVquaVKWdNzNidD_5aJz7E@webmail.leidinger.net> <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712144229.Horde.D_-hM4wiiKjbsuR-VROmvkZ@webmail.leidinger.net> 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.27 Precedence: 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, 13 Jul 2018 13:19:54 -0000 On Thu, Jul 12, 2018 at 02:42:29PM +0200, Alexander Leidinger wrote: > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) bt > #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366 > #2 0xffffffff80485e11 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:446 > #3 0xffffffff804863f3 in vpanic (fmt=, ap=0xfffffe0000457870) > at /usr/src/sys/kern/kern_shutdown.c:863 > #4 0xffffffff80486443 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:790 > #5 0xffffffff8075279f in trap_fatal (frame=0xfffffe0000457a50, > eva=32) at /usr/src/sys/amd64/amd64/trap.c:892 > #6 0xffffffff80752812 in trap_pfault (frame=0xfffffe0000457a50, > usermode=) > at /usr/src/sys/amd64/amd64/trap.c:728 > #7 0xffffffff80751e1a in trap (frame=0xfffffe0000457a50) at > /usr/src/sys/amd64/amd64/trap.c:427 > #8 > #9 0xffffffff81391fbe in arc_check_uma_cache (lowest=-1011712) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 > #10 arc_reclaim_thread (unused=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4657 > #11 0xffffffff8044ca74 in fork_exit (callout=0xffffffff81391b90 > , arg=0x0, > frame=0xfffffe0000457c00) at /usr/src/sys/kern/kern_fork.c:1057 > #12 > (kgdb) up 9 > #9 0xffffffff81391fbe in arc_check_uma_cache (lowest=-1011712) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 > 4532 lowest += > uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone); > (kgdb) list > 4527 int iter = 4; > 4528 int step = 1 << (SPA_MAXBLOCKSHIFT > - SPA_MINBLOCKSHIFT - 3); > 4529 int n = (SPA_MAXBLOCKSIZE >> > SPA_MINBLOCKSHIFT) - 1; > 4530 > 4531 while (n >= 0) { > 4532 lowest += > uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone); > 4533 if (lowest >= 0) > 4534 return lowest; > 4535 n -= step; > 4536 if(--iter == 0) { > (kgdb) print n > $1 = 32767 > (kgdb) print zio_data_buf_cache[n] > $2 = (kmem_cache_t *) 0x0 > (kgdb) Very strange, zio_data_buf_cache[] can't be NULL, as asserted in zio_init. From owner-freebsd-current@freebsd.org Fri Jul 13 14: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 42585103E0E4 for ; Fri, 13 Jul 2018 14:15:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8CE9886A1 for ; Fri, 13 Jul 2018 14:15:42 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w6DEFbL5083620; Fri, 13 Jul 2018 07:15:37 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w6DEFbYG083619; Fri, 13 Jul 2018 07:15:37 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807131415.w6DEFbYG083619@pdx.rh.CN85.dnsmgr.net> Subject: Re: [UEFI] Boot issues on some UEFI implementations In-Reply-To: <68505F98-E840-4148-9E48-BDB350F7431A@me.com> To: Toomas Soome Date: Fri, 13 Jul 2018 07:15:36 -0700 (PDT) CC: "O. Hartmann" , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 14:15:43 -0000 > > > > On 13 Jul 2018, at 14:00, O. Hartmann wrote: > > > > The problem is some kind of weird. I face UEFI boot problems on GPT drives > > where the first partition begins at block 40 of the hdd/ssd. > > > > I have two host in private use based on an > > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LGA1155). > > Both boards are equipted with the lates official available AMI firmware > > revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 (2013/7/23) > > and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision > > for the Spectre/Meltdown mitigation is available, but I didn't test that. But > > please read. > > > > The third box I realised this problem is a brand new Fujitsu Esprimo Q956, also > > AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 20180525). > > > > Installing on any kind of HDD or SSD manually or via bsdinstall the OS using > > UEFI-only boot method on a GPT partitioned device fails. The ASRock boards jump > > immediately into the firmware, the Fujitsu offers some kind of CPU/Memory/HDD > > test facility. > > > > If on both type of vendor/boards CSM is disabled and UEFI boot only is implied, > > the MBR partitioned FreeBSD installation USB flash device does boot in UEFI! I > > guess I can assume this when the well known clumsy 80x25 char console suddenly > > gets bright and shiny with a much higher resoltion as long the GPU supports > > EFI GOP. Looking with gpart at the USB flash drives reveals that the EFI > > partition starts at block 1 of the device and the device has a MBR layout. I > > haven't found a way to force the GPT scheme, when initialised via gpart, to let > > the partitions start at block 1. This might be a naiv thinking, so please be > > patient with me. This sounds like a tool showing you the protective MBR which is part of GPT. > > I do not know whether this is a well-known issue. On the ASRock boards, I > > tried years ago some LinuxRed Hat and Suse with UEFI and that worked - FreeBSD > > not. I gave up on that that time. Now, having the very same issues with a new > > Fujitsu system, leaves me with the impression that FreeBSD's UEFI > > implementation might have problems I'm not aware of. > > > > Can someone shed some light onto this? > > > > The first thing to check is if the secure boot is disabled. We do not support secure boot at all at this time. > > If you have efi or bios version running - you can check from either console variable value (it can have efi or vidconsole or comconsole) or better yet, see if efi-version is set (show efi-version) - if efi-version is not set, it is BIOS loader running. Another indirect way is to see lsdev -v, with device paths present, it is uefi:) > > GPT partitions can never start from disk absolute sector 1; this is because at sector 0 there is MBR (for compatibility), sector 1 is GPT table and then sectors 2-33 have GPT partition table entries, so the first possible data sector is 34 (absolute 34). Thats assuming 512B sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. > One must be carefull when looking at a GPT scheme device, as it still has a "protective MBR" at sector 0 which covers sectors 1 to N of the device. Legacy (mbr only) tools well see this and show it as type 0xEE covering the whole device. Some modern tools still show this as an MBR, but then also show the GPT's inside it. Some tools never show you the protective MBR. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Jul 13 15:06:41 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 67A09103FB12 for ; Fri, 13 Jul 2018 15:06:41 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (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 E258A8A2F1 for ; Fri, 13 Jul 2018 15:06:40 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) X-YMail-OSG: d167z_MVM1mlKjB0iCIRrrH1WE8u8YI78ezgzHlMrWbBlpOAVlhsP_KzkqLphVL 0S0CVPnJJ5Y.xWeT56V2qs7sxXEiC0j8tolDl3TV1jblhC01yQpThLIOT654FyqFM6GEqEYn9YxJ E.t4LA7j1aUM1JRBh9KXjmlQBxxZIu45AW__eBkqACjApiSveUAa.kpktCW85LYN6OzcrJkMeoGj 45NC.1Pa8iCCvSGMdJwiwQGrNDRFhX1V8x0yTME51nME577Ldn5kiHnPebdCoJE9ziYVehzNTgi3 MN1klp.mOPlzV56Kln3PP1tnSmRlr6CEs0e0JZZsksPzVGlaNETVhkINlv9s8V8QA0LC3vKCsZ5j o.xJEyzXNR_BIjK6fA1UBiRHAISKwFwUUs5qTqk3gXZNimpCYpV13yRC33QphoFBvVUm_jGBLIY0 ccL8zxFtUy64kBtXt4Bo1L0Lja9sIlMDKTUIVujA4JJpIUVn5tnDQM0vTJDxeQdX8Y7xRIIJ499r 5criMz2AsQmHX.cVAg.LnG06b6eRkJkDY5ss4YuWQrfuC3831qTExuQNSCavsg6dxJyTioDkVGjj DB5Dkyit_YmFSXN0yEkDtwq1HnwmdVQpwUr70oMspL473JEZuhX2hMyYLqFVlfRdo4EQgnAb7jWo 1out0kFULgFExoM.X6TOVG6t9LxL0rRsW6NPw3lu7zG3R_gOTQPMW3MVEYaO_dfpM_Wm88olU7C4 fzG.u6craxFFuDbPLBnNdeMc_2ieCMeJmj47H6kleoYPYA0jNKirU7QDesLCKKqqObsR_n42MrdT L7M7cXZ3aStpX4R7FIaOoEH2ppCQ7jDl_mgXqv0V4m9tM15YHkdslKzrWjemm4dP20qHxT3p5EEx nsyrbXr2fl2AObNpgUg3wIWX._UdKqEL0RxH1CLtrDP1bq0ZgMyTwEE2UgQ6bDaKs_9eMO4haGKo - Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Jul 2018 15:06:34 +0000 Received: from dsl-hkibng22-54faa2-233.dhcp.inet.fi (EHLO [192.168.1.129]) ([84.250.162.233]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ac1693e04b05e980680d2b3bbda1009a for ; Fri, 13 Jul 2018 14:56:22 +0000 (UTC) To: freebsd-current@freebsd.org From: "jounijl@yahoo.co.uk" Subject: options COMPAT_AOUT to file UPDATING to know Message-ID: <1c5d9e7e-fb12-d35a-818e-5a2a433733f5@yahoo.co.uk> Date: Fri, 13 Jul 2018 20:56:11 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 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.27 Precedence: 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, 13 Jul 2018 15:06:41 -0000 === Reason: In compiling the kernel again after a long time after 'pkg upgrade' the following errors. The Intel graphics card is in use and something had changed, the 'startx' did not start the XFCE session. This was the reason to compile the kernel again with the new sources of today. After two retries taking some time to complite, it would be helpful to ... === Symptom: --- kernel.full --- linking kernel.full ld.lld: error: undefined symbol: aout_sysvec >>> referenced by imgact_gzip.c:240 (/usr/src/sys/kern/imgact_gzip.c:240) >>> imgact_gzip.o:(Flush) === Resolution: Adding options         COMPAT_AOUT to the kernel configuration file. This added the necessary 'imgact_aout.o' to the linking and the 'aout_sysvec' was found. __________________ It would be nice if a message was written in the /usr/src/UPDATING about this to prevent the unnecessary retries. Probably COMPAT_LINUXKPI needs this setting with 'device gzip' since COMPAT_AOUT was defined in a kernel module object, not in a kernel object file. Somewhere in time the COMPAT_AOUT did not exist after the 11-stable and this time it was necessary (today 13:th of July 2018) with the Intel driver. It has been necessary somewhere between 16:th of May to today (from these kernel timestamps). Who knows I don't know. It would be a good idea to add a note to the UPDATING as information for all of the Intel graphics users about the aout to be necessary to use less time in testing the error. br, jla From owner-freebsd-current@freebsd.org Fri Jul 13 15:27: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 BC2511040895 for ; Fri, 13 Jul 2018 15:27:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 DE4738B16E for ; Fri, 13 Jul 2018 15:27:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: unhdnzIVM1kWBto7x6j6I96FGZ.etS60DFg4U3OTBLiyk4Q7rYcUlxDkykJe1dM iNM5PL9MaacU90ETusGM_3hEP9bZr6KZvQNffxnpkpUxsAXaQPROyQv4Sg5.Lo5Q1bp.H91xq25R i3tb_eiidhIVBsjhmDJJuYywJISahG9zIWQizmhz7EPCPYB0LwP1pT9Ij_8xjkIfsR0sU7mnDdP2 KmqtN9FDUIWD_9GXdBviJLne56XJZ5f77Vmldp.q38mx69J3CeGGR8hwSHdmRS0hUCtLfr9.qYUI 9BDUy4Bu8MkeMOFTMTkf1WoOgV0Pe_tJK0UL4C6vWirbak9SFJb_kakRuI6C8RKHdGR364H7l.6p zb4N.lUdyeme3RMVHHkRjMeNob2YY643DiH3l70RC.i6Otik1D2QQrmPP4JSB0DzrHixjth0LlSs kjW776_NrTQ.QFI.hzlVAS2iSbuj9XbLAyJrv4wCraadYmJ6aSr6tJVHeFGe.V.DohpOGwnfvKxk Df5.rcUFxavVeYlEKN_9aZi7_jBYcXRU5LJ5RwkjcQ1KI_3HhKVmBYL8eOenyVsFUD7Icq7YMM9W 0NSs2T8J5Yjon4EMiSIIxv_vWeaFMKC3_LZ34c.DS_nS9YXTEMHPWN6FJ1q9XqCbgURIX4P158rL um69AkVAkEsyw5lGdIbzuakBZwXRllJguCn1FVwEQaF7G34WxpIoJDhHuD8dBkZSzTfaBWKfhRJ3 1rygbxDnGi8RmQitqjud.ObdEarDYaQCsmKLkILn.E6.DS2leG3WO5XT.8c7LZcChXAbbwjWPT4j 7Zfbt5aZbz_CMZkKvyUEUulhMMcrVc8L_wyojOcUxfuYiMmvXee28vU9EdGp1pLNY.PEIZ7blebL TkYlQN6pOXYo7sxu_qxjqXHUKtfRiforw2b543yp5UwOFRWSvMLNg4nMG0.iU6rhFzd0Mje2CqkE tdSMIaMHLexPH0kD12hosgNinexwv08eTyuS9WW4PncrMNXp0tiKNj0qpp75d5Vka.3zkkg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 13 Jul 2018 15:27:14 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 397c607cf7ff4eb30e9b1315c185d34f; Fri, 13 Jul 2018 15:27:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 From: Mark Millard In-Reply-To: Date: Fri, 13 Jul 2018 08:27:10 -0700 Cc: Dimitry Andric , freebsd-arm , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <43C85CB9-2F8A-4DB2-85F3-CAE6371666E4@yahoo.com> References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> To: tech-lists X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 15:27:22 -0000 On 2018-Jul-13, at 3:15 AM, tech-lists wrote: > On 12/07/2018 19:32, Dimitry Andric wrote: >> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes >> , an intrinsics header, which in turn requires = . >> This was introduced = inhttps://svnweb.freebsd.org/changeset/base/308921, >> and at the time resulted in similar build failures, specifically when >> one attempted to build a new kernel, without building world or a new >> toolchain first. >=20 > Hi, >=20 > Ok, it's finished building and installing. The command I used was = this: >=20 > # make -j10 buildworld && make -j10 buildkernel KERNCONF=3DRPI3 make -j10 buildworld buildkernel KERNCONF=3DRPI3 would have worked. > and it all built, (so I'll close the PR I opened). Then I did make = installkernel KERNCONF=3DRPI3 and because I thought might as well = install everything now it's built, mergemaster -p and make installworld = && mergemaster -Ui. >=20 > So I take it then, that every time I want to build a kernel, I either = have to do the above or use make kernel-toolchain. Is this correct? If you first clear out the old build, then such would be true. (Where, for targeting aarch64, kernel-toolchain needs to be avoided.) But you can buildkernel using the results of the existing buildworld (or kernel-toolchain if it applies) when it is okay to not clear out the old build first. (kernel developers doing kernel development likely do this a lot.) Another way to make tradeoffs is to use META_MODE so that partial rebuilds are done, avoiding some of the strictly unnecessary rebuild activity. This would involve buildworld or kernel-toolchain (as appropriate for the target architecture). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 13 14:45:08 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 028FE103EEB7 for ; Fri, 13 Jul 2018 14:45:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69D0389636 for ; Fri, 13 Jul 2018 14:45:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.193.191]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7m0a-1fztqx0Vt2-00vQN2; Fri, 13 Jul 2018 16:44:55 +0200 Date: Fri, 13 Jul 2018 16:44:20 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , freebsd-current Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> In-Reply-To: <68505F98-E840-4148-9E48-BDB350F7431A@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:cXqbs+qmQg+NAeKzKHN/vmQjVKxJ2aJg5G9Bf1fQ/u3OTIMCjYq NGKy+Eo161meGr2tPGjJOYJq4a15u8wWqxbLkjTGNHHmlIdAQ71oGZtoxg83UKTzIavcK3E JjQ/6OWMzRnQ6S96PaT9f972FtiggNQLsjyGaGvtabOWnggYw7hprWc6lD+2cxxEcT1UcsR cfzelqHcAxSp1JU8xpMiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:w1lMP/I/HYY=:6c55Q3rQafP4IgWFDF011y y7PH7w+3mu0Jzfw2hvZ8nZK3DF0dRVLa/sc5KZ/hvMoaFjpHKhvKxBAnEKqA1Svu7RGy4+zbW ionKlkzudHj+1n7uswq2De20xfkWX8PjbuVqBo8+euTkUXJ7ILHKq+1u7JsD30LR+2Ux2N3jw obzG+bCjF0Lcm7VHkUXhBv53CDBV0t5ncsYSboHRxCjKEDexa3Wy331jpcNxXkcXaPhpAoNr0 4D4+vn06SHvGUclwSmstYUZWt4ZknibWzTYHsSGIBTvaN3dDCnCJ45rwo9RqnnsJ7H7C5g7+l wSSGYt/kUXfXIGbV3wWmM4giUri4G/uzZ3CfSpzczaLQ2qXmMUKru4WJ4pM/prkaz0fjjXMiU Xs6QfwCPI5vxUWsJQFm7gvNnFGkFbXu1ICLH89OCapvnMjon8FnY4SA0y5c7U8zCLwfwM+4QM AVb3uuZnCooLDDEpARWH79NBxzMJvKi1TTOugJl3ZoYgBfgQZGy/iH6curptioY3PEUIyzluf f+KH3m5ae2C2bDOpd3JqGnpLzF6cZAYldB+rz1vqKlrQIk0ssIdZmwgnotzOB9bh5w6NXElIb n6839ZXQZEhEh0IYOmyk6BiyTBJcmUsVIzG9d+yCi2e6lEXvzG+2mA17jMpbc5TL7cPHwVICG jH+UVs9x6XnSa6IQur+DQ+us/KAwQ+3zo3Icoty2+CjRvn9Y736geSExkjKfQAWMLQ+Q4nmW5 7e0c4rEfExXFmjBX1LRsYxpVz6yU4ulc5iTp19t+IET4O/yXkiWJWgl91CL9+LLM7Jfl3Sp7b yvjewZF X-Mailman-Approved-At: Fri, 13 Jul 2018 15:38:53 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 14:45:08 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIEZy aSwgMTMgSnVsIDIwMTggMTQ6MjY6NTEgKzAzMDANClRvb21hcyBTb29tZSA8dHNvb21lQG1lLmNv bT4gc2NocmllYjoNCg0KPiA+IE9uIDEzIEp1bCAyMDE4LCBhdCAxNDowMCwgTy4gSGFydG1hbm4g PG9oYXJ0bWFubkB3YWxzdGF0dC5vcmc+IHdyb3RlOg0KPiA+IA0KPiA+IFRoZSBwcm9ibGVtIGlz IHNvbWUga2luZCBvZiB3ZWlyZC4gSSBmYWNlIFVFRkkgYm9vdCBwcm9ibGVtcyBvbiBHUFQgZHJp dmVzDQo+ID4gd2hlcmUgdGhlIGZpcnN0IHBhcnRpdGlvbiBiZWdpbnMgYXQgYmxvY2sgNDAgb2Yg dGhlIGhkZC9zc2QuDQo+ID4gDQo+ID4gSSBoYXZlIHR3byBob3N0IGluIHByaXZhdGUgdXNlIGJh c2VkIG9uIGFuDQo+ID4gb3V0ZGF0ZWQgQVNSb2NrIFo3Ny1Qcm80LU0gYW5kIFo3Ny1Qcm80IG1h aW5ib2FyZCAoSXZ5QnJpZGdlLCBTb2NrZXQgTEdBMTE1NSkuDQo+ID4gQm90aCBib2FyZHMgYXJl IGVxdWlwdGVkIHdpdGggdGhlIGxhdGVzIG9mZmljaWFsIGF2YWlsYWJsZSBBTUkgZmlybXdhcmUN Cj4gPiByZXZpc2lvbiwgZGF0aW5nIHRvIDIwMTMuIFRoaXMgaXMgZm9yIHRoZSBaNzctUHJvNC1N IHJldmlzaW9uIDIuMCAoMjAxMy83LzIzKQ0KPiA+IGFuZCBmb3IgdGhlIFo3NyBQcm80IHJldmlz aW9uIDEuOCAoMjAxMy83LzE3KS4gRm9yIGJvdGggYm9hcmRzIGEgQkVUQSByZXZpc2lvbg0KPiA+ IGZvciB0aGUgU3BlY3RyZS9NZWx0ZG93biBtaXRpZ2F0aW9uIGlzIGF2YWlsYWJsZSwgYnV0IEkg ZGlkbid0IHRlc3QgdGhhdC4gQnV0DQo+ID4gcGxlYXNlIHJlYWQuDQo+ID4gDQo+ID4gVGhlIHRo aXJkIGJveCBJIHJlYWxpc2VkIHRoaXMgcHJvYmxlbSBpcyBhIGJyYW5kIG5ldyBGdWppdHN1IEVz cHJpbW8gUTk1NiwgYWxzbw0KPiA+IEFNSSBmaXJtd2FyZSwgYXQgVjUuMC4wLjExIFIgMS4yNi4w IGZvciAzNDEzLUExeCwgZGF0ZSAwNS8yNS8yMDE4IChvciAyMDE4MDUyNSkuDQo+ID4gDQo+ID4g SW5zdGFsbGluZyBvbiBhbnkga2luZCBvZiBIREQgb3IgU1NEIG1hbnVhbGx5IG9yIHZpYSBic2Rp bnN0YWxsIHRoZSBPUyB1c2luZw0KPiA+IFVFRkktb25seSBib290IG1ldGhvZCBvbiBhIEdQVCBw YXJ0aXRpb25lZCBkZXZpY2UgZmFpbHMuIFRoZSBBU1JvY2sgYm9hcmRzIGp1bXANCj4gPiBpbW1l ZGlhdGVseSBpbnRvIHRoZSBmaXJtd2FyZSwgdGhlIEZ1aml0c3Ugb2ZmZXJzIHNvbWUga2luZCBv ZiBDUFUvTWVtb3J5L0hERA0KPiA+IHRlc3QgZmFjaWxpdHkuDQo+ID4gDQo+ID4gSWYgb24gYm90 aCB0eXBlIG9mIHZlbmRvci9ib2FyZHMgQ1NNIGlzIGRpc2FibGVkIGFuZCBVRUZJIGJvb3Qgb25s eSBpcyBpbXBsaWVkLA0KPiA+IHRoZSBNQlIgcGFydGl0aW9uZWQgRnJlZUJTRCBpbnN0YWxsYXRp b24gVVNCIGZsYXNoIGRldmljZSBkb2VzIGJvb3QgaW4gVUVGSSEgSQ0KPiA+IGd1ZXNzIEkgY2Fu IGFzc3VtZSB0aGlzIHdoZW4gdGhlIHdlbGwga25vd24gY2x1bXN5IDgweDI1IGNoYXIgY29uc29s ZSBzdWRkZW5seQ0KPiA+IGdldHMgYnJpZ2h0IGFuZCBzaGlueSB3aXRoIGEgbXVjaCBoaWdoZXIg cmVzb2x0aW9uIGFzIGxvbmcgdGhlIEdQVSBzdXBwb3J0cw0KPiA+IEVGSSBHT1AuIExvb2tpbmcg d2l0aCBncGFydCBhdCB0aGUgVVNCIGZsYXNoIGRyaXZlcyByZXZlYWxzIHRoYXQgdGhlIEVGSQ0K PiA+IHBhcnRpdGlvbiBzdGFydHMgYXQgYmxvY2sgMSBvZiB0aGUgZGV2aWNlIGFuZCB0aGUgZGV2 aWNlIGhhcyBhIE1CUiBsYXlvdXQuIEkNCj4gPiBoYXZlbid0IGZvdW5kIGEgd2F5IHRvIGZvcmNl IHRoZSBHUFQgc2NoZW1lLCB3aGVuIGluaXRpYWxpc2VkIHZpYSBncGFydCwgdG8gbGV0DQo+ID4g dGhlIHBhcnRpdGlvbnMgc3RhcnQgYXQgYmxvY2sgMS4gVGhpcyBtaWdodCBiZSBhIG5haXYgdGhp bmtpbmcsIHNvIHBsZWFzZSBiZQ0KPiA+IHBhdGllbnQgd2l0aCBtZS4NCj4gPiANCj4gPiBJIGRv IG5vdCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHdlbGwta25vd24gaXNzdWUuIE9uIHRoZSBBU1Jv Y2sgYm9hcmRzLCBJDQo+ID4gdHJpZWQgeWVhcnMgYWdvIHNvbWUgTGludXhSZWQgSGF0IGFuZCBT dXNlIHdpdGggVUVGSSBhbmQgdGhhdCB3b3JrZWQgLSBGcmVlQlNEDQo+ID4gbm90LiBJIGdhdmUg dXAgb24gdGhhdCB0aGF0IHRpbWUuIE5vdywgaGF2aW5nIHRoZSB2ZXJ5IHNhbWUgaXNzdWVzIHdp dGggYSBuZXcNCj4gPiBGdWppdHN1IHN5c3RlbSwgbGVhdmVzIG1lIHdpdGggdGhlIGltcHJlc3Np b24gdGhhdCBGcmVlQlNEJ3MgVUVGSQ0KPiA+IGltcGxlbWVudGF0aW9uIG1pZ2h0IGhhdmUgcHJv YmxlbXMgSSdtIG5vdCBhd2FyZSBvZi4NCj4gPiANCj4gPiBDYW4gc29tZW9uZSBzaGVkIHNvbWUg bGlnaHQgb250byB0aGlzPyANCj4gPiAgIA0KPiANCj4gVGhlIGZpcnN0IHRoaW5nIHRvIGNoZWNr IGlzIGlmIHRoZSBzZWN1cmUgYm9vdCBpcyBkaXNhYmxlZC4gV2UgZG8gbm90IHN1cHBvcnQgc2Vj dXJlDQo+IGJvb3QgYXQgYWxsIGF0IHRoaXMgdGltZS4NCg0KU2VjdXJlIGJvb3QgaXMgaW4gZXZl cnkgc2NlbmFyaW8gZGlzYWJsZWQhDQogDQo+IA0KPiBJZiB5b3UgaGF2ZSBlZmkgb3IgYmlvcyB2 ZXJzaW9uIHJ1bm5pbmcgLSB5b3UgY2FuIGNoZWNrIGZyb20gZWl0aGVyIGNvbnNvbGUgdmFyaWFi bGUNCj4gdmFsdWUgKGl0IGNhbiBoYXZlIGVmaSBvciB2aWRjb25zb2xlIG9yIGNvbWNvbnNvbGUp IG9yIGJldHRlciB5ZXQsIHNlZSBpZiBlZmktdmVyc2lvbg0KPiBpcyBzZXQgKHNob3cgZWZpLXZl cnNpb24pIC0gaWYgZWZpLXZlcnNpb24gaXMgbm90IHNldCwgaXQgaXMgQklPUyBsb2FkZXIgcnVu bmluZy4NCj4gQW5vdGhlciBpbmRpcmVjdCB3YXkgaXMgdG8gc2VlIGxzZGV2IC12LCB3aXRoIGRl dmljZSBwYXRocyBwcmVzZW50LCBpdCBpcyB1ZWZpOikNCg0KV2hhdCBhcmUgeW91IHRhbGtpbmcg YWJvdXQ/DQpXaGF0IGlzIHRoZSBwb2ludCBvZiBlbnRyeSAtIHJ1bm5pbmcgc3lzdGVtLCBsb2Fk ZXI/DQoNCnN5c2N0IG1hY2hkZXAuYm9vdG1ldGhvZDogQklPUw0KDQpUaGlzIG1ha2VzIG1lIHF1 aXRlIHN1cmUgdGhhdCB0aGUgc3lzdGVtIGhhcyBib290ZWQgdmlhIEJJT1MgLSBhcyBJJ20gc3Vy ZSBzaW5jZSBJJ3ZlDQpjaGVja2VkIHRoYXQgbWFueSB0aW1lcy4gVUVGSSBkb2Vzbid0IHdvcmsg b24gdGhvc2Ugc3lzdGVtcyB3aXRoIEZyZWVCU0QuIEknbSBub3Qgc3VyZQ0KYW50bW9yZSwgYnV0 IEkgdHJpZWQgYWxzbyBXaW5kb3dzIDcgb24gdGhvc2UgbWFpbmJvYXJkcyBib290aW5nIHZpYSBV RUZJIC0gYW5kIEkgbWlnaHQNCnJlY2FsbCB0aGF0IHRoZXkgZmFpbGVkIGFsc28uIEkgYWxzbyBy ZWNhbGwgdGhhdCB0aGVyZSB3ZXJlIGlzc3VlcyB3aXRoIGVhcmxpZXIgVUVGSQ0KdmVyc2lvbnMg cmVnYXJkaW5nIGJvb3Rpbmcgb25seSBXaW5kb3dzIDgvOC4xIC0gYW5kIG5vdGhpbmcgZWxzZSwg YnV0IHRoZSBmYWN0IHRoYXQgTGludXgNCndvcmtlZCBjb25mdXNlcyBtZSBhIGJpdC4NCg0KSWYg dGhpcyBBU1JvY2sgY3JhcCAobmV2ZXIgZXZlciBhZ2FpbiB0aGlzIGJyYW5kISkgZG9lc24ndCB3 b3JrIGF0IGFsbCAtIHdobyBjYXJlcywgSQ0KaW50ZW5kIHRvIHB1cmNoYXNlIG5ldyBzZXJ2ZXIg Z3JhZGUgaGFyZHdhcmUuIEJ1dCB0aGUgbW9yZSBwdXp6bGluZyBpc3N1ZSBpcyB3aXRoIHRoZQ0K RnVqaXRzdSwgd2hpY2ggSSBjb25zaWRlciBzZXJpb3VzIGFuZCBmcm9tIHRoZSBiZWhhdmlvdXIg dGhlIEZ1aml0c3UgZmFpbHVyZSBsb29rcw0KZXhhY3RseSBsaWtlIHRoZSBBU1JvY2sgLSBXaW5k b3dzIDcgd29ya3MsIFJlZEhhdCA3LjUgd29ya3MgKEkgYXNzdW1lIEkgY2FuIHRydXN0IHRoZQ0K RmlybXdhcmUgc2V0dGluZ3Mgd2hlbiBJIGRpc2FibGUgQ1NNIHN1cHBvcnQsIHRoYXQgdGhlIEZp cm13YXJlIHdpbGwgb25seSBFRkkvVUVGSQ0KY2FwYWJsZSBsb2FkZXI/IE9yIGlzIHRoZXJlIGEg Z2hvc3R5IG92ZXJyaWRlIHNvbXdoZXJlIHRvIGJlIGV4cGVjdGVkPykuIEFsc28gb24gQVNSb2Nr DQpkaXNhYmxpbmcgQ1NNIHNob3VsZCBlbnN1cmUgbm90IGJvb3RpbmcgYSBkdWFsLWJvb3RzdHJh cC1jYXBhYmxlIHN5c3RlbS4gVGhpcyBzYWlkLCBvbg0KdGhlIHJlY2VudCBGdWppdHN1LCBpdCBz ZWVtcyB0byBib2lsIGRvd24gdG8gYSBGcmVlQlNEIFVFRkktZmlybXdhcmUgaW50ZXJhY3Rpb24N CnByb2JsZW0sIHdoaWxlIHRoZSBBU1JvY2sgaXMgc3RpbGwgdW5kZXIgc3VzcGljaW9uIHRvIGJl IGJyb2tlbiBieSBkZXNpZ24uICANCg0KPiANCj4gR1BUIHBhcnRpdGlvbnMgY2FuIG5ldmVyIHN0 YXJ0IGZyb20gZGlzayBhYnNvbHV0ZSBzZWN0b3IgMTsgdGhpcyBpcyBiZWNhdXNlIGF0IHNlY3Rv ciAwDQo+IHRoZXJlIGlzIE1CUiAoZm9yIGNvbXBhdGliaWxpdHkpLCBzZWN0b3IgMSBpcyBHUFQg dGFibGUgYW5kIHRoZW4gc2VjdG9ycyAyLTMzIGhhdmUgR1BUDQo+IHBhcnRpdGlvbiB0YWJsZSBl bnRyaWVzLCBzbyB0aGUgZmlyc3QgcG9zc2libGUgZGF0YSBzZWN0b3IgaXMgMzQgKGFic29sdXRl IDM0KS4gVGhhdHMNCj4gYXNzdW1pbmcgNTEyQiBzZWN0b3JzLiAgRm9yIGRldGFpbHMgc2VlIFVF RkkgMi43IENoYXB0ZXIgNS4zLjEgcGFnZSAxMzEuDQoNClRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0 aW9uLiBUaGF0IGltcGxpZXMgdGhlIGluc3RhbGxlciBkaWQgcmlnaHQsIGdwYXJ0IGRpZCBhbHNv IHJpZ2h0DQphbmQgdGhlcmVmb3JlIHRoZXJlIG11c3QgYmUgYW4gaXNzdWUgd2l0aCB0aGUgc3R1 ZmYgbG9jYXRlZCB3aXRoaW4gdGhlIEVGSSBwYXJ0aXRpb24/DQoNCj4gDQo+IHJnZHMsDQo+IHRv b21hcw0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGFuZCBraW5kIHJlZ2FyZHMsDQoNCk9saXZlcg0K DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0 cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVudA0K PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vi c2NyaWJlQGZyZWVic2Qub3JnIg0KDQoNCg0KLSAtLSANCk8uIEhhcnRtYW5uDQoNCkljaCB3aWRl cnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDDnGJlcm1pdHRsdW5nIG1laW5lciBEYXRlbiBmw7xy DQpXZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGllIE1hcmt0LSBvZGVyIE1laW51bmdzZm9yc2NodW5n ICjCpyAyOCBBYnMuIDQgQkRTRykuDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQpp TFVFQVJNS0FCMFdJUVFaVlpNekF0d0MyVC84NlRyUzUyOGZ5RmhZbEFVQ1cwaTYzd0FLQ1JEUzUy OGZ5RmhZDQpsSlM5QWY5NmFnY1hObEhZME1SMzdJZWJsSXlXRnVYNWRLRXYrZS9QeTdDTlhJK0pj VEc4N05JYTROc1hIOE9oDQp1REN6Wm5yaC94RzJRaHQ2UXpKZmxWSnBCWFFzQWdDYW5JUE9sekFn aDIvUENBdU1pMVNXenUvSllRU2hPeUI2DQpMandhS2xSa3JRVDN3NnhpdDlPOEhXcVdiazh2ZDZx cVVmV00zU1h5RE1kOHBNdnA3dUhkDQo9NitQYg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0t DQo= From owner-freebsd-current@freebsd.org Fri Jul 13 16:44:35 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 73E351043927 for ; Fri, 13 Jul 2018 16:44:35 +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 1A9308E645 for ; Fri, 13 Jul 2018 16:44:35 +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 <0PBT00700AAAZD00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Fri, 13 Jul 2018 15:44:28 +0000 (GMT) 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 <0PBT00KZ4AE0RL00@st13p35im-asmtp001.me.com>; Fri, 13 Jul 2018 15:44:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-07-13_05:,, 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-1807130135 From: Toomas Soome Message-id: <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations Date: Fri, 13 Jul 2018 18:44:23 +0300 In-reply-to: <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> Cc: freebsd-current To: "O. Hartmann" References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 16:44:35 -0000 > On 13 Jul 2018, at 17:44, O. Hartmann wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Am Fri, 13 Jul 2018 14:26:51 +0300 > Toomas Soome > schrieb: >=20 >>> On 13 Jul 2018, at 14:00, O. Hartmann = wrote: >>>=20 >>> The problem is some kind of weird. I face UEFI boot problems on GPT = drives >>> where the first partition begins at block 40 of the hdd/ssd. >>>=20 >>> I have two host in private use based on an >>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket = LGA1155). >>> Both boards are equipted with the lates official available AMI = firmware >>> revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 = (2013/7/23) >>> and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a = BETA revision >>> for the Spectre/Meltdown mitigation is available, but I didn't test = that. But >>> please read. >>>=20 >>> The third box I realised this problem is a brand new Fujitsu Esprimo = Q956, also >>> AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 = (or 20180525). >>>=20 >>> Installing on any kind of HDD or SSD manually or via bsdinstall the = OS using >>> UEFI-only boot method on a GPT partitioned device fails. The ASRock = boards jump >>> immediately into the firmware, the Fujitsu offers some kind of = CPU/Memory/HDD >>> test facility. >>>=20 >>> If on both type of vendor/boards CSM is disabled and UEFI boot only = is implied, >>> the MBR partitioned FreeBSD installation USB flash device does boot = in UEFI! I >>> guess I can assume this when the well known clumsy 80x25 char = console suddenly >>> gets bright and shiny with a much higher resoltion as long the GPU = supports >>> EFI GOP. Looking with gpart at the USB flash drives reveals that the = EFI >>> partition starts at block 1 of the device and the device has a MBR = layout. I >>> haven't found a way to force the GPT scheme, when initialised via = gpart, to let >>> the partitions start at block 1. This might be a naiv thinking, so = please be >>> patient with me. >>>=20 >>> I do not know whether this is a well-known issue. On the ASRock = boards, I >>> tried years ago some LinuxRed Hat and Suse with UEFI and that worked = - FreeBSD >>> not. I gave up on that that time. Now, having the very same issues = with a new >>> Fujitsu system, leaves me with the impression that FreeBSD's UEFI >>> implementation might have problems I'm not aware of. >>>=20 >>> Can someone shed some light onto this?=20 >>>=20 >>=20 >> The first thing to check is if the secure boot is disabled. We do not = support secure >> boot at all at this time. >=20 > Secure boot is in every scenario disabled! >=20 >>=20 >> If you have efi or bios version running - you can check from either = console variable >> value (it can have efi or vidconsole or comconsole) or better yet, = see if efi-version >> is set (show efi-version) - if efi-version is not set, it is BIOS = loader running. >> Another indirect way is to see lsdev -v, with device paths present, = it is uefi:) >=20 > What are you talking about? > What is the point of entry - running system, loader? >=20 > sysct machdep.bootmethod: BIOS >=20 > This makes me quite sure that the system has booted via BIOS - as I'm = sure since I've > checked that many times. UEFI doesn't work on those systems with = FreeBSD. I'm not sure > antmore, but I tried also Windows 7 on those mainboards booting via = UEFI - and I might > recall that they failed also. I also recall that there were issues = with earlier UEFI > versions regarding booting only Windows 8/8.1 - and nothing else, but = the fact that Linux > worked confuses me a bit. >=20 > If this ASRock crap (never ever again this brand!) doesn't work at all = - who cares, I > intend to purchase new server grade hardware. But the more puzzling = issue is with the > Fujitsu, which I consider serious and from the behaviour the Fujitsu = failure looks > exactly like the ASRock - Windows 7 works, RedHat 7.5 works (I assume = I can trust the > Firmware settings when I disable CSM support, that the Firmware will = only EFI/UEFI > capable loader? Or is there a ghosty override somwhere to be = expected?). Also on ASRock > disabling CSM should ensure not booting a dual-bootstrap-capable = system. This said, on > the recent Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware = interaction > problem, while the ASRock is still under suspicion to be broken by = design. =20 >=20 >>=20 >> GPT partitions can never start from disk absolute sector 1; this is = because at sector 0 >> there is MBR (for compatibility), sector 1 is GPT table and then = sectors 2-33 have GPT >> partition table entries, so the first possible data sector is 34 = (absolute 34). Thats >> assuming 512B sectors. For details see UEFI 2.7 Chapter 5.3.1 page = 131. >=20 > Thanks for the explanation. That implies the installer did right, = gpart did also right > and therefore there must be an issue with the stuff located within the = EFI partition? >=20 Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS = loader at all or not - that is, if the BIOS bootstrap is actually caring = to read the MBR code and start it, since once the MBR code is started, = it is all about our code. btw, you can try to validate the installed boot blocks by using recent = enough loader (usb or iso) and then you can use from OK prompt: OK chain diskX: (replace X by correct disk number from lsdev) to read and start the MBR = code. If that is working, then its really about BIOS refusing to read = the MBR and execute it. rgds, toomas From owner-freebsd-current@freebsd.org Fri Jul 13 17:23: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 D5C731045002 for ; Fri, 13 Jul 2018 17:23:10 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from ns.it.odessa.ua (ns.it.odessa.ua [195.128.182.40]) by mx1.freebsd.org (Postfix) with ESMTP id 522BE8FF2B for ; Fri, 13 Jul 2018 17:23:09 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from ns.it.odessa.ua (localhost [127.0.0.1]) by ns.it.odessa.ua (Sendmail) with ESMTP id 10ADB7CB54C for ; Fri, 13 Jul 2018 20:22:56 +0300 (EEST) X-Virus-Scanned: amavisd-new at it.odessa.ua Received: from ns.it.odessa.ua ([127.0.0.1]) by ns.it.odessa.ua (ns.it.odessa.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0WP6kV6_E3o for ; Fri, 13 Jul 2018 20:22:55 +0300 (EEST) Received: from asus.theweb.org.ua (unknown [10.133.217.144]) by ns.it.odessa.ua (Sendmail) with SMTP id 660E27CB42B for ; Fri, 13 Jul 2018 20:22:54 +0300 (EEST) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id w6DHMoF8005741 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Jul 2018 20:22:50 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id w6DHMneh005740 for freebsd-current@freebsd.org; Fri, 13 Jul 2018 20:22:49 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: FreeBSD Current Subject: HEAD i386 r336217 : wireless connection fails ( ath(4) ) Date: Thu, 12 Jul 2018 19:08:36 +0300 Message-ID: <2011560.GsEZm8Rlsn@asus.theweb.org.ua> Organization: Private person MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 17:23:11 -0000 I'm experiencing wireless connection failure after HEAD/i386 update performed today. Below is relevant portion of dmesg buffer: Jul 12 18:43:39 desktop kernel: wlan0: Ethernet address: 18:a6:f7:8a:b1:52 Jul 12 18:43:39 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:39 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='****' freq=2412 MHz) Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:41 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:41 desktop dhclient[641]: New IP Address (wlan0): 192.168.0.50 Jul 12 18:43:41 desktop dhclient[642]: New Subnet Mask (wlan0): 255.255.255.0 Jul 12 18:43:41 desktop dhclient[643]: New Broadcast Address (wlan0): 192.168.0.255 Jul 12 18:43:41 desktop dhclient[644]: New Routers (wlan0): 192.168.0.1 Jul 12 18:43:42 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:42 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:42 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='****' freq=2412 MHz) Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:45 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:45 desktop dhclient[269]: send_packet: No buffer space available Jul 12 18:43:46 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:46 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:46 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='****' freq=2412 MHz) Jul 12 18:43:49 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:49 desktop dhclient[269]: send_packet: No buffer space available Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:50 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-SSID-TEMP- DISABLED id=22 ssid="****" auth_failures=1 duration=10 reason=CONN_FAILED Jul 12 18:43:50 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Trying to associate with SSID 'test adhoc' Jul 12 18:43:53 desktop wpa_supplicant[257]: bsd_set_if_media: SIOCSIFMEDIA Device not configured Jul 12 18:43:53 desktop wpa_supplicant[257]: wpa_driver_bsd_associate: failed to set operation mode Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Association request to the driver failed Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=-1 id_str=] Jul 12 18:43:56 desktop dhclient[269]: send_packet: Network is down Jul 12 18:44:04 desktop dhclient[269]: send_packet: Network is down Jul 12 18:45:01 desktop dhclient[269]: send_packet: Network is down Jul 12 18:45:05 desktop dhclient[1739]: New IP Address (wlan0): 192.168.0.50 Jul 12 18:45:05 desktop dhclient[1740]: New Subnet Mask (wlan0): 255.255.255.0 Jul 12 18:45:05 desktop dhclient[1741]: New Broadcast Address (wlan0): 192.168.0.255 Jul 12 18:45:05 desktop dhclient[1742]: New Routers (wlan0): 192.168.0.1 Jul 12 18:45:06 desktop dhclient[1744]: New Routers (wlan0): 192.168.0.1 From owner-freebsd-current@freebsd.org Fri Jul 13 18:01: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 B7C9A1046640 for ; Fri, 13 Jul 2018 18:01:21 +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 05C417181B for ; Fri, 13 Jul 2018 18:01:20 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.187] (cpe-75-82-194-8.socal.res.rr.com [75.82.194.8]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 13502bbb TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 13 Jul 2018 11:01:18 -0700 (PDT) Subject: Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more To: Yuri , freebsd-current@freebsd.org References: <750df9db-ac02-a691-d091-7c34fe5ddb22@rawbw.com> <83624f27-797d-6557-3f7e-8beac57c7d38@nomadlogic.org> From: Pete Wright Message-ID: Date: Fri, 13 Jul 2018 11:01:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: 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.27 Precedence: 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, 13 Jul 2018 18:01:21 -0000 On 07/12/2018 21:15, Yuri wrote: > On 07/12/18 13:38, Pete Wright wrote: >> >> sorry if i missed something (don't see details in the bug report) - >> is the issue that the run(4) kernel module is not being loaded? is >> there an error when the system attempts to load the kernel module in >> the dmesg buffer?  if it is not being loaded automagically what >> happens when you manually load the module via "kldload" or by >> updating rc.conf? > > > No errors while the kernel module is loaded. The problem is that when > the card is inserted wlan0 isn't automatically created. It also isn't > created during boot with the card in. I think that there were some > changes in devd that caused this regression. > interesting, i ran into an issue with a kernel/world i updated to on thursday where my USB mouse was non-functional and i suspect something funky happened with devd as well.  one suggestion i heard was to enable devmatch which i haven't had a chance to test yet. throwing it out there as it may help you. cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Jul 13 18:31: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 4241F1047A00 for ; Fri, 13 Jul 2018 18:31:28 +0000 (UTC) (envelope-from marklmi@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 BA72772B60 for ; Fri, 13 Jul 2018 18:31:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OM7CAsIVM1ke_CJdmh9MZK80MHB5nr9264kdCYBMWDGFz9GmttkkYmsBZNKGtIV 2tHYQPWCtpooxgDsrLbKp4c1XKkUQAjsnjlwkzn5zEa1q1xgeDJ_6hGmIZvauSw3t2uJSp.oVC5P EU1wJaySTq5_4NenHOsi18srx0GmZ00v6P53Q5YZZxFyZZpXGX9RXXliPIn8TatvtQNKbf_rpDMF jTDkSs6jdMxvW4_KVpTk.XqHX3NA1KKrWlj0rc7ErQuzixhXut_m5nzArFehznqP1PuuIcnirptu KxeS_UR2E0vyO_l3vnknM6d0j5VafiIl3uzj7KwF1Y7MXBp80Tqh4S7D_bQgyeIVArZyWnx.JK3X qHZof9XJTIyAd463CqxnUlXF6NRTlF8qF2cJtu3Z3_sPe6bK6bPvkoeXq3HzpzF3H3Y4TMvWFWvO w_0kFkc_iEFBrOPhIH3rpeAiXSmhHbjRWsErGYiIyU4PrVEWiD1KyqaGP2.uwMZ9VENKlaCreBL9 og9ufaKs44Shr4DfvK7yJLwxVo3otYrQ4LD89HcjJCDDFjBkzGznuxxy_eypJbvn3yoa1kPmVb3Z 9DSuohnMUpwQLvg6T6OrBjmlEdsLM3qbvy.V_6eYRvePkwUvxST1HN.GBmgVcpg50XgeS.GCCFMg IKZdTami3OoTV6L2pY46lwFYz9zw630dZ4DtZE.F5BMirGtIErROzhnU2x8LdDM1NSjFhfOGoFUE Wv.nZOorYe5Ze5CMCUaEP3sulUyVX2MIiYtj9.5A6pR6VcCXgv1t9LtVO4ciZ_o52Qci1Zgq1CW2 c5ZOVhp8PXBc.mf3_7vGVp4V6y2O4C.U.XkX0HA1ALUwz24Z8g9CbzAl5jhRotXeGMwJz7.zK7pz 5t947Ab5Uoqb9EIcAhKCmCZa8xFeO.eN5jENlwq4RgOa27x35Wv.WZhkZs6YOXiNNBrJ7bcKfuKk q6hzjJ9dCZ3Fh.uPnBD1pkMyP67mBGxWPYoNjojd8ym.X2opwufovXC3Q3C6cMg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Jul 2018 18:31:20 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp406.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 26e94217122c3788126bbd55fe7e289b; Fri, 13 Jul 2018 18:21:11 +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.5 \(3445.9.1\)) Subject: Re: svn commit: r336252 - in head: [ broke the ci.freebsd.org's FreeBSD-head-{mips,mips64,powerpc,powerpc64,sparc64,???}-build ] Message-Id: Date: Fri, 13 Jul 2018 11:21:10 -0700 To: ian@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 13 Jul 2018 18:31:28 -0000 [Note: mips64 built for -r336251 but failed for -r336252 and -r336253 .] An example (mips64): --- all_subdir_stand --- cc1: warnings being treated as errors /usr/src/stand/libsa/geli/geliboot_crypto.c: In function = 'geliboot_crypt': /usr/src/stand/libsa/geli/geliboot_crypto.c:45: warning: 'blks' may be = used uninitialized in this function *** [geliboot_crypto.o] Error code 1 (A bunch of architectures are still building their first build after -r336251 .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jul 14 09:00: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 B62E9104754B for ; Sat, 14 Jul 2018 09:00:38 +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 47C0771158 for ; Sat, 14 Jul 2018 09:00:38 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd36.aul.t-online.de (fwd36.aul.t-online.de [172.20.26.137]) by mailout04.t-online.de (Postfix) with SMTP id A2B434197AD6; Sat, 14 Jul 2018 11:00:29 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (GQ-6nOZ6Zh+7mzXKVSsTRLfQOehUpCUxj9MaJlrzq5pDmjkdoxs0o3VXZjdOMfvQ1g@[80.128.98.40]) by fwd36.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1feGPi-3LDj3A0; Sat, 14 Jul 2018 11:00:26 +0200 Subject: Re: options COMPAT_AOUT to file UPDATING to know To: "jounijl@yahoo.co.uk" , freebsd-current@freebsd.org References: <1c5d9e7e-fb12-d35a-818e-5a2a433733f5@yahoo.co.uk> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNKVN0ZWZhbiBFw59lciAoWWFob28hKSA8c3QuZXNzZXJAeWFob28uZGU+wsCWBBMBCgBA AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQSjceplnAvsyCtxUxNH67XvWv31RAUC WvLvqwUJCyUBEwAKCRBH67XvWv31REySCACc6vqcSFQCRyBRc2CV5ZBjbbnTy7VBoXbUS3/c 4Hn8I0YQ39q7//2z8vYsgLeM1mMXL4PUIU/0f0dBAFBLpxV7bntGzyCJls6SeGS/qcQKhqaI 6I7NcWg8OkIJIhUL6q238cS1ql9pU65fyHe0PP8JS08m81PDpX2/4wTE6h2jgYUy55eXRzoF MEjr1S8SSnidsBem27o7iWu9ltJsUtE86071iZlLzbuHv2nvucrjAV9cK9tHrxYT/YiY8QhT L48iWj2xIjLjg1ebmgIFZ2k881we/KTIoUugqOOR1gDSc4qwM8CA388cN3frjtl98CwhAT5T UV8tIDqri+/Z1AKwzsBNBFVxiRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1M kVnCAhFbY9oecTB/togdKtfiloavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNU eMm+gtTDMSvloGAfr76RtFHskdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPq z3B4IjiDAWTO2obD1wtAvSuHuUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSA ly+hkY7NrDZydMMXVNQ7AJQufWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpq ThDMurqtQFn1ABEBAAHCwHwEGAEKACYCGwwWIQSjceplnAvsyCtxUxNH67XvWv31RAUCWvLv qwUJCyUBGQAKCRBH67XvWv31RLnrB/9gzcRlpx71sDMosoZULWn7wysBJ/8AIEfIByRaHQe3 pn/KwE57pB+zFbbQqB7YzeZb7/UUgR4zU2ZbOcEfwDZcHUbj0B3fGRsS3t0uiLlAd8w0sBZb SxrqzjdpDjIbOZkxssqUmvrsN67UG1AFWH9aD24keBS7YjPBS8hLxPeYV+Xz6vUL8fRZje/Z JgiBMIwyj6g2lH/zkdnxBdC0iG1xxJOLTaghMMeQyCdH6ef8+VMyAlAJsMckbOTvx63tY8z7 DFcrnTJfbe1EziRilVsEaK8tTzJzhcTfos+f3eBYWEilxe5HzIhYKJeC7lmsSUcGwa6+9VRg a0ctmi9Z8OgX Message-ID: <7f930a51-e884-3bfb-60e8-9273bc65b618@freebsd.org> Date: Sat, 14 Jul 2018 11:00:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1c5d9e7e-fb12-d35a-818e-5a2a433733f5@yahoo.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ID: GQ-6nOZ6Zh+7mzXKVSsTRLfQOehUpCUxj9MaJlrzq5pDmjkdoxs0o3VXZjdOMfvQ1g X-TOI-MSGID: a7f601f9-f1ae-4ccb-b803-aa0cc35b0091 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 09:00:38 -0000 Am 13.07.18 um 19:56 schrieb jounijl@yahoo.co.uk: > > === Reason: > > In compiling the kernel again after a long time after 'pkg upgrade' the > following errors. The Intel graphics card is in use and something had changed, > the 'startx' did not start the XFCE session. This was the reason to compile > the kernel again with the new sources of today. After two retries taking some > time to complite, it would be helpful to ... > > === Symptom: > > --- kernel.full --- > linking kernel.full > ld.lld: error: undefined symbol: aout_sysvec >>>> referenced by imgact_gzip.c:240 (/usr/src/sys/kern/imgact_gzip.c:240) >>>> imgact_gzip.o:(Flush) > > === Resolution: > > Adding > > options         COMPAT_AOUT > > to the kernel configuration file. > > This added the necessary 'imgact_aout.o' to the linking and the 'aout_sysvec' > was found. Seems you have "device gzip" in your kernel configuration? This is a long (15 years?) obsolete option, which let you compress your a.out binaries with gzip and execute them as if they were uncompressed. The binaries where not paged in as normal, but loaded as one blob, in that case. This was a useful features when Laptops had slow 200 MB hard disks, since the space saving was substantial. ELF binaries could never be compressed and executed that way, and the option is not present in any kernel configuration in the FreeBSD sources. It is only mentioned in NOTES and there is a clear remark, that this option requires COMPAT_AOUT (and also mentions that it is only useful for a.out binaries). Regards, STefan From owner-freebsd-current@freebsd.org Sat Jul 14 10: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 BF1B61049EA8; Sat, 14 Jul 2018 10:15:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 84E9073F92; Sat, 14 Jul 2018 10:15:09 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1feHZz-00068w-Rh; Sat, 14 Jul 2018 12:15:08 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dimitry Andric" , "Mark Millard" , tech-lists Cc: freebsd-arm , "FreeBSD Current" , "FreeBSD Toolchain" Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> Date: Sat, 14 Jul 2018 12:15:07 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 523f42b60907f92a5b98f162865e3e4b X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 10:15:11 -0000 On Fri, 13 Jul 2018 12:15:22 +0200, tech-lists wrote: > On 12/07/2018 19:32, Dimitry Andric wrote: >> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes >> , an intrinsics header, which in turn requires . >> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, >> and at the time resulted in similar build failures, specifically when >> one attempted to build a new kernel, without building world or a new >> toolchain first. > > Hi, > > Ok, it's finished building and installing. The command I used was this: > > # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 What is RPI3? Mine runs GENERIC and there is no RPI3 config in /usr/src/sys/arm64/conf. I can find RPI2 in sys/arm/conf. Regards, Ronald. From owner-freebsd-current@freebsd.org Sat Jul 14 11:24: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 A719C104C817; Sat, 14 Jul 2018 11:24:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 379A975F71; Sat, 14 Jul 2018 11:24:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7BA76345; Sat, 14 Jul 2018 07:24:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 14 Jul 2018 07:24:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=oTcfaA2ZCTZaaVfcRRhgslDRXGUrC n2nbGubSZuN0gY=; b=MeV6zaFl9vJHdE8dRG1Dsl40wqV8ZTGiXXmFeDzd72NbW A1VXMMPbwKf3DUPVdWFufjkJ2H2YD8WIWwmeM/KRSkc/k56vHrikXqCGNbu+2yVA g9d463N+f0KtsTGfNPJsqv3p+dMrgROzYTYyDer51IUv72ZdJ9Tq9Y3jlEad0P3L XfC55zJyX8Ur13/6XyUzHdLWGj/+/n4cbSNp9cQyeIsRoJwcFwmNjvPAN1aSlZG5 7P1mEejciVd27Ypq84H7m08lDC4PTAFh7DSS4ZnYvWVVUDHv4nKQ6/Z34BKnsLZ/ pRQgPRVWre/6Mrk63Ap86p13+F2l3ENNDgAVQSWbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=oTcfaA 2ZCTZaaVfcRRhgslDRXGUrCn2nbGubSZuN0gY=; b=TlcWi8/O432vwroczQgAyh XIoVEPFU0KZHa1m7RmgPHmRZN7m5Dh2fmhoovqxLLYLoN1/4j8eXAw+4vhwWRPF3 WYxuN1H0zy/X6GdA2HQzKqwyYUG2laMTBqjjtFZnpMH5z17FFxeOnmkqumy+bm9u MHHoV6XlmDfJC8xYz4SSaeSeZ/8dafVvalpY1mysyCaUy3szrQXK1Cfva/5Eb6wc hWeO1DHaY86O1zU4P+NEf9581IfrjrbBVTIYjKnUjX4uLUp5jmtY9RGB7YSsuBZz esmXY1O3Xp+Pfgq2RSbw7e1NTYAdTmDRKLuiFxbGmZQZWTSjwFJ1Syr8iGa+Y5gQ == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id F42221026B; Sat, 14 Jul 2018 07:24:22 -0400 (EDT) Subject: Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3 To: Ronald Klop , Dimitry Andric , Mark Millard Cc: freebsd-arm , FreeBSD Current , FreeBSD Toolchain References: <2F72F7DB-F5DD-471A-B644-9CDE3FABFAC1@yahoo.com> <6DDED0A0-588D-4323-8E22-1267AA06615E@FreeBSD.org> From: tech-lists Organization: none Message-ID: <2350edc7-44a9-c04d-3b30-66bb6998e9e2@zyxst.net> Date: Sat, 14 Jul 2018 12:24:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.27 Precedence: 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, 14 Jul 2018 11:24:32 -0000 On 14/07/2018 11:15, Ronald Klop wrote: > What is RPI3? Mine runs GENERIC and there is no RPI3 config in > /usr/src/sys/arm64/conf. I can find RPI2 in sys/arm/conf. RPI3 is the same as GENERIC-NODEBUG, apart from the ident string which is also RPI3. (was mentioned at the start of the thread which branched off) -- J. From owner-freebsd-current@freebsd.org Sat Jul 14 11:36:16 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 33247104CE3D for ; Sat, 14 Jul 2018 11:36:16 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C9C5D7651B for ; Sat, 14 Jul 2018 11:36:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 86E5F104CE3C; Sat, 14 Jul 2018 11:36:15 +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 741F1104CE3B for ; Sat, 14 Jul 2018 11:36:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1234576519 for ; Sat, 14 Jul 2018 11:36:14 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1feIqM-0007uR-3v for current@freebsd.org; Sat, 14 Jul 2018 13:36:06 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1feIqM-0000DS-2g for current@freebsd.org; Sat, 14 Jul 2018 13:36:06 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Sat, 14 Jul 2018 11:36:05 GMT From: "Jeffrey Bouquet" To: "current" Subject: updates to HEAD online, RSS non-browser ?? Date: Sat, 14 Jul 2018 04:36:05 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 11:36:16 -0000 secnetix.de used to let me read HEAD updates to src daily. About several m= onhts ago, my browsers cannot reach it and the 2ndry site is tedious to rea= d in an equivalent manner. AFAIK the site is still up. Recent EU laws or some other cause? Reachable by some legal = VPN trickery?=20 RSS feed better serving to inform? legal web scraping connects to site when= browsers cannot?=20 ............. Thanks in advance. .............= From owner-freebsd-current@freebsd.org Sat Jul 14 13:35:10 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 D32D1102B347 for ; Sat, 14 Jul 2018 13:35:09 +0000 (UTC) (envelope-from alexvpetrov@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 4F3FA7A021 for ; Sat, 14 Jul 2018 13:35:09 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0FD77102B345; Sat, 14 Jul 2018 13:35:09 +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 D4348102B342 for ; Sat, 14 Jul 2018 13:35:08 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 2E8707A01F for ; Sat, 14 Jul 2018 13:35:08 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id a134-v6so29219947lfe.6 for ; Sat, 14 Jul 2018 06:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=oQUmcv1qlmw2cENzDRkjU9LgVdVTLVyhh9P9whyrt4s=; b=tUkSzuPfs16okRx3Tu1bfJVTRe5VCjZL9ULsqgCANDvvjQ+G7kgakpQEd+ix8qfSJh iAEWSHuRwaLYcKYdQa2sR9cY2hRI0KRQU+q8ZBXhva/FNqBEp2kOPE0k+gyb3s6mibkj n0x3hAo/ZCbJLjEu2H4pPZIbDoJh7+pojf1Z3Fdu1Sx2wjswxjoH0PI6L2m3FIihwdBD Zh/xLshN260wIqCXHgTCwduv6YP9A4aPvWcMXmQfiUKsJ1LuCbr7Pdzysf50cRQn0G9I uHDNtcXrTslXpGr6tbHTn26DXFi360PJaASyZ4q0e+bFOUSoR9GEJMUyhGO+c89h6Oyz omXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=oQUmcv1qlmw2cENzDRkjU9LgVdVTLVyhh9P9whyrt4s=; b=QHk4yJfraT2RmgmfpnlkvjG7gSipxrDXNvY5uRKiNma+tx74XlSGP+4+F6Lewme7VD rh/VlVkfAgEvb/6KNxBzOBM+z3t4+XSBg2xw2MydUUTBTTJpea7j1SM7kT4sDjKJQooV Y/vfsGkxjLM+76QPkghVydde5WQKuscDRpVwu8YYY0eRupQr8jeHUqdtqD8iDLhfp2H6 8VGIiqCAFZCOBXgDnA/YObMJ1fkDZQdi3OicLkWKOXxThmGRbsXwH95wsKztaMYT1XiS 1pMv01uVPC+knjRKwnDivx2QQHLDQTo1UJUKAReAp4Mg1LXgDrQLz7zZyA+TnHHJVeRx 8rTg== X-Gm-Message-State: AOUpUlG/n6vta7sGiKMvMeYGLeAfO8U6W+v8M9cC8zDzBGDqyAaXg5Co kQJhnOhLSFJpbp2fpLBlt9fnHA== X-Google-Smtp-Source: AAOMgpcnmaSeBVQPsOyRIVpobf7/YGTvRphFfl3BylNECCzmkyAlxO1K1Ll2XSaDFwI/QhnsZihXEw== X-Received: by 2002:a19:5c06:: with SMTP id q6-v6mr7791427lfb.6.1531575306104; Sat, 14 Jul 2018 06:35:06 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id l14-v6sm1535846ljh.91.2018.07.14.06.35.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 06:35:04 -0700 (PDT) To: current From: "Alex V. Petrov" Subject: error top? Openpgp: preference=signencrypt Autocrypt: addr=alexvpetrov@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFr3oA0BEADMSXiVd/IwYhJPMQ6LXbZ7jTA/RXuzrGYaR++UENx5QJ6/HJ/3myTeMnZE nNa0Zme+oKw/9s5x7rBTP6mL5ta7VSYpnPX932mAjT9J4nS7iW/wWNBqcXn7wDCog2TV8Ww3 13SUP2YaKoJKJLxddiZD6AJrkafB9EE/AycMQ8XxMao1lVS+/KAo0yciOsnSlIJCWhF00b3j xDlHLvehrDa4S3EB13bF6uE0XU5nFfMNHtBav2mwD9t01hNioCNTV1hXwmsS/L1n5PR5FyJJ yYtjeohrAUiGKGJU9lJJ6tROBhzV/k3OsOGPyajFOVsW0vUueYfgw+IAPYdOZIAONgNdxkvs tRLQxYPCBMN1FvQ7GlIhq7ob+mxuA1imXx3xzlYy5tu4QzB383qZtLqQnZpysjYooAbHl+eN vB2ldvH9TZxm3fxxNL6zgYAXE/pNgFoqg/ILmhDwvvHzApHqVCKU3g6yii0KPxD7susaUWcL JYgrmt2BIE0RuiQRGWyS0L277D/YGmVnPNHxPi58DBs2iexDm7jw7PhlmfOw44N9w+O09D2S gqmBHySAtsq9Z5LoM81F+LrOoVmpYczZWErS917Gua1X7K3wrXoqQC8qcSiHZpEcBl/Uohii QWzjQJot5LT7rvfFHpnSOXAKgN7enVM7KxTJAYK1U343GGdepQARAQABzTZBbGV4VlBldHJv diAoZmlyc3QgZ2xvYmFsIGtleSkgPGFsZXh2cGV0cm92QGdtYWlsLmNvbT7CwY4EEwEIADgW IQRvKPTT2TJuh37ANx313p8aVpVkcAUCWvegDQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRD13p8aVpVkcLLeEADClYAElEInGGjtLfH4jdjvTDaQTsrwT5/1E5/h8yxI4yn7hCt1 Dh+iCSUNLdPO88nZV2jP8bMQXFBKSbC0nAJXd8O+8t9AfSWoUC6IMzncxKTK/jZuJTCToCUR XZ+47+uJaBp51rpw3pFX8UrFlYSF6Dz97dI2cGHfx3xAOnowKxyHfthxS8waKWgbMOceds78 BP2+Q0iLCpoC9rO4KDc+w+h8z21eHIE9VHadTHpnKVF82voPH8XWvznTOCpYrdBwUtIyD/DV XRb0xcFsOSkvmReYX7u4QuOPLSc86sEWh4hXTFLAOdfeTjrDTDmBcmFpltmW1j+5t4mI1dK8 gptREM8gMJVJw3jjcO6jADeXX9q5C8/lX0sEGz9uC4oU5nkOMyfzd9Anb+9bCs7pMxhqAKjA 8tqJPPkmJU8WzMCs+uudIiQ8W9qIETwUJWxizQ3kvlzLfWRz5n93Y9kzSmjw81aiIJK/HFY8 wsW5zNo6JBn57cMPx8nBC4E2zM09ffmqSpjDwXfvZF2IIR8L4VTiKi3ovwLglJP+Qbs5HXNn 6K40cPNqfnHzPLwXwd/co04B/VVr+cKZuE58kYGty9Xs9q/SEpObDnxnLxMNHUNJJuRgOiti TKDkteHuKm6NA8v05o3TDQ5HU9szEoE5uoi/3pQ1ktfA/K3LkDwbotXL+87BTQRa96ANARAA w5+/xcaCP6iwsi2CFQ4pAWksdmPBEHA2VPn1ym3C6opjbyWUp6sn25eTWppdhA9rUqbM/zV/ hAFRT67oZJKBYNRaMoDdO8BsVZsg/u76QF/GuhbUjIk0tFFdpddMXl0zKAJJMCfDRxURRWv7 NW6sY/EZ4Dal5s4xOT+UrWGag3qoaIRdzw5bJRP+o75L90cE8pd7+Pd9cVJOOtTAwx0E4bPq dPSa6CPDSvzd9D3mw37dPzXysyQkQTy0OM7255E2wjYz3RbJxB3utybPVN3XJBD5EyA8IYeS ic1/03UrkRNv4XrLnlg7xLv96ZeCrf/BDNQW23iVwbISUAk4TXL7xs2TGYOmowZ89mMEcbfW ChX3YLAuAeWzgpMcrDC00izOxG0spkkrHL7/i1iSu2MKhv5qMTVgchlSktdd+KTba5keleHv ULQ3feGUKf9eTkKgES6q4rKrae0tIwByTLhhDVbkXqR6v8zrpJSscrvJ3tMNgquJKy5ATIUB nvUE2hMkSwtnJ2vQ/Z0zGt6c5KxI57/hsb148tXp1v3gAq9d6i8c8ChxSR/kUlqAvzl2QGcn CFVN6nfOzyNfBPZ61abNzkzjzyhOK4Gq4gQvx4QXhDp3jEME7rPM0Tqf0venb1Dp7SIHwggV yJglGApwoUvD4kKNIC7KDr+s/UjbBp4ExFMAEQEAAcLBdgQYAQgAIBYhBG8o9NPZMm6HfsA3 HfXenxpWlWRwBQJa96ANAhsMAAoJEPXenxpWlWRwAaEQAKm0imG5Fm37JZi+5faXJv/ZLZGl r4TVg4u1kMktdTQRrTXa3Qs0i3wTtOZe1p3xCCzPx+97iYETHragDTdAFUO+v+Llin26L1Zl z4huyIqgGSuTuekQfn6eoMZbcF+wzah4j/mvXQVpJBF2qQi1YdHSapWDlweuiuk01y8C3eHv 3qfFB/OJwXhwj0HKhkGkB2dLXuLtIk4GCXh4/g22tWz/SB0gsSXU7WhJFb0CyxETGR9YKxM8 CNl5tVRLqsBC6yQLvcAJgJci73PfMiHKnjxrz//+0xQO1TPeruWsd8nLYvziT38CyX42Mbaj 01WpvB0qOeTGtwGFmyyrnE8fYpd3CE0uAl9BnHqafAabl9+09x3wf+lEkkO2bK59akZz3BPU 8Lz2BAgskyS81WZCthQYUrUozFEx/31x8JJ95EQFNW9t8HBa51r4QhedSNKxLbT3Sx8hH0iq Z8wYkGw0og9U1DqgFzxE2HSGZSDG3I1DrPDqhcM/6Y0V98wS+XreuS88DYYck37+L7bTGiyZ WYFNZk1ChcIBk8hgKn5nFOCWO2rX06RI9zorzSpEg6lB2STae1Up5oEj8QqfYmfO3cp2Qhvj F3c2/i8KpWkJQkAgNrv428FIlx9SiPu9gvNTTYuLIOdZLQvInTmKs2uCoB6JDAW75axDhBbR FvM3Vpv/ Message-ID: Date: Sat, 14 Jul 2018 20:35:03 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 13:35:10 -0000 1T Wired!!! My system have 16G memory only. last pid: 35599; load averages: 8.53, 4.70, 3.52 up 1+01:20:57 20:30:17 310 processes: 11 running, 294 sleeping, 4 zombie, 1 waiting CPU: 22.7% user, 72.9% nice, 4.4% system, 0.0% interrupt, 0.0% idle Mem: 3G Active, 5G Inact, 2G Laundry, 1T Wired, 1G Buf, 524M Free ARC: 2G Total, 337M MFU, 2G MRU, 3M Anon, 35M Header, 94M Other 2G Compressed, 4G Uncompressed, 2.35:1 Ratio Swap: 4G Total, 138M Used, 4G Free, 3% Inuse FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #18 r336020 amd64 -- ----- Alex. From owner-freebsd-current@freebsd.org Sat Jul 14 14:50:50 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 58CAB102DE1C for ; Sat, 14 Jul 2018 14:50:50 +0000 (UTC) (envelope-from markjdb@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 E08FB7C6B0 for ; Sat, 14 Jul 2018 14:50:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9C489102DE17; Sat, 14 Jul 2018 14:50:49 +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 7826B102DE16 for ; Sat, 14 Jul 2018 14:50:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.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 0109A7C6AD for ; Sat, 14 Jul 2018 14:50:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-wm0-f53.google.com with SMTP id z13-v6so11827062wma.5 for ; Sat, 14 Jul 2018 07:50:48 -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=mnFZLDwK2JwUbx1AcDOmkmQavLII0iWajbR2Icgzd9U=; b=qkD5WSo8x4XENx/QVhSig0nrc/86qg6CPI+FAFji9k6YnrsU+EXMyiQzarj3U65t9G 8kwc1uotcxxY948dffBCTHEArxFt52cFeOD/0/r1qjufCBIzdj524bx4L8kRV+yCUTBx KUmvyldL/HYnXD40Rm6pIyCspuP/9bAfHxGInJJ/i5A8mmikHluCnzT5OELp91hZT26U nJuTQhrVqL7P6xJDmNtYUxC7a6iE5gvoRiA1Ux8v0pIAKfeE2x0LCsHpaodvLfHHJux3 yIixCfz7Xp8PguxXMET7etp8ZalI23ZbLsXzj8HI2s0MnS5zP7vr+dUFC5F1SgB2+Kgd fpFw== X-Gm-Message-State: AOUpUlE0L7d6vb6y40yP5dNhPqI4RW08ifKaMLwTl0YsvJBuw5WBCUfh zJsMvVrkuwhxQhV7NpdFaLzZBNofTBRfyL2qoQA= X-Google-Smtp-Source: AAOMgpdniZEP3FACmpl4rkJtWt5gM5HZbcgJdvk1VGr6hYDOSCq2oNCudJdDLgVJATa0t5aqvqsZv7RV+Ux5BAKu5cw= X-Received: by 2002:a1c:d543:: with SMTP id m64-v6mr5802685wmg.12.1531579392351; Sat, 14 Jul 2018 07:43:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Johnston Date: Sat, 14 Jul 2018 10:42:59 -0400 Message-ID: Subject: Re: error top? To: "Alex V. Petrov" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 14:50:50 -0000 On Sat, Jul 14, 2018, 09:36 Alex V. Petrov, wrote: > 1T Wired!!! > My system have 16G memory only. > > > last pid: 35599; load averages: 8.53, 4.70, 3.52 > > up 1+01:20:57 20:30:17 > 310 processes: 11 running, 294 sleeping, 4 zombie, 1 waiting > > > CPU: 22.7% user, 72.9% nice, 4.4% system, 0.0% interrupt, 0.0% idle > Mem: 3G Active, 5G Inact, 2G Laundry, 1T Wired, 1G Buf, 524M Free > ARC: 2G Total, 337M MFU, 2G MRU, 3M Anon, 35M Header, 94M Other > 2G Compressed, 4G Uncompressed, 2.35:1 Ratio > Swap: 4G Total, 138M Used, 4G Free, 3% Inuse > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #18 r336020 amd64 > Try updating to r336149 or later. > From owner-freebsd-current@freebsd.org Sat Jul 14 15:25:33 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 159F0102F0BD for ; Sat, 14 Jul 2018 15:25:33 +0000 (UTC) (envelope-from lists@opsec.eu) 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 A97257D58A for ; Sat, 14 Jul 2018 15:25:32 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 66ADF102F0BC; Sat, 14 Jul 2018 15:25:32 +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 53D3C102F0BB for ; Sat, 14 Jul 2018 15:25:32 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE0317D589 for ; Sat, 14 Jul 2018 15:25:31 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1feMQP-000Iim-PB; Sat, 14 Jul 2018 17:25:33 +0200 Date: Sat, 14 Jul 2018 17:25:33 +0200 From: Kurt Jaeger To: Jeffrey Bouquet Cc: current Subject: Re: updates to HEAD online, RSS non-browser ?? Message-ID: <20180714152533.GL77764@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 15:25:33 -0000 Hi! > secnetix.de used to let me read HEAD updates to src daily. > About > several monhts ago, my browsers cannot reach it and the 2ndry site > is tedious to read in an equivalent manner. AFAIK the site is still up. I've checked (from .de) and the site is down. Why don't you use the mailman archive ? https://lists.freebsd.org/pipermail/svn-src-all/ -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sat Jul 14 18:19: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 916A11035F3A for ; Sat, 14 Jul 2018 18:19:07 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 20A07839F8 for ; Sat, 14 Jul 2018 18:19:07 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id CAF541035F39; Sat, 14 Jul 2018 18:19:06 +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 B867B1035F38 for ; Sat, 14 Jul 2018 18:19:06 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AA4A839F7 for ; Sat, 14 Jul 2018 18:19:06 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1feP8J-0000Ik-Mr; Sat, 14 Jul 2018 20:19:03 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1feP8J-0004fg-Kt; Sat, 14 Jul 2018 20:19:03 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Sat, 14 Jul 2018 18:19:03 GMT From: "Jeffrey Bouquet" To: "Kurt Jaeger" CC: "current" Subject: Re: updates to HEAD online, RSS non-browser ?? Date: Sat, 14 Jul 2018 11:19:03 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <20180714152533.GL77764@home.opsec.eu> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: 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, 14 Jul 2018 18:19:07 -0000 On Sat, 14 Jul 2018 17:25:33 +0200, Kurt Jaeger wrote: > Hi! >=20 > > secnetix.de used to let me read HEAD updates to src daily. > > About > > several monhts ago, my browsers cannot reach it and the 2ndry site > > is tedious to read in an equivalent manner. AFAIK the site is still up. >=20 > I've checked (from .de) and the site is down. Thanks. I guess that's what I wanted to know >=20 > Why don't you use the mailman archive ? >=20 > https://lists.freebsd.org/pipermail/svn-src-all/ I guess the best way to use that is script the downloadable archive and = somehow just read the part that's new from yesterday's downloadable archive. So so= mething to test...=20 >=20 > --=20 Thanks.=20=