From owner-freebsd-current@freebsd.org Sat Sep 8 19:49: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 71D35FFC6AD for ; Sat, 8 Sep 2018 19:49:43 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F069E762B9; Sat, 8 Sep 2018 19:49:42 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by mail-it0-x244.google.com with SMTP id p129-v6so23961155ite.3; Sat, 08 Sep 2018 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pbshumRyqKPAhbRddZXNxe/+ok+1tQ+8FEX9md2gIc4=; b=cTSFRuGondE1S2lkr7yHoq6bj2FAJSF3GocslbKUHSfZfeqGAC4BMPAhYVIT/t/dLP huf1iIlRxW/AgX+oMSH8FyEHH8+NFbi0m41bhyNZ+0x7LyKAlcwAeMHLyVSGnIN5AtAl xpagDEuRGnxwD0gpz8uySGRx35jIDLJvCkJCtpver6UtC+12KqllSSly1cPiULKJZ6ai HzXTzZ0TEAnEwmaJz46sh1vTBiedu/IqD1NWVwWKn9150B+5vinmYfPvuEB6KNrhPi1c cQT7VArJ2adXHepNmad+nBFRpNIPBMOj2pFs2uAb+reZiJi5L5GzpXwcV+H8/XD8E8YE Kftg== 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=pbshumRyqKPAhbRddZXNxe/+ok+1tQ+8FEX9md2gIc4=; b=AU6ZHV5gfOOBhPX0BwKQWQBOciQvzlQNo2BeojFZUSO472Ow+48Rx8uEfTiMDd1VhU 8L+vKDx4M3IrnuTUmylrkW37zyD197TMk+diPtcv0OIkk+1r3D2DqscykGE9vu98kPI8 2RcKnRntwUUPcbN4+M0WwhX81448h+HPuiIFoCdA2o9ep/iCzHRqITKBNUGTGRKtbVEr iFQ29RJi5PMcGETJIAEKwLrjDht6qWgJZU7u0EqiYBIzXvdAwluW+qnTyFQnWRYcwyOm cQMGGMgp8O8wSx1xsmL5yycml4x9dvTFeGeCkaqR3BbV4LiAY2ZaAGrn5gHl7o73f2HY rUhQ== X-Gm-Message-State: APzg51Dos5CJirQg9zoQ+YOkdu7AeJQo5vdrCb1zzTDDG74TuedQu1ZB Gq03gXoh1P38YKRfCV8G7L/ejs7JtlMCArGvIpg= X-Google-Smtp-Source: ANB0VdbSYTMhsGnpn2qHdsj1o5lMOYsyisbFEBT3xp7QwnjqjeWbsEvnODM6VWB4KQmNryc/sSix2Yl77Qu7ACN8Tog= X-Received: by 2002:a02:2b12:: with SMTP id h18-v6mr12415953jaa.10.1536436182098; Sat, 08 Sep 2018 12:49:42 -0700 (PDT) MIME-Version: 1.0 References: <201809081759.w88HxenJ059089@slippy.cwsent.com> In-Reply-To: <201809081759.w88HxenJ059089@slippy.cwsent.com> From: Matthew Macy Date: Sat, 8 Sep 2018 12:49:31 -0700 Message-ID: Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: Cy Schubert Cc: Jakob Alvermark , Mark Johnston , Subbsd , "allanjude@freebsd.org" , freebsd-current Current X-Mailman-Approved-At: Sun, 09 Sep 2018 04:32:34 +0000 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, 08 Sep 2018 19:49:44 -0000 On Sat, Sep 8, 2018 at 11:03 Cy Schubert wrote: > In message , Jakob > Alvermar > k writes: > > > > Total MFU MRU Anon Hdr L2Hdr > Other > > ZFS ARC 667M 186M 168M 13M 3825K 0K 295M > > > > rate hits misses total hits total > > misses > > arcstats : 99% 65636 605 167338494 > 9317074 > > arcstats.demand_data : 57% 431 321 13414675 > 2117714 > > arcstats.demand_metadata : 99% 65175 193 152969480 > 5344919 > > arcstats.prefetch_data : 0% 0 30 3292 401344 > > arcstats.prefetch_metadata: 32% 30 61 951047 1453097 > > zfetchstats : 9% 119 1077 612582 55041789 > > arcstats.l2 : 0% 0 0 0 0 > > vdev_cache_stats : 0% 0 0 0 0 > > > > > > > > > > This is while a 'make -j8 buildworld' (it has 8 cores) is going. > > Overall you have a 94% hit ratio. > > slippy$ bc > scale=4 > 167338494/(167338494+9317074) > .9472 > slippy$ > > > It could be better. > > Why is your ZFS ARC so small? Before I answer this I will discuss my > experience first. > > My machines are seeing something similar to this: > > Total MFU MRU Anon Hdr L2Hdr > Other > ZFS ARC 4274M 2329M 1394M 17M 82M 0K > 445M > > rate hits misses total hits total > misses > arcstats : 97% 614 13 866509066 > 51853442 > arcstats.demand_data :100% 96 0 107658733 > 3101522 > arcstats.demand_metadata : 97% 516 13 755890353 > 48080146 > arcstats.prefetch_data : 0% 0 0 327613 > 225688 > arcstats.prefetch_metadata:100% 2 0 2632367 > 446086 > zfetchstats : 6% 6 80 2362709 > 294731645 > arcstats.l2 : 0% 0 0 0 > 0 > vdev_cache_stats : 0% 0 0 0 > 0 > > This is what you should see. This is with -CURRENT built two days ago. > > cwsys$ uname -a > FreeBSD cwsys 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #51 r338520M: Thu Sep 6 > 17:44:35 PDT 2018 root@cwsys:/export/obj/opt/src/svn-current/amd64.a > md64/sys/BREAK amd64 > cwsys$ > > Top reports: > > CPU: 0.3% user, 89.9% nice, 9.5% system, 0.3% interrupt, 0.0% idle > Mem: 678M Active, 344M Inact, 175M Laundry, 6136M Wired, 168M Buf, 598M > Free > ARC: 4247M Total, 2309M MFU, 1386M MRU, 21M Anon, 86M Header, 446M Other > 3079M Compressed, 5123M Uncompressed, 1.66:1 Ratio > Swap: 20G Total, 11M Used, 20G Free > > This is healthy. It's running a poudriere build. > > My laptop: > > Total MFU MRU Anon Hdr L2Hdr > Other > ZFS ARC 3175M 1791M 872M 69M 165M 0K > 277M > > rate hits misses total hits total > misses > arcstats : 99% 3851 26 89082984 > 5101207 > arcstats.demand_data : 99% 345 2 6197930 > 340186 > arcstats.demand_metadata : 99% 3506 24 81391265 > 4367755 > arcstats.prefetch_data : 0% 0 0 11507 > 30945 > arcstats.prefetch_metadata: 0% 0 0 1482282 > 362321 > zfetchstats : 2% 12 576 113185 > 38564546 > arcstats.l2 : 0% 0 0 0 > 0 > vdev_cache_stats : 0% 0 0 0 > 0 > > Similar results after working on a bunch of ports in four VMs last > night, testing various combinations of options while Heimdal in base is > private, hence the large ARC remaining this morning. > > Currently on the laptop top reports: > > CPU: 0.2% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.8% idle > Mem: 376M Active, 1214M Inact, 5907M Wired, 464M Buf, 259M Free > ARC: 3175M Total, 1863M MFU, 803M MRU, 69M Anon, 160M Header, 280M Other > 2330M Compressed, 7881M Uncompressed, 3.38:1 Ratio > Swap: 22G Total, 22G Free > > This is also healthy. > > Now for questions: > > Do you have any UFS filesystems? Top will report buf. What is that at? > > Some background: My /, /usr, and /var are UFS (these are old > installations which when I install a new machine I dump | rsh > new-machine restore, change a couple of entries in rc.conf and fstab, > rsync ports (/usr/local, /var/db...) and boot (I'm terribly impatient). > Hence the legacy. > > I have noticed that when writing a lot to UFS, increasing the size of > the UFS buffer cache, my ARC will reduce to 1 GB or even less. But this > is during a -j8 installworld to /, a test partition, an i386 partition > and a number of VMs on UFS on a zpool and other VMs using ZFS on the > same zpool. My ARC drops rapidly when the UFS filesystems are actively > being written to. UFS and ZFS on the same server will impact > performance unless one or the other is sparsely used. > > To repeat, do you have any UFS on the system? Do you write to UFS? Is > it actively being written to at the time? How many MB is used by UFS > buffers? > > How much RAM is installed on this machine? > > What is the scan rate? > > > > > SSH'ing to the machine while the buildworld is going it takes 40-60 > > seconds to get to the shell! > > Then your iostat or systat -v should show that you're hammering your > disks. Or, you may be using a lot of swap. > > > > > Hitting ^T while waiting: load: 1.06 cmd: zsh 45334 > > [arc_reclaim_waiters_cv] 56.11r 0.00u 0.10s 0% 5232k > > Load might be low because processes are waiting for disk I/O. Processes > waiting on I/O are not in the run queue and therefore don't affect load > average. Disk I/O will kill performance worse than CPU load. Back in > the days when I was an MVS systems programmer (IBM mainframe), I did a > fair bit of tuning MVS at the time (Z/OS today). The rule of thumb then > was machine instructions took nanoseconds whereas disk I/O took > milliseconds and interrupting a process to gain control of the CPU the > scheduler took nanoseconds because that's how long instructions took. > You cannot interrupt I/O. You have to wait for the current I/O > operation to complete before inserting a new I/O into the queue and > with tagged queuing you have to wait for the disk to complete its work > before scheduling new work. Now you're waiting multiples of > milliseconds instead of a few nanoseconds. I/O kills performance. > > Look at iostat or systat -v. I think your answer lies there and since > your ARC is small we need to find out why. > > > > > I will test the patch below and report back. > > Agreed, though IMO your workload and your environment need to be > understood first. What concerns me about the patch is what impact will > it have on other workloads. Not evicting data and only metadata could > impact buildworld -DNO_CLEAN for example. I do a -DNO_CLEAN > buildworlds, sometimes -DWORLDFAST. Adjusting vfs.zfs.arc_meta_limit to > the same value as vfs.zfs.arc_max improved my buildworld/installworld > performance. In addition disabling atime for the ZFS dataset containing > /usr/obj also improved buildworld/installworld performance by reducing > unnecessary (IMO) metadata writes. I think evicting metadata only might > cause a new set of problems for different workloads. (Maybe this should > be a sysctl?) > Mark's suggested change would just restore the default behavior from before balanced pruning was imported. Balanced pruning is dependent on code that didn't exist in FreeBSD - unfortunately when I did the import I did not pull in all the dependencies. Mid freeze, the least disruptive path is to disable the new behavior. Post branch we can restore it as a default, possibly contingent on the amount of memory in the system. There is precedent for this with prefetch. -M > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > > > > > Jakob > > > > On 9/7/18 7:27 PM, Cy Schubert wrote: > > > I'd be interested in seeing systat -z output. > > > > > > --- > > > Sent using a tiny phone keyboard. > > > Apologies for any typos and autocorrect. > > > Also, this old phone only supports top post. Apologies. > > > > > > Cy Schubert > > > or > > > The need of the many outweighs the greed of the few. > > > --- > > > > ------------------------------------------------------------------------ > > > From: Mark Johnston > > > Sent: 07/09/2018 09:09 > > > To: Jakob Alvermark > > > Cc: Subbsd; allanjude@freebsd.org; freebsd-current Current > > > Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 > > > > > > On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: > > > > On 9/6/18 2:28 AM, Mark Johnston wrote: > > > > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > > > > >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude > > > > wrote: > > > > >>> On 2018-09-05 10:04, Subbsd wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> I'm seeing a huge loss in performance ZFS after upgrading > > > FreeBSD 12 > > > > >>>> to latest revision (r338466 the moment) and related to ARC. > > > > >>>> > > > > >>>> I can not say which revision was before except that the > newver.sh > > > > >>>> pointed to ALPHA3. > > > > >>>> > > > > >>>> Problems are observed if you try to limit ARC. In my case: > > > > >>>> > > > > >>>> vfs.zfs.arc_max="128M" > > > > >>>> > > > > >>>> I know that this is very small. However, for two years with > > > this there > > > > >>>> were no problems. > > > > >>>> > > > > >>>> When i send SIGINFO to process which is currently working with > > > ZFS, i > > > > >>>> see "arc_reclaim_waiters_cv": > > > > >>>> > > > > >>>> e.g when i type: > > > > >>>> > > > > >>>> /bin/csh > > > > >>>> > > > > >>>> I have time (~5 seconds) to press several times 'ctrl+t' before > > > csh is executed: > > > > >>>> > > > > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u > > > 0.00s 0% 3512k > > > > >>>> load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% > 3512k > > > > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u > > > 0.01s 0% 3512k > > > > >>>> load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u > > > 0.01s 0% 4156k > > > > >>>> > > > > >>>> same story with find or any other commans: > > > > >>>> > > > > >>>> load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% > 2676k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u > > > 0.00s 0% 2676k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u > > > 0.00s 0% 2680k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u > > > 0.00s 0% 2684k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u > > > 0.00s 0% 2704k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u > > > 0.00s 0% 2716k > > > > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u > > > 0.00s 0% 2760k > > > > >>>> > > > > >>>> this problem goes away after increasing vfs.zfs.arc_max > > > > >>>> _______________________________________________ > > > > >>>> 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" > > > > >>>> > > > > >>> Previously, ZFS was not actually able to evict enough dnodes to > keep > > > > >>> your arc_max under 128MB, it would have been much higher based > > > on the > > > > >>> number of open files you had. A recent improvement from upstream > ZFS > > > > >>> (r337653 and r337660) was pulled in that fixed this, so setting > an > > > > >>> arc_max of 128MB is much more effective now, and that is causing > the > > > > >>> side effect of "actually doing what you asked it to do", in this > > > case, > > > > >>> what you are asking is a bit silly. If you have a working set > > > that is > > > > >>> greater than 128MB, and you ask ZFS to use less than that, it'll > > > have to > > > > >>> constantly try to reclaim memory to keep under that very low bar. > > > > >>> > > > > >> Thanks for comments. Mark was right when he pointed to r338416 ( > > > > >> > > > > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/commo > > n/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > > > > >> ). Commenting aggsum_value returns normal speed regardless of the > > > rest > > > > >> of the new code from upstream. > > > > >> I would like to repeat that the speed with these two lines is not > > > just > > > > >> slow, but _INCREDIBLY_ slow! Probably, this should be written in > the > > > > >> relevant documentation for FreeBSD 12+ > > > > > > > > Hi, > > > > > > > > I am experiencing the same slowness when there is a bit of load on > the > > > > system (buildworld for example) which I haven't seen before. > > > > > > Is it a regression following a recent kernel update? > > > > > > > I have vfs.zfs.arc_max=2G. > > > > > > > > Top is reporting > > > > > > > > ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M > > > Other > > > > 105M Compressed, 281M Uncompressed, 2.67:1 Ratio > > > > > > > > Should I test the patch? > > > > > > I would be interested in the results, assuming it is indeed a > > > regression. > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sun Sep 9 09:48: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 48E8A10904E1 for ; Sun, 9 Sep 2018 09:48:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 E35368D82D for ; Sun, 9 Sep 2018 09:48:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id A84EC10904E0; Sun, 9 Sep 2018 09:48:42 +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 96F0A10904DF for ; Sun, 9 Sep 2018 09:48:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 304908D82C for ; Sun, 9 Sep 2018 09:48:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1fywKS-000GmA-Ct for current@freebsd.org; Sun, 09 Sep 2018 12:48:28 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: netif not started by devd? Message-Id: Date: Sun, 9 Sep 2018 12:48:28 +0300 To: 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: Sun, 09 Sep 2018 09:48:43 -0000 with latest current, but can tell when this stopped working, the wifi dongle is recognised, ie there is a net.wlan.devices, depending on the dongle it=E2=80=99s run0 or rtwn0 but only if I type service netif start does it become operational. so what am I missing? cheers, danny From owner-freebsd-current@freebsd.org Mon Sep 10 01:16: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 3BE1E10A47F2 for ; Mon, 10 Sep 2018 01:16:27 +0000 (UTC) (envelope-from alex.mckeever@sbcglobal.net) Received: from sonic314-23.consmr.mail.gq1.yahoo.com (sonic314-23.consmr.mail.gq1.yahoo.com [98.137.69.86]) (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 9B7AA899D2 for ; Mon, 10 Sep 2018 01:16:25 +0000 (UTC) (envelope-from alex.mckeever@sbcglobal.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1536542184; bh=/L8ZULUs2lbAVGxDpOCJzpOCcRZqWRiFf4Bf14KNG1o=; h=Date:From:To:Subject:References:From:Subject; b=Hty34+82EUZ2MDIPcbIhSpdJPQ9OxfnjbJKTXN/StG7jLEL5oJN/wRMx7WYVkcSp6TqrGgu4KrwzyZHK8dFm/sPt0fNdTwStda+KHspp4J4YN0RVbqeHgx8nOciWrArLIJCJxC+f6NZT4YTfOOFANPLqrX+2djpgY/eg4YLcu5oEPOmkMwdF8Wz84xcsOq3sk8rAVhz9YbzdtBxiN8jfJoSumR6mRTokRlM1VUNhpJy/nONZoIZxEJ2SAj517gXgFp11l+XFuz9KSNLUEYf8l8ZD7rqoNlknRNniMnlabvjUpzgyDwiBh4lg6KW8yrJ1Rrbz8kJqexBeSc+LWCjMpA== X-YMail-OSG: jnUjI18VM1kPBQ0fvYM1dvrBd_bbjfp9mZTfx.V18C7Rzo95BcIJl1_nPlovy_2 sjHwA6tO3IOwv3QU74cd17mTTAnO1ZPyq4BP9yKegXfG5Wm1.QcaT3LoeeqsEyiMY7oXPgfbItRX tJQX6EJCvv6_szYeedu.cZjofqnANr05MdJ8A5q7TtNDCgzogVIAP2IUfKH0Wi6G9m_tHqctIp7J Pu5Ys0nXhXMxxFvivLeUYrYzocLnwsZyT4o86TfY6G8tSrILCMwVUa.NIGAWRVH.NoRpVF9f.0FY 11ZsQBFh5v9jquaXx2JXlq5pZSzxBm3XdUzMiSRl7_cJU0h36GVyCbM7djiiMDwl6yXHLky.4d13 ntlpSH4udHGKmYEAKi2p0zLsvz_YNr0w8N.r7ursTQIOxlxLWQrf3TpIHKA307HVIPnbNg2GVs5l YaDkNFAnXxlfzsCCESAu1GlMnjTfyz1foKRMaedV5QqiQgLooNnXtEeybynE3SACF4N6H1J_CZpZ liEFdKP.ScmzQs4eMYCiZvrmmvpBezjNrf87kmAVvvESJcVeuF5uRcN.BiV7uShIaJ6tuhXufJD1 gN4bQ0muaPgatO1Mec2VVfvfmbpi5fNgDLXemWwt7zV84pZw6LsnDH7wcfxrxd3HLmN7BNWTe5Tm vkAMqtvRX1qS4Czx20aYyqgK3ieVvsEY5obymHcKJ9Z5IGpxaiseyINyuVo82t1.kYHsn4c6uvL8 WrWR3evWdWRcDmNANvJA_02N.6eR9P5haAbxrGkHSD7GSu1RBHlWQhH6DoAfFOI4OmULtmf1Mam0 OXlSXz336vQY0UuWmQ0Lsfx.DA4I2w7GX3WUEJOPn3lmR08M7eoxQbLuundH2k0np3ff8BpdLcFr KOb6AJ_J70Dv4AZU.MMbddu9eEGsxF3Z2PoJBrAMmHFP_4PCSb1_9wT9J031hoFiGI_GJQM.y747 GIbui2YVNPUvfe6cwJm7QXKARmZb_sdjMRE2XYOs61nviuOGCZt_0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Sep 2018 01:16:24 +0000 Date: Mon, 10 Sep 2018 00:56:02 +0000 (UTC) From: Alex McKeever To: FreeBSD Current , FreeBSD Stable Message-ID: <784808865.2275376.1536540962286@mail.yahoo.com> Subject: FreeBSD 12 PowerPC CD/DVD images, no boot. MIME-Version: 1.0 References: <784808865.2275376.1536540962286.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12406 YahooMailIosMobile Raven/42997 CFNetwork/902.2 Darwin/17.7.0 X-Mailman-Approved-At: Mon, 10 Sep 2018 01:45:44 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 10 Sep 2018 01:16:27 -0000 I have a problem with trying to boot FreeBSD 12 on my eMac G4, 1.25 (Retail). It will not boot (inverts colors in the boot menu) Sent from Yahoo Mail for iPhone From owner-freebsd-current@freebsd.org Mon Sep 10 14:56: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 D62B61092005 for ; Mon, 10 Sep 2018 14:56:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DD6984B5A for ; Mon, 10 Sep 2018 14:56:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x236.google.com with SMTP id y12-v6so839516ioj.13 for ; Mon, 10 Sep 2018 07:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=0Zxu7UMCBX4wzTu2ijtJxPqkKpJETZIvLpyil806Yeg=; b=JtZAp9iIalQQCPqL4XUw9IPZ4lkQr74bvbDZZKaPhkVEkaGFgJjJAGFAlCDfKKC1Sj XxRMu5DXI6E79Uqcy2mjSRjEvlH2Itc5LWRrzm7K4a7iuI5x67eflVb7Xg1/BZSRJsD1 KwnV/ZJMCVeCyWFX6DMCXdUDwGCzogtJc6YFdU0OuASRWsVW1MXoI+/6eVG5om6H15tQ wNU+gvIqMLd/6T/df9odNSnzjZkexgP5rSDWPDdb7lVJjsKngGimztUeuFXqRNO5c9kh 5qSXqHTnfurPGbYoYIqzZ8UD6HJwsgDzymU4epnKjkzCprbwG8weQr1rV/Yp7sqrbBBy gGYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=0Zxu7UMCBX4wzTu2ijtJxPqkKpJETZIvLpyil806Yeg=; b=SvauZThsRYFD74RUG8EMUoE60WVlwoNfS9I3bU3D47VtveXYTM1FsT/QRE2yHSiSej MFeXDK/eNcXR0XS0NnVASi3xl059BWmucAYstNpayD1h8qlQrP3mhmg8esctqSxgj3i8 hmTXzqOWqVLKzhilzrJDelQUmySqswSQJzlvKEjCNHFsFzZlrqXFULFVDlR0BUDcnRBw /CVYr2ylZvLkIX/TaQ0wuiAzst2vXXQCFg6oqs6+2Xt4GJ7+KmbV7bucyuY8RlrT4+/c JASf+UBIuj4bPNKuElQWSwZ5QS1LIEC/gaCM4xO2yYHZfxcGOJJ/gBKXAN4WxOYkRVV1 4m/Q== X-Gm-Message-State: APzg51DVz6RP4j+jHMF+FbmGmL0PtjXVpJpkbmpbmbdTeYadx9nAyIU6 Ljli71vkTMamK3PdUBpX1KPfd88Y3AUWQATG+Bmffu7v X-Google-Smtp-Source: ANB0Vdbow7zSNNxhmw24C+ux5w9yWm0fr2xs3dC+KCTirlaMZJTG2/iXyMxabkSHb2huHMby3DTqF74EOwPNxA4Rrhg= X-Received: by 2002:a6b:e716:: with SMTP id b22-v6mr17802390ioh.239.1536591395452; Mon, 10 Sep 2018 07:56:35 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 07:56:14 -0700 (PDT) From: Ed Maste Date: Mon, 10 Sep 2018 10:56:14 -0400 X-Google-Sender-Auth: 6ETo42A2PJTnRvCfkwLtF9HtxS0 Message-ID: Subject: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: 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, 10 Sep 2018 14:56:37 -0000 The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 user@hostname:/path/to/freebsd/src and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 (Mon Jan 1 10:11:12 EDT 2018 user@hostname) With reproducible builds enabled the kernel ident looks like: FreeBSD 12.0-ALPHA5 r338195 and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 I would like to enable the REPRODUCIBLE_BUILD knob by default for the 12.0 release, and propose we do this by adding a step to switch the default to the list of changes[2] that re@ commits to the branch as part of the release process. [1] https://reproducible-builds.org [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html From owner-freebsd-current@freebsd.org Mon Sep 10 15:08: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 20EBA109264C for ; Mon, 10 Sep 2018 15:08:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E78685358 for ; Mon, 10 Sep 2018 15:08:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id d10-v6so29935289itj.5 for ; Mon, 10 Sep 2018 08:08:19 -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=CHZTUmZm/WbofM0OMGBdDHLh9+wnWRbtFyGhNJ1djBU=; b=lWHGvMy4YU9iG9uwoBurMjHR1zEAd/tUhenkvTd9SBhZL4ynjeBKqvhB+LCq6lgD8g 6lcTNGBeGBRaAY2IloJUlpnm3Oh+xxRdWNwFsYEXZ7NUELHZFwwwDOx+9tjebnok+FT9 I35UCEQDnfjI1xvLCCwaV8SK2B5DXbq5LUpjD00YHSt5+pZzIJUZsbipPGLA0u15V53K oy3alaorg8QiIlrfNm3lkRS3wg1kBXE0/YlV5+6+8FqJqG/vSmmDMMXN9FE7PuboXHd7 DgqpzoNKT16lnNLqAwJ8xf7IXCu8XiqtYVZ8uIGIaQ+thRlrbQau07eUL533Zp1er/sZ IFFQ== 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=CHZTUmZm/WbofM0OMGBdDHLh9+wnWRbtFyGhNJ1djBU=; b=tcGOY1s5Bfpz1vXfdWa6EHuJvz+Z7Kh9HH0EjqDLipP0N7YueFePtigf0DyY9G9OB+ FbZSpqgYhG1SL3krCafvvwBJ4k7OYMz8Iu3/8LpvaCb1NO13wKCy6Qw6P4p7mKcuJbn3 KbqlmU5ydwQ/JQsteP2CCAUbqXhwLFkUMXB9CwmWBf7Su6yXPEcVGTUxjpuVhJ5CXEpf ULVHshyctvwltey7Ld2G/Hln6cLIjX3Y5juOhtEEJeMQNP/5u2WMpl7Lb9MhtfaEaq/r vsBGwWBSgRMemW5MzJX9IUrS4GQ3/92hk4ffBtFiR+9xr92UXcn4MBiekCoiA1V8g/3a eowg== X-Gm-Message-State: APzg51DvSgcVjzQkl3mmnSsbnRHV44/wmc5B6gb4IwRKn13WEQID06KB PxPv+IKax1hEtXVVtahlqyOi50feWD7S6HhyVcxxjg== X-Google-Smtp-Source: ANB0VdYaMrrI2OxmZzfynO7F8oG7nfgOkW4qc3X/dFkpkn7HQl7BrRPR0JZdJ1O8SkRGv9bnDqfZMnmgBvREjT1/WVw= X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr18015514itg.75.1536592098667; Mon, 10 Sep 2018 08:08:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 10 Sep 2018 09:08:07 -0600 Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: Ed Maste 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: Mon, 10 Sep 2018 15:08:20 -0000 On Mon, Sep 10, 2018 at 8:58 AM Ed Maste wrote: > The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. > > [1] https://reproducible-builds.org > [2] > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html Turning it on, like we turn off WITNESS, for stable branches, I think this is a good idea. The loader doesn't really need the extra stuff to function properly, so dropping it is OK. Warner From owner-freebsd-current@freebsd.org Mon Sep 10 15:26: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 1C9A71093076 for ; Mon, 10 Sep 2018 15:26:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A821586776 for ; Mon, 10 Sep 2018 15:26:54 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x242.google.com with SMTP id 139-v6so29215683itf.0 for ; Mon, 10 Sep 2018 08:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=CzPdweXZKS1Kc8kcY9IwT8mwq2SgGgqBsTb/UUXu/j8=; b=HUxPOii4lJSxL9A+v/zbxasTeSSzxSYK8ReSdd9cAuH2btVyEpHHaIrowsA1WLbjwO CvkYVg/kStp4XSAYbM5/dQ98InZtw7fQxY6xiQnRdxq/w/IHt1xgag6cBckxncjh80wV mP2OjPHPaQ+Ze7YuA04T7FbpNhgXWg1oYVayZEYQTziwR/ttkvy2+GPXGh3XZzv7lVxp x9DwxpTtS1xibNayt5/XneAfnl6gQCTozZrbCazh/CBZuuIm6/A/3l9A+3oaBkQZkqmU j5hcKYCtWEI+eeQA57rzIRnv1jwEGeJ9HWfSx+HpYBX54UVwWA9xBla18xaRHgJMPk5v Rt1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=CzPdweXZKS1Kc8kcY9IwT8mwq2SgGgqBsTb/UUXu/j8=; b=ODVCNo6IGc67FzOqlYbCweRThi8gW4W3HuTP3llFzE2fZNhW2SaohmwLmvnLKfCaV8 65xGznIOPQVY6ErZYaBHTNx1gq5PRUYwFRnKw4IjIPEg+KZR11dspCCz1NryDLMk5Wk+ +U/jgEdrvxwLl6JEU7hyqUVf+iM1TV4k9uHJMRwFt2YtzSZZ3COnCSnDvMs2J/q6WWHf HC1Iva+BCxxGbiDiSEPfPEEXHfIVdRqxeqKRaFf11fef5MgtM5/p18wz083lVRRYCkY4 nn6pFh0ECudzFupTJgvwcaM0u/PGW4pd94/HOp6tNryrk29J52hSNDtWiMbmxccsJqgo bdAQ== X-Gm-Message-State: APzg51A2/Df7K8eGs+hveOfEHvY9HPvTChKb7h6kpC6pvNKQ3qhiugdt OzOeRfzQN0kbgPo8JuEy/NMmgpfXfTGegtOC16A= X-Google-Smtp-Source: ANB0Vdbat9fWZI6k26sZrs+CQS3lTEj/CWtRM2TFXKSZ4Fc0GLPDZo+49yiR2v3xDVcqUyIZvUFnkx7ILCQB8SPGvKs= X-Received: by 2002:a02:9a10:: with SMTP id b16-v6mr19031415jal.4.1536593214014; Mon, 10 Sep 2018 08:26:54 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 08:26:33 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Mon, 10 Sep 2018 11:26:33 -0400 X-Google-Sender-Auth: p_mLdKz-A1u8swY7y1UsIzwzj18 Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: Jonathan Anderson Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 10 Sep 2018 15:26:55 -0000 On 10 September 2018 at 11:11, Jonathan Anderson wrote: > Hi Ed, > > I think that sounds great. In the future, could we go even further and, b= y > default, only emit date/user/path if the source tree is =E2=80=9Cdirty=E2= =80=9D with respect > to SVN? If the build really is reproducible, that data should only be > informative when building something that doesn=E2=80=99t match a FreeBSD = SVN > revision (e.g., a Git commit in a local repo or a tree with local changes= ). Indeed, and I already have that support in newvers.sh: -r means build reproducibly and -R means build reproducibly if the source tree represents an unmodified checkout from a version control system. It's currently not hooked up to a src.conf knob, and we don't really have a great way to handle options with more than two states. We could have REPRODUCIBLE_BUILD always on by default, using the -R mode - something to revisit after we're done with the 12.0 process. Also, note that the build will currently not be reproducible between svn/git/tarball because the version control info is included in the ident strings. From owner-freebsd-current@freebsd.org Mon Sep 10 15:11: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 27476109297D for ; Mon, 10 Sep 2018 15:11:07 +0000 (UTC) (envelope-from jonathan.robert.anderson@gmail.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8E6F85958; Mon, 10 Sep 2018 15:11:06 +0000 (UTC) (envelope-from jonathan.robert.anderson@gmail.com) Received: by mail-qk1-x741.google.com with SMTP id b19-v6so14574509qkc.6; Mon, 10 Sep 2018 08:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=hOBPbAcpjQyLxEs97W9tmKlZFLgtvld19iWBsT25gu0=; b=HINQJDIFWyVpHfXATp2ea2P0AegQRCw2Y8YXXAv2pmMgMMooJZYHBfms2JGbGuwoHu bDDqCzdQKHvvblScpJGV534IxFQOHExYKzYC83imgt+vl/jS56ZGHgiKSp4GaetxNk1I 3kLz1lIOIaaCu8U+vM9zBWuXZa6y/UKMyh/FmzoUZgS6iUBNka/vFj+JiyTSfDAWkEXy iMCtHjPBn7WCVZlulaItY0EYOynTDhHWM/avqVsL8d4q+xtJELJCzh3F0PEHLGr3vFSz DAGq0ZQe+tWRn/R4/2NoP3N0u31tfYQPvtP9zDgGNgAweAtKinMnBvsr8dB77NHFsXC9 n6Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hOBPbAcpjQyLxEs97W9tmKlZFLgtvld19iWBsT25gu0=; b=qyeNnSsjTnbYDQyrwMvLKq35X3tADF0vo3hzwKfiSJnB0eipzEGF79Y8Pb1Y9lRAl6 Or8lgwqBJoawVC9PsMugCk1TgS0R13FZ6Qm6hPrxy6h1wRmZ6A+r164caUaWVwr/+80h c82pNz1lftvkDRJYpNz1IJa/agjU4/mfB8ruhNM4a6xdHNdBX5ozH8SXggWxDqM1NjEk kcuX/5P3vToi2IAWZB3VWWktTwyFSCBrYzvTPzvmUUZ81N/sjirh4E3mbuRD7e9mOLID tlh9JaEBaYZvcRsBJwxPcCLVeRuBe2+nMecDquxNywL8x5lvdisFGoRHWQbfSeATUBdR N5vQ== X-Gm-Message-State: APzg51DfWPGa7Z7moFQlk1WOEadwK+KYPOyqROJSwU9PITEi79NHAHfU pyjDlUcgGKIE7VPgrNALqd6OlDw= X-Google-Smtp-Source: ANB0VdaPB1K2XSyXV4QraO+RQGyCPg6Qd9CrZlPykLL6sqWEnHoPTXHnb0XSClsf/MT3KV5cD+9K+w== X-Received: by 2002:ae9:e64b:: with SMTP id x11-v6mr15560265qkl.41.1536592266075; Mon, 10 Sep 2018 08:11:06 -0700 (PDT) Received: from [134.153.15.109] (n015h109.wst.mun.ca. [134.153.15.109]) by smtp.gmail.com with ESMTPSA id x26-v6sm10645914qth.15.2018.09.10.08.11.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 08:11:05 -0700 (PDT) From: "Jonathan Anderson" To: "Ed Maste" Cc: "FreeBSD Current" Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL Date: Mon, 10 Sep 2018 12:41:00 -0230 X-Mailer: MailMate Trial (1.12r5523) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 10 Sep 2018 15:27:56 +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, 10 Sep 2018 15:11:07 -0000 Hi Ed, I think that sounds great. In the future, could we go even further and, = by default, only emit date/user/path if the source tree is =E2=80=9Cdirty= =E2=80=9D = with respect to SVN? If the build really is reproducible, that data = should only be informative when building something that doesn=E2=80=99t m= atch = a FreeBSD SVN revision (e.g., a Git commit in a local repo or a tree = with local changes). Cheers, Jon -- = jonathan@FreeBSD.org On 10 Sep 2018, at 12:26, Ed Maste wrote: > The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. > > [1] https://reproducible-builds.org > [2] = > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/rel= eng-head.html > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Sep 10 15:45: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 62D451093A1A for ; Mon, 10 Sep 2018 15:45:58 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B89B987627 for ; Mon, 10 Sep 2018 15:45:57 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf1-x12c.google.com with SMTP id x26-v6so17831442lfi.7 for ; Mon, 10 Sep 2018 08:45:57 -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=xaZdsG+Fgju+b9VrGdFBKBqG9qjQD9vdzyu8agXe6OQ=; b=o+utA90rL3to3FL4eoapR85D3rk4sLq5lDCX1FpO88kj5LIewNDvrR+YYomoeCqrFk caAiJOGp6Oah9sx5yOfpMU0cMYuTmelraVG2VEfhO9jZ+Dh8Mp588BoRA+hWrBfDnM/K 2FzeOR72K2RyISP6i2rEdAy+0/v5JfVMQxjHQRfTrOksnnVX3ZJDWcyv/x5TmwLNiAph 5hPLijl3pzIQUK0GIN0SlIpwO3MFtbXIpwWozUBRiCAsXe2XbpAB7thURvs8xAAiwvSa ViffRkol08Er6Izo2lPzHhSDHJbegf8tvvtPqKNb8iPOMJ7tI/Az6bit2uvnrIApiFQg Fg2Q== 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=xaZdsG+Fgju+b9VrGdFBKBqG9qjQD9vdzyu8agXe6OQ=; b=qcYfRCNFFRsku8mskZ5sHuVG5o5rAU1UOHgwj97g7SeC7DsFdxQfZ7n9YY6pvWKUxD KmzZo+3y7bZq8RUCsbtsIcay4hwxvS3TzpmCz7GnrKoPUvViHzsZesgVF7WG9nYNHwga 3Fwh6H1bgtWnYKgHFOlHglAX4BY3To3WTT/VGb5V6P3Ay/1br354WAhaTAEbWr9S0yhJ tTW+W/DNyVZDMFDdbkOaAAkK5kQm6LJ4q6SU1GAwGgHE+viBLtwGihHrT3/lpFMKCht/ ijXEQNg7YdEhlFeHkwzJ2H8ab9IFmQIXKpRz3UTftd/YDhibMDJyYq34yvV89zYHpQZZ UlIw== X-Gm-Message-State: APzg51DYss5WjYDSUiiE8XcKoRct9D4wovVANu2UsguB9RL3xrdbl+WX TL2p6BAW1DuLXEK1SFGlVrLu5uo72Qikm+rYyLdXs1C9 X-Google-Smtp-Source: ANB0VdaRqX1g2sRpA0wGIBKxnJJbxFa4FYCackRZ9pZ2TAxjWmc8gST7ooDwfJsQFQOoxM0atccFOFXTCAUS2hy5U9k= X-Received: by 2002:a19:1388:: with SMTP id 8-v6mr13496513lft.12.1536594355679; Mon, 10 Sep 2018 08:45:55 -0700 (PDT) MIME-Version: 1.0 From: Andreas Nilsson Date: Mon, 10 Sep 2018 17:45:43 +0200 Message-ID: Subject: make packages fails recent -current To: Current FreeBSD 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, 10 Sep 2018 15:45:58 -0000 Hello, I have for about a week been trying to get new (base)packages built. make buildworld/buildkernel works as expected, however make packages has been failing: ===> Creating FreeBSD-runtime-12.0.s20180910124534 pkg: duplicate directory listing: /boot, ignoring pkg: duplicate directory listing: /etc, ignoring ... pkg: duplicate directory listing: /etc/syslog.d, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: Plist error, @config /root/.cshrc: not a regular file pkg: Plist error, @config /root/.profile: not a regular file pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring pkg: duplicate directory listing: /usr/lib, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib32, ignoring ... Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode for building. I'm currently building from scratch just to rule out metamode. Best regards Andreas From owner-freebsd-current@freebsd.org Mon Sep 10 15:55:18 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 A6FDD1093E58 for ; Mon, 10 Sep 2018 15:55:18 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21B22884BC for ; Mon, 10 Sep 2018 15:55:18 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-pl1-x62b.google.com with SMTP id p5-v6so2469187plk.3 for ; Mon, 10 Sep 2018 08:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=phnHCzAbW1gbH5z5inzNDrPZ5GI11rP8jgPv93ihlak=; b=tfIXk5hbRTtqmVyOEIUtB8uQi32DIVgsQZk4DtZdzIIIQZb24OHYeiCCWISuXtZSHg lY0rhxjRVSiIqQH3/O6KoeyEk9cKeEOe1G8aIdDox8W/83ab9OGe8sbLG/VHeTlL9P9o GDIl9kDHbBMvzJWtxN1exq1tHzCAyj30QRFv09ujSp1HgKCSl5mcwWfONwirJzSikvNa OPcNm7GfIuhH5MlYdsGoDNL8H6pX8p/s4h5+JDJQqD1KsOtdHIyO/ZhBnWcrekP4z7vS d616fEQcV2SezMuk/4Dzj+9QY8y4R+3tkJrvf6tCKOQk0SyXIHi2UThovn30b0VipE6m UTbg== 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=phnHCzAbW1gbH5z5inzNDrPZ5GI11rP8jgPv93ihlak=; b=Ch7uuA86ut+PsXac7ozHhFFBqLKcCohm/ru1/N9gh7kFy/adF5npSqOvxxZrQWS1mP cztPe7z4S1FbNGBvNKsfFAlAn75r0RXGqPZnJLsm8q5epEFv8NutRDTe/Dq1XKyF8Jhq O//7nu1A3savttsQaKo6JD/zuM7kRZIXPcUp0O1WxJuwwR6YlzqeolwF1kvInvZZjAbW Z9HRjKDPAfS2INUZbbdWgUI2uqva4csj2Gqrh2s/g7JIc/EAYVX4z6DZRw8nmyUb2g0m qnayY17ZaSsMrg3cdaV2bHwHih/k7+iROhVJN9BGxJtZ0Z08ePPGPKEu41Uk1OPK8nGZ /Lbw== X-Gm-Message-State: APzg51Dql2LBXMCfGkqpAqbyqVP9RRIaFTWouzUhsdncHv0Qs65Ty2ey UaPscUEClAgfyQJ7++naq0dJyPeNhkaz2Unxkyg+rtQL X-Google-Smtp-Source: ANB0VdY38VFjVwYT1jOgx/EDShvMhdQPqPQ2mfUlpLxf7JOcCnkkltq0bpEVqqDnLKwHyetnLRrSIk9vqyiO78WAdWA= X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr22518651plb.172.1536594916987; Mon, 10 Sep 2018 08:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:d98e:0:0:0:0 with HTTP; Mon, 10 Sep 2018 08:54:36 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Mon, 10 Sep 2018 17:54:36 +0200 Message-ID: Subject: Re: make packages fails recent -current To: Andreas Nilsson Cc: Current FreeBSD 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, 10 Sep 2018 15:55:18 -0000 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : > Hello, > > I have for about a week been trying to get new (base)packages built. make > buildworld/buildkernel works as expected, however make packages has been > failing: > > ===> Creating FreeBSD-runtime-12.0.s20180910124534 > pkg: duplicate directory listing: /boot, ignoring > pkg: duplicate directory listing: /etc, ignoring > ... > pkg: duplicate directory listing: /etc/syslog.d, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: Plist error, @config /root/.cshrc: not a regular file > pkg: Plist error, @config /root/.profile: not a regular file > pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring > pkg: duplicate directory listing: /usr/lib, ignoring > pkg: duplicate directory listing: /usr/lib/dtrace, ignoring > pkg: duplicate directory listing: /usr/lib/dtrace, ignoring > pkg: duplicate directory listing: /usr/lib32, ignoring > ... > > Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode for > building. I'm currently building from scratch just to rule out metamode. > See https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html From owner-freebsd-current@freebsd.org Mon Sep 10 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 B2C9B1094B3E; Mon, 10 Sep 2018 16:28:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 33DF1899EB; Mon, 10 Sep 2018 16:28:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-24-18-193-141.hsd1.wa.comcast.net [24.18.193.141]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w8AGSkTX080355 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2018 09:28:47 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current , "freebsd-virtualization@freebsd.org" From: Julian Elischer Subject: a little secret info on AZURE VMs.. Message-ID: Date: Mon, 10 Sep 2018 09:28:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; 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: 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: Mon, 10 Sep 2018 16:28:55 -0000 Apparently if you publish an Azure image to their marketplace, they blindly store billing information at location 65536 of the VHD file.. so you need to ensure that your first partitions start after that. if you use a layout with your first partition starting at 64 sectors in, this location falls in the middle of your boot code. So it fails to boot. I haven't found any documentation of this yet.. Julian From owner-freebsd-current@freebsd.org Mon Sep 10 16:51: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 82AD71095A37 for ; Mon, 10 Sep 2018 16:51:20 +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 088188B30B; Mon, 10 Sep 2018 16:51:19 +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 w8AGpB3l078812; Mon, 10 Sep 2018 09:51:11 -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 w8AGpBDl078811; Mon, 10 Sep 2018 09:51:11 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809101651.w8AGpBDl078811@pdx.rh.CN85.dnsmgr.net> Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL In-Reply-To: To: Ed Maste Date: Mon, 10 Sep 2018 09:51:11 -0700 (PDT) CC: 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: Mon, 10 Sep 2018 16:51:20 -0000 > The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. Why not just turn this on and leave it on? > > [1] https://reproducible-builds.org > [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Sep 10 17:05:00 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 2D03E10961F4 for ; Mon, 10 Sep 2018 17:05:00 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 CD35F8BCCA for ; Mon, 10 Sep 2018 17:04:59 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id B23085646F for ; Mon, 10 Sep 2018 12:04:58 -0500 (CDT) To: freebsd-current From: Eric van Gyzen Subject: Request for Review: Generate /etc/services from the IANA registry Message-ID: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> Date: Mon, 10 Sep 2018 12:04:54 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.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: Mon, 10 Sep 2018 17:05:00 -0000 Would anyone like to review this change to generate /etc/services from the IANA registry? https://reviews.freebsd.org/D17106 Thanks, Eric From owner-freebsd-current@freebsd.org Mon Sep 10 17:10:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA9741096418 for ; Mon, 10 Sep 2018 17:10:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 920FE8BF2E; Mon, 10 Sep 2018 17:10:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id B710410AFD2; Mon, 10 Sep 2018 13:10:32 -0400 (EDT) Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: "Rodney W. Grimes" , Ed Maste References: <201809101651.w8AGpBDl078811@pdx.rh.CN85.dnsmgr.net> Cc: FreeBSD Current From: John Baldwin Message-ID: <236dc4bb-956a-a103-9f59-a3492d9866f3@FreeBSD.org> Date: Mon, 10 Sep 2018 10:10:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <201809101651.w8AGpBDl078811@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 10 Sep 2018 13:10:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 10 Sep 2018 17:10:40 -0000 On 9/10/18 9:51 AM, Rodney W. Grimes wrote: >> The FreeBSD base system is a reproducible build[1] with a minor >> exception: the build metadata (timestamps, user, hostname, etc.) >> included in the kernel and loader. >> >> With the default, non-reproducible build the kernel ident looks like: >> >> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 >> user@hostname:/path/to/freebsd/src >> >> and the loader ident: >> >> FreeBSD/amd64 EFI loader, Revision 1.1 >> (Mon Jan 1 10:11:12 EDT 2018 user@hostname) >> >> With reproducible builds enabled the kernel ident looks like: >> >> FreeBSD 12.0-ALPHA5 r338195 >> >> and the loader ident: >> >> FreeBSD/amd64 EFI loader, Revision 1.1 >> >> I would like to enable the REPRODUCIBLE_BUILD knob by default for the >> 12.0 release, and propose we do this by adding a step to switch the >> default to the list of changes[2] that re@ commits to the branch as >> part of the release process. > > Why not just turn this on and leave it on? For kernels not built against a pristine tree the extra info is useful to have. For better or worse, kgdb also parses the path to try to find kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it won't be able to find the matching kernel using its current logic. crashinfo uses different logic so will still work fine (crashinfo looks for all the things matching /boot/*/kernel and tries them all until it finds a match). -- John Baldwin                                                                              From owner-freebsd-current@freebsd.org Mon Sep 10 17:20:14 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 16A251096A6D for ; Mon, 10 Sep 2018 17:20:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87AA48C7DD for ; Mon, 10 Sep 2018 17:20:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 5FE8910A87D; Mon, 10 Sep 2018 13:20:12 -0400 (EDT) Subject: Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted' To: Michael Butler , Konstantin Belousov References: <524214ac-e3ca-53cd-aee3-dac9212e9800@capeaugusta.com> <0aa35f96-9f62-bfca-c04a-f6ddcb1ce738@FreeBSD.org> <8ed7961e-e12a-9267-2bd0-a9bcbe383c7f@protected-networks.net> <20180831052805.GP2340@kib.kiev.ua> <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> <20180908194316.GI3161@kib.kiev.ua> Cc: Ian FREISLICH , freebsd-current From: John Baldwin Message-ID: <1918dda4-e9e5-a7bd-09e3-b3a70fcccd01@FreeBSD.org> Date: Mon, 10 Sep 2018 10:20:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 10 Sep 2018 13:20:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 10 Sep 2018 17:20:14 -0000 On 9/8/18 1:44 PM, Michael Butler wrote: > On 9/8/18 3:43 PM, Konstantin Belousov wrote: >> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >>> On 8/31/18 1:28 AM, Konstantin Belousov wrote: >>>> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: >>> >>> [ .. snip .. ] >>> >>>>> I see another problem after using Ian's workaround of moving the #ifdef >>>>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >>>>> machine with only 512MB of RAM: >>>>> >>>>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >>>>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >>>>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed >>>> >>>> What is the kernel revision for "now". What was the previous revision >>>> where the kstack allocation failures did not happen. >>>> >>>> Also, what is the workload ? >>> >>> Sorry for the delay. Any version at or after SVN r338360 would either a) >>> not boot at all or b) crash shortly after boot with a swarm of messages >>> as above. It was stable before that. >>> >>> Unfortunately, this machine is remote and, being as old as it is, has no >>> remote console facility. 'nextboot' has been my savior ;-) >>> >>> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, >>> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an >>> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a >>> router/firewall with few actual applications running. >>> >>> As another data point, I manually reversed both SVN r338360 and r338415 >>> (a related change) and it is now stable running at SVN r338520, >> >> It is very unprobable. I do not see how could r338360 affect KVA allocation. >> Double-check that you booted right kernels. >> > > FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 > r338520M: Thu Sep 6 21:35:31 EDT 2018 > > 'svn diff' reports the only changes being the two reversals I noted above, Can you get the output of 'x num_io_irqs' at the DDB prompt after the panic? -- John Baldwin                                                                              From owner-freebsd-current@freebsd.org Mon Sep 10 17:44: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 61FB010974EB for ; Mon, 10 Sep 2018 17:44:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBE3D8D5AF for ; Mon, 10 Sep 2018 17:44:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x233.google.com with SMTP id p129-v6so29803178ite.3 for ; Mon, 10 Sep 2018 10:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mPfVsvpsSjZvGvUgN6txNUjmT7DSO9qjxWG3+aCCFlc=; b=uxPXlpxbA4DT9rceIwUhJX/onIC6bCSHidl4YRxx8U6XT/82mpz4GOydAUb9M+YQSq tqpccB8umMba680O1TKONH1CUELrru3JUhfYGEQWjfGvvODxGbAa4OpCEUDe3CBS0lmB af9CqDMWphHVh5XS3MVVC3PxmLANkgX1HE5pMVzOmZSQnA202RBZPLBOnZIfa4Tm1kCq QCRXCZdgzYMzk8RJ7tdgO3U+G27CKEJgzzekOP2bqAN4m8pKCBl8TmmdmZWQWSWUpiy0 ZsnzcgbT9OMaMpLt+5ypnu4GOrui6grkfSP+B2e6mSXeEl0gR2ahyD9CWevuXljpWazW btYg== 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=mPfVsvpsSjZvGvUgN6txNUjmT7DSO9qjxWG3+aCCFlc=; b=R52gH4KcYO9+prFITTutMhKRwfYQcyhqiQBqftnKFbNbF0woVnBhLE8b49uyk6ck7I c7+nNumnpVBNPMHZxPUXrtRv8em6Jo/FCrEo8uyFgP7XY6RO4g2ec1vKqD0n4eJ1tKnb iTFxzGkM3f2WGqZxPdj+djgIOGlaetP/8v8wy8zLDjmBo2gargHzZCVNJ//wn9e+A0SZ cccZCiAyiFKeQHsPFgY+f6U7nFHZzhazM9zGXDv5SlRvpI0sslQAi7SUa9WX3eTTsOSt tvC8sqLmzmPNBdn3qhDtrYRJ7lNBQVkaoz133is2ugnx41/eOHZj15jqFuhz6dJLgssP W+7g== X-Gm-Message-State: APzg51CmPe6zQtUB7h3uc7g0CmboKeULvORlwr+V8tWkZ8LkOTTS59Sg wBWMcK46ORCwYua3zURC3bSyPpoSa5UjYtQxWDd+gA== X-Google-Smtp-Source: ANB0VdZaboJZKs7hOO8naTaWaR2YOlZZg/vmgZ/U902MN3uc8dvYa0tW2TBArrxO3scgcFoPL9boMqf8e217m4VHIFQ= X-Received: by 2002:a24:b804:: with SMTP id m4-v6mr18851668ite.72.1536601458010; Mon, 10 Sep 2018 10:44:18 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 10:43:57 -0700 (PDT) In-Reply-To: <201809101651.w8AGpBDl078811@pdx.rh.CN85.dnsmgr.net> References: <201809101651.w8AGpBDl078811@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Mon, 10 Sep 2018 13:43:57 -0400 X-Google-Sender-Auth: 0danLFAMywwIp32uPy8jAyNPL3w Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: "Rodney W. Grimes" 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, 10 Sep 2018 17:44:19 -0000 On 10 September 2018 at 12:51, Rodney W. Grimes wrote: > > Why not just turn this on and leave it on? I know a number of developers want to keep the metadata for their own builds at least. We have essentially three different levels of metadata that are arguably sensible: 1. Major/minor version, release/branch name, architecture 2. Version control information 3. Path, user, date, time, host And three kinds of working trees: 1. Non-versioned with/without modifications (e.g., a src tarball) 2. git/svn/other checkout, without modifications 3. git/svn/other checkout, with modifications What I'm proposing for 12.0 gives us 1+2 always (regardless of the state of the tree). I think there's more discussion to be had on the mapping between the tree type/state and amount of metadata to include. If we come to a consensus I'll handle it, but don't want to hold up a change destined for 12.0 with a broader discussion. From owner-freebsd-current@freebsd.org Mon Sep 10 17:55:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7554109798B for ; Mon, 10 Sep 2018 17:55:03 +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 3A0368DCAF; Mon, 10 Sep 2018 17:55:02 +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 w8AHt0W0079064; Mon, 10 Sep 2018 10:55:00 -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 w8AHt0Yo079063; Mon, 10 Sep 2018 10:55:00 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809101755.w8AHt0Yo079063@pdx.rh.CN85.dnsmgr.net> Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL In-Reply-To: <236dc4bb-956a-a103-9f59-a3492d9866f3@FreeBSD.org> To: John Baldwin Date: Mon, 10 Sep 2018 10:55:00 -0700 (PDT) CC: Ed Maste , 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: Mon, 10 Sep 2018 17:55:03 -0000 > On 9/10/18 9:51 AM, Rodney W. Grimes wrote: > >> The FreeBSD base system is a reproducible build[1] with a minor > >> exception: the build metadata (timestamps, user, hostname, etc.) > >> included in the kernel and loader. > >> > >> With the default, non-reproducible build the kernel ident looks like: > >> > >> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > >> user@hostname:/path/to/freebsd/src > >> > >> and the loader ident: > >> > >> FreeBSD/amd64 EFI loader, Revision 1.1 > >> (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > >> > >> With reproducible builds enabled the kernel ident looks like: > >> > >> FreeBSD 12.0-ALPHA5 r338195 > >> > >> and the loader ident: > >> > >> FreeBSD/amd64 EFI loader, Revision 1.1 > >> > >> I would like to enable the REPRODUCIBLE_BUILD knob by default for the > >> 12.0 release, and propose we do this by adding a step to switch the > >> default to the list of changes[2] that re@ commits to the branch as > >> part of the release process. > > > > Why not just turn this on and leave it on? > > For kernels not built against a pristine tree the extra info is useful to > have. For better or worse, kgdb also parses the path to try to find > kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it > won't be able to find the matching kernel using its current logic. So this means stable/12 users would have hassles getting kgdb to work? > crashinfo uses different logic so will still work fine (crashinfo looks > for all the things matching /boot/*/kernel and tries them all until it finds > a match). > > -- > John Baldwin > > ???????????????????????????????????????????????????????????????????????????? > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Sep 10 17:57: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 C3FB31097A87 for ; Mon, 10 Sep 2018 17:57:54 +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 4546B8DE34; Mon, 10 Sep 2018 17:57:54 +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 w8AHvqbo079080; Mon, 10 Sep 2018 10:57:52 -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 w8AHvque079079; Mon, 10 Sep 2018 10:57:52 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809101757.w8AHvque079079@pdx.rh.CN85.dnsmgr.net> Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL In-Reply-To: To: Ed Maste Date: Mon, 10 Sep 2018 10:57:52 -0700 (PDT) CC: 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: Mon, 10 Sep 2018 17:57:54 -0000 > On 10 September 2018 at 12:51, Rodney W. Grimes > wrote: > > > > Why not just turn this on and leave it on? > > I know a number of developers want to keep the metadata for their own > builds at least. And we do not really know what the users position is on this... and developers also run on stable/X, they may not like this flipped there, though IMHO we should not be catering so much to developers, while shooting users. > > We have essentially three different levels of metadata that are > arguably sensible: > > 1. Major/minor version, release/branch name, architecture > 2. Version control information > 3. Path, user, date, time, host > > And three kinds of working trees: > > 1. Non-versioned with/without modifications (e.g., a src tarball) > 2. git/svn/other checkout, without modifications > 3. git/svn/other checkout, with modifications > > What I'm proposing for 12.0 gives us 1+2 always (regardless of the > state of the tree). > > I think there's more discussion to be had on the mapping between the > tree type/state and amount of metadata to include. If we come to a > consensus I'll handle it, but don't want to hold up a change destined > for 12.0 with a broader discussion. I think there is more discussion to be had before we flip this knob anyplace. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Sep 10 18:27:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFE671098463 for ; Mon, 10 Sep 2018 18:27:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 385028EEF4 for ; Mon, 10 Sep 2018 18:27:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id j26-v6so10885046pfi.10 for ; Mon, 10 Sep 2018 11:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=E8SpR3QIqrVoLeQzmWDzGbCBUMe8SW9kNTj2S+zrfMM=; b=Wp6mkci8fy06vdQO0O6hU9iJ7+korW0Xbt9TDqHDbXGC+vbPMHxzvXIYv0VY1jG0aD 8APp2ORbaK8jvmuxgHBiDPK5gfiCmvdoS3Wa45nyRInH8fh+TEdGkgaHRxW901m5ifth KtViH+EB2PNkbBEPHn/va5g6l3drVZ5ayaX0xJv/+1Mp5gLNz9diEYrtjiEidYWsxnpZ NU9ej//FEy2x2535qjyP1Xihon94pwsVYx0TN64XWIKDAB6MlKaOdPqEe/8MCwHhMEiG POZNZdftA0uNj73MNgSSDDnlB/fpEJUoFjI/CvWLankhLM0dMXhxI6DrIXx+9HTfR9C6 N+Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=E8SpR3QIqrVoLeQzmWDzGbCBUMe8SW9kNTj2S+zrfMM=; b=FtH4OvgSHSt78UqCiIr0LuoIUUF9F3OZfpKYQ5GNfMpBmW/15+6x/bGEdiuVNskvNi m15XWf3DK6qQDloMQUF883epO/zTLrPHqFs8bQZJ4vKVs5nI3Y/guJbpQHi2VyOmrMjC dzNKWlwwoRHzRAWJipokDNid66yXeu9xE576/lYMvp1ikyTfPwISetEd724U9hyTv3zD wielBCLwHndSVYZ/UxOSR6JCWXajfTQgnhgzgdJ2Egx+IwXcUpAV5/EBe0HQj7XbHbeH mKTk7rFT8r57W7im9Vof/BNndGn6Ot2TuTDJH7aDPHvvEr/dxYINVYNrngN817bEfbV7 3r3g== X-Gm-Message-State: APzg51C1q9lRJEO4ptB66oflSxjIusoe4XCZGIqRC0hv+PbROJntE4wQ eCDmgIvlU57jjrmEzGZBTIMJWJsZ X-Google-Smtp-Source: ANB0Vdb5O+DmA7NTGhVestr3RxP+PW2CRbUYXiHkmnxuAk9rO77sIuy8azHrfCj0iQbpISXp55WD6g== X-Received: by 2002:a62:cdcf:: with SMTP id o198-v6mr25274782pfg.12.1536604021759; Mon, 10 Sep 2018 11:27:01 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id 70-v6sm23971428pfz.27.2018.09.10.11.27.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 11:27:00 -0700 (PDT) Sender: Mark Johnston Date: Mon, 10 Sep 2018 14:26:55 -0400 From: Mark Johnston To: freebsd-current@freebsd.org Subject: testing early microcode loading Message-ID: <20180910182655.GA2849@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) 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, 10 Sep 2018 18:27:03 -0000 Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install /boot/firmware/intel-ucode.bin. This file contains a copy of every Intel microcode update supplied by the port. Per the pkg-message, one can enable early loading of this file by specifying: cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" in loader.conf. The update will be applied upon a subsequent reboot. Testing consists of enabling early loading and verifying that the CPUs report an updated microcode version. If early loading fails, a message is printed to the dmesg. If your system is capable of successful ACPI suspend/resume, it is useful to also verify that the microcode remains updated following a resume. To fetch the current microcode version, use sysutils/x86info: # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0000000000000020 Compare with the version installed by the microcode_update rc script at run-time: # service microcode_update onestart Updating CPU Microcode... Done. # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0000000000000020 If your testing indicates that the boot-time loading method doesn't work, please include the dmesg in your reply. Thanks in advance. From owner-freebsd-current@freebsd.org Mon Sep 10 18:52: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 3A3A31098DF8 for ; Mon, 10 Sep 2018 18:52:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C51678FD82 for ; Mon, 10 Sep 2018 18:52:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x232.google.com with SMTP id p79-v6so30951788itp.3 for ; Mon, 10 Sep 2018 11:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WZlxLNsJ7fyscwRNVep+qm4ZAIYTryswK5hSbsSq8mI=; b=o7zuSaKw6fPLfhH6E2AoTST4QPgqQQRRFKrfNipzkc0e/UWBK+2C2uQN8RTB0kKSrK DLqYEnvgR9omt7o2CJJ0FXoPLc0x/45WhbGJ0e144ks1R/h6X/b7IgOI+/JDz2v0BPzc lrW2dJ0+kgiLdIB2cQ/IQIfwozjYYpsYpaLD3BIPnPG6CqlRPrEAD7FNj9do4IF/dFCL q31Bwua2Mgn4sP4Xwr2Go65fKwPU+bjggMzYh5piBV0it2SuIMK3FNlqq58pmz7y1Qh9 vp6/C6zTHBvTp5ekk8s+Wt25Qt+KGuRqItwNbTFvAXew3SWvoJ+GsWIj3BzyZfFrBJ/C v6ew== 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=WZlxLNsJ7fyscwRNVep+qm4ZAIYTryswK5hSbsSq8mI=; b=H63TFgOTUYGqNXDLih1o3U9tBXKoAcuKkatLwRgTpHsap68Am7UGgRSd6xsc52jT3h cpEce9aar/6f8QhGuYJbPT2Sd/EllkKQAC6BbVNgR6aEnh63MjpPKVD+ZXU5DgL2peEI 2UATP955FRF9s7VfQb3Jr4yrn/F+h/2A6WLFUvjO96AP/GL9gJEJxRwTU2fyvU9lRUbf MtV89U5nya1Y7ZOkZR7Iup4+G8IpQkoDyJw8+DHZFLT+tzXFrTyFVa8KqKRj8XM0axb/ BwbTjJEfn20G+OniK50fXMc+MX9hrwevZ/+Liz1XT6pwl5fTEZ5hMrAXWjeOj/nXcjYv ITBw== X-Gm-Message-State: APzg51DRDJjJ5cypvqb/avp45pkAdaEGmNcHFzcm2KqYNILjM4f+73e9 rqoc6aDgbi9Exfu+Pe6ZIPzrHQ3qAzwwdIttnv6XnQ== X-Google-Smtp-Source: ANB0VdbDtGadljP9VotieCB6c5ElAtx8GJ4fTwi4kXi1Kwu3MUeuB+IalIUHVbtfJWNYRV65yJiSZBb5EDowzTAKuyw= X-Received: by 2002:a02:9a10:: with SMTP id b16-v6mr19923430jal.4.1536605556249; Mon, 10 Sep 2018 11:52:36 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 11:52:15 -0700 (PDT) In-Reply-To: <201809101757.w8AHvque079079@pdx.rh.CN85.dnsmgr.net> References: <201809101757.w8AHvque079079@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Mon, 10 Sep 2018 14:52:15 -0400 X-Google-Sender-Auth: va5L8i1eRoEzkYREIn5y8orABgs Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: "Rodney W. Grimes" 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, 10 Sep 2018 18:52:37 -0000 On 10 September 2018 at 13:57, Rodney W. Grimes wrote: >> >> I know a number of developers want to keep the metadata for their own >> builds at least. > > And we do not really know what the users position is on this... If users are building FreeBSD from source they can set the knob however they like. Users of our prebuilt binares/releases are the ones who benefit from reproducible builds, and they're the ones unable to set it. > I think there is more discussion to be had before we flip > this knob anyplace. I brought this up on -arch in 2015, and gave presentations on reproducible builds in FreeBSD at BSDCan 2016 and AsiaBSDCon 2017. I believe we've had ample opportunity to discuss this in the context of what makes sense in a binary release, but there are still reasonable open questions about defaults in HEAD. From owner-freebsd-current@freebsd.org Mon Sep 10 19:08:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC9A810992C1 for ; Mon, 10 Sep 2018 19:08:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 840A47064B for ; Mon, 10 Sep 2018 19:08:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id h20-v6so30161713itf.2 for ; Mon, 10 Sep 2018 12:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wjqDYndK61/6QYeSEutp9drWLyJTRKZA0fEu3v8uSU8=; b=eRmnasLCCl4CJpeXPmnIyKDgOFlvU+Gbb/1PvJ6jHyJB7P7JKa/PKQ6r6EoUxraqFh lH5okVczcAfgzbqEaH8Y5CXrhIFdxW1vDVSTMuzEvPdQf4gg86j03sZt8LXKEc+M+ftC 92u1j7EsQesD9rGL2AmMJ+56rvEdGXljybpLJqw5F1qBP4LcM2h9YYFHXNSI73GTEV79 uNLNK8lchdLl3I4frzeJooQFc2jSEp4SblXYpdkRRd/zlhF40/MmaeSXi2Wi02s1Qher 8fyNAM4ia/6tb8OaQNJqLZsNoXc5kJaG48f80SX+ku4VW+6emC4nF/5Gieo3sIOAfyT1 vnQg== 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=wjqDYndK61/6QYeSEutp9drWLyJTRKZA0fEu3v8uSU8=; b=ZXZ/U6hKejDxt8ZFXl5Kd+HmxaZvxzZG9tQdNi7HLtz8vlcRPAwBiAYF1ZtSNtydmC Yf4nTmviJNsDQTSPGUTHBCe+kph2UbFg8NNyalPldSbThtk0jl9+E/rSWx1ipiJFKxAp ILYMX9AlW2LNcVxjvfNl+eSgQULNl4HOCJIVBC5F0BRiSVbNjaF+yuecVg7q45rinHLW g/OWz14uzm2uQ196YiS5Oqb1g6cawzhAR6xnh+WOxkwBBRezt1c/IjFHSEbnp/jmfIJD pfppPNdK5RbIDweqWQLPw8qAo+rVnh+jV/+3UL5yX83uBwzqPyiDRjP6UnABwHp6GVbE 7TYw== X-Gm-Message-State: APzg51AhdZ14EL2H+ycZm58abu0FX9PTp37TNl1pWmhiKFCgx6C1TF8j yovOMnNmofPp0tb2xpCLHvcsS3dV1Q5cdUrdNhY= X-Google-Smtp-Source: ANB0Vdb6ha4SRQFk1voaN5RZXgGRQpwRdEiWWoolvAjzHjAmX/VNlSjo+0P4TSKf10VaMbmkv5St0eYl14aaG89wW1k= X-Received: by 2002:a02:6c45:: with SMTP id w66-v6mr20205484jab.87.1536606522907; Mon, 10 Sep 2018 12:08:42 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 12:08:22 -0700 (PDT) In-Reply-To: References: <201809101757.w8AHvque079079@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Mon, 10 Sep 2018 15:08:22 -0400 X-Google-Sender-Auth: cLCXsrTf9wPa7kSKbRU6hK5YYSs Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: "Rodney W. Grimes" 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, 10 Sep 2018 19:08:44 -0000 On 10 September 2018 at 14:52, Ed Maste wrote: > > I brought this up on -arch in 2015... That said, the kgdb -n issue was brought up in the old thread and it seems I did forget about it. I don't think we should cater too much to the needs of the deprecated in-tree kgdb, but we should make sure that this works with kgdb from the port. There are now standardized ways to specify this information that we should migrate to, rather than the current approach. Note that here I'm really only interested in what we do for FreeBSD binary releases, and the path for kgdb -n etc. isn't really relevant in this case. Src tree defaults are in scope only because release settings and src tree defaults are coupled. From owner-freebsd-current@freebsd.org Mon Sep 10 19:55:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70A5E109A5C8 for ; Mon, 10 Sep 2018 19:55:39 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "mail.nomadlogic.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DDB3B725E6; Mon, 10 Sep 2018 19:55:38 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.203] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 1bdbca27 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 10 Sep 2018 12:48:57 -0700 (PDT) Subject: Re: testing early microcode loading To: Mark Johnston , freebsd-current@freebsd.org References: <20180910182655.GA2849@raichu> From: Pete Wright Message-ID: <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> Date: Mon, 10 Sep 2018 12:48:56 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180910182655.GA2849@raichu> 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: Mon, 10 Sep 2018 19:55:39 -0000 On 9/10/18 11:26 AM, Mark Johnston wrote: > Hi, > > Support for boot-time loading of Intel microcode updates has landed in > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. > I'd like to solicit some testing of the feature ahead of 12.0. > > The port has been modified to install /boot/firmware/intel-ucode.bin. > This file contains a copy of every Intel microcode update supplied by > the port. Per the pkg-message, one can enable early loading of this > file by specifying: > > cpu_microcode_load="YES" > cpu_microcode_name="/boot/firmware/intel-ucode.bin" > > in loader.conf. The update will be applied upon a subsequent reboot. > > Testing consists of enabling early loading and verifying that the CPUs > report an updated microcode version. If early loading fails, a message > is printed to the dmesg. If your system is capable of successful ACPI > suspend/resume, it is useful to also verify that the microcode remains > updated following a resume. > > To fetch the current microcode version, use sysutils/x86info: > > # kldload -n cpuctl && x86info -a | grep Micro > Microcode version: 0x0000000000000020 > > Compare with the version installed by the microcode_update rc script at > run-time: > > # service microcode_update onestart > Updating CPU Microcode... > Done. > # kldload -n cpuctl && x86info -a | grep Micro > Microcode version: 0x0000000000000020 > > If your testing indicates that the boot-time loading method doesn't > work, please include the dmesg in your reply. Thanks in advance. Hey there Mark, So I've just tested this on a kabylake system running a kernel/world from Sept 7th which I believe is recent enough. After updating /boot/loader.conf as per your email I am not sure if any microcode updates are being applied.  I'm not seeing any messages regarding firmware updates being applied in the dmesg buffer.  running x86info results in the following: $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro Microcode version: 0x000000000000008e this is after rebooting with the updated loader.conf as well as running the rc script by hand.  i didn't think to compare the output of x86info before running the rc script, i can do that later today. for reference here is my dmesg: https://gist.github.com/nomadlogic/bfc54315b97d374a7818d29bfc93223e Cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Sep 10 21:36:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF8EA109CDB1 for ; Mon, 10 Sep 2018 21:36:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D03B7727F; Mon, 10 Sep 2018 21:36:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 09F2C10B681; Mon, 10 Sep 2018 17:36:32 -0400 (EDT) Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: "Rodney W. Grimes" References: <201809101755.w8AHt0Yo079063@pdx.rh.CN85.dnsmgr.net> Cc: Ed Maste , FreeBSD Current From: John Baldwin Message-ID: <97710a3f-7b5c-af12-3e22-027904ef8b92@FreeBSD.org> Date: Mon, 10 Sep 2018 14:36:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <201809101755.w8AHt0Yo079063@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 10 Sep 2018 17:36:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 10 Sep 2018 21:36:35 -0000 On 9/10/18 10:55 AM, Rodney W. Grimes wrote: >> On 9/10/18 9:51 AM, Rodney W. Grimes wrote: >>>> The FreeBSD base system is a reproducible build[1] with a minor >>>> exception: the build metadata (timestamps, user, hostname, etc.) >>>> included in the kernel and loader. >>>> >>>> With the default, non-reproducible build the kernel ident looks like: >>>> >>>> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 >>>> user@hostname:/path/to/freebsd/src >>>> >>>> and the loader ident: >>>> >>>> FreeBSD/amd64 EFI loader, Revision 1.1 >>>> (Mon Jan 1 10:11:12 EDT 2018 user@hostname) >>>> >>>> With reproducible builds enabled the kernel ident looks like: >>>> >>>> FreeBSD 12.0-ALPHA5 r338195 >>>> >>>> and the loader ident: >>>> >>>> FreeBSD/amd64 EFI loader, Revision 1.1 >>>> >>>> I would like to enable the REPRODUCIBLE_BUILD knob by default for the >>>> 12.0 release, and propose we do this by adding a step to switch the >>>> default to the list of changes[2] that re@ commits to the branch as >>>> part of the release process. >>> >>> Why not just turn this on and leave it on? >> >> For kernels not built against a pristine tree the extra info is useful to >> have. For better or worse, kgdb also parses the path to try to find >> kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it >> won't be able to find the matching kernel using its current logic. > > So this means stable/12 users would have hassles getting kgdb to work? No, this means that if you turn this option on in HEAD and leave it always on (as I read your mail to say), then it would be a hassle for developers on head. On stable branches it would be nice to keep the info if people are building kernels that aren't stock kernels (meaning modified source trees). For release kernels, crashinfo should work fine though even with the extra information stripped. For release builds the information is not really useful, it's only ever useful if someone is building their own kernel for some reason (and even in some of those cases it isn't all that useful). -- John Baldwin                                                                              From owner-freebsd-current@freebsd.org Mon Sep 10 21:56: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 2AED7109D4B2 for ; Mon, 10 Sep 2018 21:56:41 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 C0E9B77CE0 for ; Mon, 10 Sep 2018 21:56:40 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 943025646F for ; Mon, 10 Sep 2018 16:56:39 -0500 (CDT) Subject: Re: Request for Review: Generate /etc/services from the IANA registry To: freebsd-current@freebsd.org References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> From: Eric van Gyzen Message-ID: <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> Date: Mon, 10 Sep 2018 16:56:38 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> 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, 10 Sep 2018 21:56:41 -0000 On 9/10/18 12:04 PM, Eric van Gyzen wrote: > Would anyone like to review this change to generate /etc/services from > the IANA registry? > >     https://reviews.freebsd.org/D17106 If that review made your browser unhappy, try this one instead: https://reviews.freebsd.org/D17115 Eric From owner-freebsd-current@freebsd.org Tue Sep 11 00:41:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5806D10A048C for ; Tue, 11 Sep 2018 00:41:22 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC06A7C4C0 for ; Tue, 11 Sep 2018 00:41:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x441.google.com with SMTP id j26-v6so11304060pfi.10 for ; Mon, 10 Sep 2018 17:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=0P8kChDrL2bcosXuU7taomEGNa74TioRELVVEfCB7w0=; b=hQ3bs6iY066JoN63x2I8m1FVKgMiUmp2ONLqJA7CcEQFLLBIGbe3UUrq4bd4E+a3we e+dVnP5q/RLTNezAmDRjgClcDDxlVlflt3p6OaViF0vRmY0t8GMSbJwQXZcrFpXlwqSF Z7huJOp0t4Ea7j8kmjmX10AiYM9nlWXETFoCsW6nOpBuJq7IZP3FGBg3n1fe+6Cd05zf VBAFznH1e/sUsrpa0+ObcfjAugQwhbQ+8l5lDxRBNNmgZUvu5OyURQyfNihiHdpmpA6K 3NEuLYldaO1PGlBsyMh1Gn3k2GGeXKtbqfGKQspThrMYLG4KLZo5/XT5mVme4RoKwwLE cJmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=0P8kChDrL2bcosXuU7taomEGNa74TioRELVVEfCB7w0=; b=mEyj7Sm2jnKirOZ7/sUmRVPrQ8PxnWk1d1PdQQnN2JyMg6OJAFrPspxVglxQw8ypdS Lp5v+SGyXwzmBvNp8uBbQcUud3jfwBD1PA0e6Q9cJlelhP0fvxci7vW/OeL0dC5q4uLL PU2a3udlYoAZmjDkahN9qMwmp2El5sWVuj+guO+8SO+DISMq27cHUqvDcTc0jHGDlEez Af9fHu0H1rwCxPVvZLCJJAC/u8WVfDVLs1CPf1K7YYspFITHDN9K02LQd/UBGd+UhFIx SGqK6/5qw1jfpX034LSX+UgYGajIb6mqmVE7a2MsZWmSBz5zYPepkLaoTElap9lNhe9Q Y4Bg== X-Gm-Message-State: APzg51Cdq+bs3HKrKF6aUsFRzFlRw419I9NuSgkx05jcqiq3IVp+TcvG ICzS4VLAcnDDbsVr5RQcxhMil7Xk X-Google-Smtp-Source: ANB0VdYrljU1GZ72GeHzDXLS7/Hky3u/cOakR38IS/IXGFTq2UbMmgLbw438Oifsra76Jxcj/xSXGg== X-Received: by 2002:a63:3cc:: with SMTP id 195-v6mr24700260pgd.229.1536626480677; Mon, 10 Sep 2018 17:41:20 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id q25-v6sm22900683pfh.113.2018.09.10.17.41.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 17:41:19 -0700 (PDT) Sender: Mark Johnston Date: Mon, 10 Sep 2018 20:41:17 -0400 From: Mark Johnston To: Pete Wright Cc: freebsd-current@freebsd.org Subject: Re: testing early microcode loading Message-ID: <20180911004117.GE2849@raichu> References: <20180910182655.GA2849@raichu> <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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, 11 Sep 2018 00:41:22 -0000 On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: > > > On 9/10/18 11:26 AM, Mark Johnston wrote: > > Hi, > > > > Support for boot-time loading of Intel microcode updates has landed in > > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. > > I'd like to solicit some testing of the feature ahead of 12.0. > > Hey there Mark, > So I've just tested this on a kabylake system running a kernel/world > from Sept 7th which I believe is recent enough. > > After updating /boot/loader.conf as per your email I am not sure if any > microcode updates are being applied.  I'm not seeing any messages > regarding firmware updates being applied in the dmesg buffer.  Right, we currently print something only if an update was configured but failed to apply. We should probably print something either way, perhaps only if the kernel is booted with -v. > running x86info results in the following: > > $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro > Microcode version: 0x000000000000008e > > this is after rebooting with the updated loader.conf as well as running > the rc script by hand.  i didn't think to compare the output of x86info > before running the rc script, i can do that later today. Thanks. If the boot-time update succeeded, the rc script should have been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages in /var/log/messages? That would indicate that the rc script applied an update, which would imply that the boot-time update failed somehow. > for reference here is my dmesg: > https://gist.github.com/nomadlogic/bfc54315b97d374a7818d29bfc93223e From owner-freebsd-current@freebsd.org Tue Sep 11 03:55: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 8011610A7BBC for ; Tue, 11 Sep 2018 03:55:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "mail.nomadlogic.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA0C8838AF; Tue, 11 Sep 2018 03:55:28 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from creek.local (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 1b51ea0a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 10 Sep 2018 20:55:26 -0700 (PDT) Subject: Re: testing early microcode loading To: Mark Johnston Cc: freebsd-current@freebsd.org References: <20180910182655.GA2849@raichu> <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> <20180911004117.GE2849@raichu> From: Pete Wright Message-ID: <6eee4e31-b6ff-bc32-5974-9bb261eb82df@nomadlogic.org> Date: Mon, 10 Sep 2018 20:55:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180911004117.GE2849@raichu> Content-Type: text/plain; charset=utf-8 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: Tue, 11 Sep 2018 03:55:29 -0000 On 9/10/18 5:41 PM, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >> >> On 9/10/18 11:26 AM, Mark Johnston wrote: >>> Hi, >>> >>> Support for boot-time loading of Intel microcode updates has landed in >>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>> I'd like to solicit some testing of the feature ahead of 12.0. >> Hey there Mark, >> So I've just tested this on a kabylake system running a kernel/world >> from Sept 7th which I believe is recent enough. >> >> After updating /boot/loader.conf as per your email I am not sure if any >> microcode updates are being applied.  I'm not seeing any messages >> regarding firmware updates being applied in the dmesg buffer.  > Right, we currently print something only if an update was configured > but failed to apply. We should probably print something either way, > perhaps only if the kernel is booted with -v. i could certainly as being helpful for debugging. >> running x86info results in the following: >> >> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >> Microcode version: 0x000000000000008e >> >> this is after rebooting with the updated loader.conf as well as running >> the rc script by hand.  i didn't think to compare the output of x86info >> before running the rc script, i can do that later today. > Thanks. If the boot-time update succeeded, the rc script should have > been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages > in /var/log/messages? That would indicate that the rc script applied an > update, which would imply that the boot-time update failed somehow. when i ran the rc script after boot i saw the CPU related messages in dmesg on the console (CPU count, type, features, etc).  i did not see anything in /var/log/messages of interest either.  i'll re-test tomorrow when i get back into the office and let you know if i see anything of interest.  my plan is to: - boot with the /boot/loader.conf additions for applying microcode and save the output from x86info - boot with loader.conf settings uncommented, view output of x86conf - then run rc script and get output of x86conf -pete -- Pete Wright pete@nomadlogic.org 310.309.9298 From owner-freebsd-current@freebsd.org Tue Sep 11 08:21: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 D54E61083ACB for ; Tue, 11 Sep 2018 08:21:07 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (net-2-44-121-52.cust.vodafonedsl.it [2.44.121.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mailserver.netfence.it", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 323A58B6ED; Tue, 11 Sep 2018 08:21:07 +0000 (UTC) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.15.2/8.15.2) with ESMTPSA id w8B8KuK1092248 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 11 Sep 2018 10:21:04 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu Subject: Re: testing early microcode loading To: markj@freebsd.org References: <20180910182655.GA2849@raichu> Cc: freebsd-current@freebsd.org From: Andrea Venturoli Message-ID: Date: Tue, 11 Sep 2018 10:20:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180910182655.GA2849@raichu> 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: Tue, 11 Sep 2018 08:21:08 -0000 On 9/10/18 8:26 PM, Mark Johnston wrote: > Hi, > > Support for boot-time loading of Intel microcode updates has landed in > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. Thanks for your work. Altough I cannot test it yet, I appreciate it. Just one question: what about AMD? Is support for this brand coming in the future? Is it impossible for some reason? bye & Thanks av. From owner-freebsd-current@freebsd.org Tue Sep 11 09:41:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4EBA108AAC5 for ; Tue, 11 Sep 2018 09:41:34 +0000 (UTC) (envelope-from zhongcy95@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43ACF8E649 for ; Tue, 11 Sep 2018 09:41:34 +0000 (UTC) (envelope-from zhongcy95@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id f4-v6so19897065uao.10 for ; Tue, 11 Sep 2018 02:41:34 -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=kgZPWZOCWFfRMZiPhNF8QxfrDPCQMO4OUlUjFfvHU7Y=; b=hA1dxAW4u7hg0Goreywqp3WSvFprQyTlR6iRD0pk5P5eHiWaU3/fbRncY7GaADsKaI aB4zXqFONuorP5gHArW5IBqhPyKHg2MoTPyAVJuIfYYipGylYBv2naqgfX6xz2rKpUoB 1WIXsthJI5MIX0Nj8Ur9GuL+IqLxAd9dolY1diHfxmYhGkP7STM+VzfOVPvCiEY3EUcW kKXifyMJJo7twg6beHpGSb/QORPNcWocjX4Zs21sPVjD5Hcf5v96hS5+AJFqqlHelmPd jOGIDztpy2TB5CwmDx9uXB/xwL+cTH6xC2AP0BzcHinyw1O5dKtBUVSdvlilwxgESd2h Ts+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kgZPWZOCWFfRMZiPhNF8QxfrDPCQMO4OUlUjFfvHU7Y=; b=VBmPHYvWx+D4/58JqtssHI+sETMAVbhk9i7VznDlzm/gx7/mWuRA4Zsl49EwNeOqEm O2NTxE5PtP26/w6DTHZXutg8f4ykgC/D2q0kLWbrTfQgc5lSyGTWG1jhCJCa1CdG9OY9 a4WQTXjXtiJGKM/7/wuDcDErZIwhMWJsOJEV9WXzNNq1csP9KFB0VUa3W6RJdMiBopZq WwgDlmHydJD8lTkcPnMk6b3dtxbwti4V/Z4Yy0Lz8+1dJ/zeRzIgKmY4ZxbqffJTLJDc n59udkZyasRJWGmOlGJz/Fgx1UgDC+GdLclXbY+XbKgaU0RCupnobdHUME2jxHuAYK71 i8bA== X-Gm-Message-State: APzg51DkLhlYccD+NgTM670+vOsgDdWq8BLDOBo73cCkyjWW1EzexUQj yN9Pc5zJBSm1ryQoxqcga5F2qlz4Sxo1rbVkEbMRPmoX X-Google-Smtp-Source: ANB0VdZIDxVjGLpTDE5zs2qS/FMqD4UL5rqgaI+kp07GG4w9s80MUX82v55ajRSf1kVsnBWNkJvvRr1ChzUmHa3xDrI= X-Received: by 2002:a67:2442:: with SMTP id k63-v6mr8534710vsk.67.1536658893334; Tue, 11 Sep 2018 02:41:33 -0700 (PDT) MIME-Version: 1.0 From: Chenyang Zhong Date: Tue, 11 Sep 2018 17:41:20 +0800 Message-ID: Subject: TCP RACK performance To: freebsd-current@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, 11 Sep 2018 09:41:35 -0000 Hi, I am really excited to see that @rrs from Netflix is adding TCP RACK and High Precision Timer System to the kernel, so I built a kernel (r338543) and ran some test. I used the following kernel config, as suggested in commit rS334804. makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS After booting the new kernel, I loaded the tcp_rack.ko, # kldload tcp_rack and checked the sysctl to make sure rack is there. # sysctl net.inet.tcp.functions_available net.inet.tcp.functions_available: Stack D Alias PCB count freebsd * freebsd 3 rack rack 0 I ran the first test with the default stack. I was running iperf3 over a wireless network where rtt was fluctuating but no packet loss. Here is a ping result summary. The average and stddev of rtt is relatively high. 39 packets transmitted, 39 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.920/40.206/124.094/39.093 ms Here is the iperf3 result of a 30-second benchmark. [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 328 MBytes 91.8 Mbits/sec 62 sender [ 5] 0.00-30.31 sec 328 MBytes 90.9 Mbits/sec receiver Then I switched to the new RACK stack. # sysctl net.inet.tcp.functions_default=rack net.inet.tcp.functions_default: freebsd -> rack There was a 10% - 15% performance loss after running the same iperf3 benchmark. Also, the number of retransmissions increased dramatically. [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 286 MBytes 79.9 Mbits/sec 271 sender [ 5] 0.00-30.30 sec 286 MBytes 79.0 Mbits/sec receiver I then ran iperf3 on a Linux machine with kernel 4.15, which uses RACK by default. I verified that through sysctl: # sysctl net.ipv4.tcp_recovery net.ipv4.tcp_recovery = 1 The iperf3 result showed the same speed with the default freebsd stack, and the number of retransmission matched the RACK stack on freebsd. [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 330 MBytes 92.3 Mbits/sec 270 sender [ 4] 0.00-30.00 sec 329 MBytes 92.1 Mbits/sec receiver I am not sure whether the performance issue is related to my configuration or to the new implementation of RACK on FreeBSD. I am glad to offer more information if anyone is interested. Thanks again for all the hard work. I cannot wait to see TCP BBR on FreeBSD. Best, Chenyang From owner-freebsd-current@freebsd.org Tue Sep 11 09:45:00 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 E32B0108AC32 for ; Tue, 11 Sep 2018 09:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 51E218E9DE for ; Tue, 11 Sep 2018 09:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EvKtiP8VM1n6JCZpfesxwzvsuB2cJf8zopR5p3XQ8ioj6CkJYnutdIZuY4BWhkM c0M.cmgwjHN5uWPxIT96pWwqnCUgg1Ygbm9iJphU7PfhCSqaWazJg_rRf7g2_js2VofOcPvQG1_c a20UgAHFSnasEBOOU.kEI34ViUpKXJ6PXChiz7TyGMpHE3vHu4uO0e4OlejOeYT8w0PF0b5SnSkf Qy8UKavTEQihIF1mMY1yl89df2F1Jzl.Ao5zWZd0uf8CDYEDP.yUibDNyZlhpKi3GcB8tGQYkvDY fgZ088iGDmhK1cH1_tTCAz_.KsbcTOzdnZnO1TTr5EMey7IJ0LSDqjuHq08X7T05QNEplAjAb96u pPg69uPFeS1T26sNiZSVqSZWHYIh2yrX5xuRezpktpOsvcOe62Ig.lGUuqlA5DkCnAGaQOt2pxrz NfDyLxAGg77.YjAqmoKrDWtxjNiUo7GEpnxg46BtN5ElvpIQSwH5hBlTHtmmAqIplD2GXmB2xMq0 M.nRHiZqf1hBwQ50Ch75o34sJbi97FcnnK48BYOoAV.VzAE.ONaRUbiEXOUvet2NRrbz7xubKZbB bF_j4u5r.HTSD2gi8uMArI_KGvXoT1WHL7PMxdf4P4161QMlAo.rlLEW4SF0tczKWAtL1n3m0MJo ONFJzpDe42HMl4vt6U9EhN41ULYX.GRQYiQd41UyEzpQW4NV93vo7l0_c2TktNlUGb96tjiP3tBD x.z52i94YHs.QMmfhhGrhVcsWOVFGeuiuG735OILacviOIus10exC.aaD3ikHN8I3F6m2W_o_Cxn UBjxCTkHvs8tyFj1UYdtgrWA1UfOArtD_ZXWeMcFD1QnZnRVPFYKmEUvCcUhF0PB_FFBF9anseqo a9xNNaHdRy.4A2eQOf9nInaL9w584dU0W5kkm9O8VyHjF9NgtlbmtSim72DCahvuh1eoK6nxhk.n edshj9k7dpZYOfRpTOesEqOCSXHRHZiN22BuhYUeZGbmF70vWs.S5FmdjZ6t0qP6shVuAEuiGtIc G6HScBV595A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 11 Sep 2018 09:44:53 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp419.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 32c42484b2aa6d29488d41a9bc0fb0e4; Tue, 11 Sep 2018 09:44:51 +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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-Id: Date: Tue, 11 Sep 2018 02:44:49 -0700 To: freebsd-arm , 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: Tue, 11 Sep 2018 09:45:00 -0000 [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] I got 14 failures. I've not enabled any configuration properties. I do not know if official devel/kyua tests are part of the head -> stable transition for any tier or not. I'm not claiming to know if anything here could be a significant issue. Someone may want to test an official aarch64 build rather than presume that my personal build is good enough. But I expect that its results should be strongly suggestive, even if an official tests uses a more normal-for-FreeBSD configuration of an aarch64 system. The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file system. This might let some things pass that otherwise would time out. =3D=3D=3D> Failed tests lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.107s] lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output for = more details [0.013s] lib/msun/trig_test:special -> failed: 8 checks failed; see output for = more details [0.013s] local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: Line = 420: atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) = not met [4.470s] local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see = the output of the test for details [0.151s] usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, = 14 failed Total time: 6688.125s I'll note that the console reported over 73720 messages like (with = figures where I've listed ????'s): md????.eli: Failed to authenticate ???? bytes of data at offset ????. There are also device created and destroyed/removed notices with related material. Overall there were over 84852 lines reported with "GEOM_ELI:" on the line. This did not prevent tests from passing. (The huge console output is unfortunate in my view: it makes finding interesting console messages a problem while watching messages go by.) I did get the console message block: kern.ipc.maxpipekva exceeded; see tuning(7) Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with non-tentative = address (epair2Freed UMA keg (rtentry) was not empty (18 = items). Lost 1 pages of memory. a) Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. But no failure reports seemed to be associated. Still, I wonder if the block of messages is significant. Some other console messages seen (extracted from various places): GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] Again no failure reports seemed to be associated. Some or all of the following may be normal/expected: Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: exited = on signal 3 (core dumped) Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited on = signal 6 (core dumped) Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: exited = on signal 6 (core dumped) Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited on = signal 6 Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited on = signal 11 (core dumped) Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited on = signal 11 (core dumped) Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited on = signal 3 Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited on = signal 3 Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited on = signal 6 Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited on = signal 5 (core dumped) Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: exited = on signal 11 (core dumped) I'm not sure that they all would be expected. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Sep 11 11:26:00 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 BD0F9108D934 for ; Tue, 11 Sep 2018 11:26:00 +0000 (UTC) (envelope-from ndowens@yahoo.com) Received: from sonic315-20.consmr.mail.ne1.yahoo.com (sonic315-20.consmr.mail.ne1.yahoo.com [66.163.190.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 5D72972B83 for ; Tue, 11 Sep 2018 11:26:00 +0000 (UTC) (envelope-from ndowens@yahoo.com) X-YMail-OSG: mFptL7oVM1kwYJPqKj5Bh7DZzjW_.9n9p7ECdO37Ukeafqx.dArMpQREG_.0xj. idjpZ6bWH_ORY.rSKw4tFlwlRGILsrwmkr3gkEHQU5jeLJhpMIDMyrNwAwaj_H2d8LsQQlHRfhNH k9jV5a3kUnQJvVdU0QOYJfmT8VQJDxNDBs_aUJci3T4LIPJsVEquPePWck7YWOd9UgAYSyMfGIVO vtPkOdGvcUYnOmIN6pB5gnk66sUMTHPuOrCZYLnESKqFnA1Z.s3jS07J8PPDI8Q980R0eU8SMdhC s6ThHuFaMkXN5yNlj5QcGcNER.XCtdFilO_oDqbWJTEWySRb3hhir6qzZrpUKkhpHuFOM9IZy06S CfShcxNFbWyIR9SwirgfUfD72Y6YM6vBrzTeQmahtAkIbVd.w.KoRm95fCP5Er9Bbv6TVtj9o595 lc9mt_phkaqqTIylBEwyRRML4tSlhIeolUfwilQfIDU4dY3BQcq5O90XTCFM9lCPyVL7X4M2GD4. TeYGnmWbWplFY.hB8Edhh43u9PnLy5U66MmsaqAyUNDWJd9YB_AiJN1qQwdarhZl2cmilCTG_6vL _26..u_IWWfwBia5uxI0q3tEQPlvr.FDMnBe0J8tSwG9dBroHB0PogPsxdI8cXEHi8I0VwSoUycb 9TgE8Vl6lmG0SLqUpqjd6wLrv7MVL0Hjodk8SILaEWjO71A29ItjvjNklhYT5bgwGrn6NYEhFbPr dPaBxHWM6xgjGOuZRapzYqgQgIGkkmUAKgmxm_ZzG_XmCZX6UkJbYs14xu5iaUBqdOix.kh8ONAx yBOi1NbGXqsmvB3V9HsceaMLIw1XwCsuUF4jdg5N_yY8_DZ04LPjqAPMXwSM159SHZWEvyNMdf.5 XZBLSzm71QGkf4ZFRxOoJBCYhSHdU55iivWp_sFjikCMCxYeYyikeq8w2O2gLvqnsOO_twofIrh0 kNLgCCSaEQu04xFgEH9MFvztI6SJDLb3PUcQTHKA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Tue, 11 Sep 2018 11:25:54 +0000 Date: Tue, 11 Sep 2018 11:25:48 +0000 (UTC) From: Nathan Owens To: FreeBSD Current , FreeBSD Ports Message-ID: <596850902.3408902.1536665148359@mail.yahoo.com> Subject: Poudriere MIME-Version: 1.0 References: <596850902.3408902.1536665148359.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12406 YahooMailIosMobile Raven/42997 CFNetwork/902.2 Darwin/17.7.0 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: Tue, 11 Sep 2018 11:26:01 -0000 Submitting this here as I believe this may be best place to ask the questio= n as I use poudriere to test ports before sending patches I am on 12 current. If I=E2=80=99m building a port that can use either py27= or py36 on an non x86based system the py27 works fine on all my jails. If = I test with py36 poudriere errors out saying a file touched my FS during bu= ild and it actually does install a file on my FS as I can delete the file i= t refers to and retry build and it will be there again. The FS violation ha= ppens on my mips/mips64/armv6/arm64/ poudriere jails with py36. To try some= thing I forced it to use py37 and it does the same.=C2=A0 I=E2=80=99ve created a new arch jail with new name and it happens on fresh = jail install as well. I=E2=80=99ve disabled ccache and that didn=E2=80=99t = fix the issue either=C2=A0 Sent from Yahoo Mail for iPhone From owner-freebsd-current@freebsd.org Tue Sep 11 12:22: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 43063108F86A for ; Tue, 11 Sep 2018 12:22:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 A0FDE74B42 for ; Tue, 11 Sep 2018 12:22:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-90-199.dz.commufa.jp [124.18.90.199]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w8BBZQTT018758 for ; Tue, 11 Sep 2018 20:35:26 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 11 Sep 2018 20:35:20 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL Message-Id: <20180911203520.3b927661a8488aec280b6e11@dec.sakura.ne.jp> In-Reply-To: References: Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 11 Sep 2018 12:22:13 -0000 I prefer releng, rather than stable, to make it default. Binary releases requiring reproducible builds are built from release and releng branches. On Mon, 10 Sep 2018 10:56:14 -0400 Ed Maste wrote: > The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. > > [1] https://reproducible-builds.org > [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html > _______________________________________________ > 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" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Tue Sep 11 13:20:46 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 E71F91090E5F for ; Tue, 11 Sep 2018 13:20:45 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5508B767DC for ; Tue, 11 Sep 2018 13:20:45 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id v77-v6so20292968lfa.6 for ; Tue, 11 Sep 2018 06:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bf6w+OjD6Qil7iFpCzjXbWwOjNDZWwc2ew9IkrqIXCc=; b=ENc33YOYM3MQu+6IdRXh4AEUR8OEcLKHXaimZCIyOlhotYEQ8ODLko2g2CGYhVkIu/ 77Veyva5R+On3fjD4cEN0aHnAE7vSqRsT8iFURQ6zFHxWr3JmgTipHGbyFxJIkPxO0Iv GLOaBzXOJt5JTS4yQIreMJ7aZrem0KriDXIe3+h9TRL6oG3BmG9UYnLWj7oYC9gjddSo GMuEfJGkCnly4hn0Msau/S3BvBHEa8WTT8uyaPfEmD6BHCP06LJh1ratZwo4/nfgYyo/ J7ujlIgPJtMW0Z5FuIBjM4RKSnK/tDlEsvzfRUcl/j8DgvQ2C6OpECLrV31+dDcyELxI KOpw== 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=bf6w+OjD6Qil7iFpCzjXbWwOjNDZWwc2ew9IkrqIXCc=; b=H7RTMQiB4QIol3ZxTxr4cbGCdhBWSGBCZb+clMKpxsmf7Utg+tDBt6kL4A5I93XtuJ 2N4PSgPrYed96rWaxCHpj484RagOYa8a07pEaxdQnxAKsRVwe82aaEiDhnXV1lsdegUv LqpzsWn/zrGyQ0vPI61h9ynG7E9Vl/02qMfSXJ1BRQAEapRECnyljVZc0lccz6YcsKGV s3kqIjt+vBn4nF/rzA+LL8neLrZ/blKCOz7waxNZeddxOPNHJm8kuHVrn0f7I5etUDUv ud3hZAuDxbGpVyFFtExkPZWsa0jeY3pjXbVo3LFAZKTmTOF5BvP/j4M/dolOgp5vCVQC 9NAQ== X-Gm-Message-State: APzg51Ap/Wr/Peq28MR5OQNZhG9EHhwxLZClkWPgv9swKV8yaMZpGknd XGJcDvKMKMv9NGmLg4+3QK6M3rKkKubvt7t9DsA= X-Google-Smtp-Source: ANB0VdYzZ/llgEMY28Fyi37zoPsDgQdpz/ChuyGe4ueEMyx6EhcOtzRPXfjTl106TdgNcHmuMSQx0yBgM6Vp/qifBac= X-Received: by 2002:a19:f83:: with SMTP id 3-v6mr15494243lfp.131.1536672043780; Tue, 11 Sep 2018 06:20:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andreas Nilsson Date: Tue, 11 Sep 2018 15:20:31 +0200 Message-ID: Subject: Re: make packages fails recent -current To: mikael.urankar@gmail.com Cc: Current FreeBSD 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: Tue, 11 Sep 2018 13:20:46 -0000 On Mon, Sep 10, 2018 at 5:55 PM Mika=C3=ABl Urankar wrote: > 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : > >> Hello, >> >> I have for about a week been trying to get new (base)packages built. mak= e >> buildworld/buildkernel works as expected, however make packages has been >> failing: >> >> =3D=3D=3D> Creating FreeBSD-runtime-12.0.s20180910124534 >> pkg: duplicate directory listing: /boot, ignoring >> pkg: duplicate directory listing: /etc, ignoring >> ... >> pkg: duplicate directory listing: /etc/syslog.d, ignoring >> pkg: duplicate directory listing: /root, ignoring >> pkg: duplicate directory listing: /root, ignoring >> pkg: duplicate directory listing: /root, ignoring >> pkg: Plist error, @config /root/.cshrc: not a regular file >> pkg: Plist error, @config /root/.profile: not a regular file >> pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring >> pkg: duplicate directory listing: /usr/lib, ignoring >> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring >> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring >> pkg: duplicate directory listing: /usr/lib32, ignoring >> ... >> >> Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode >> for >> building. I'm currently building from scratch just to rule out metamode. >> > > See > https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383= .html > Thanks, that would explain it. Although even after installing pkg-devel-1.10.99.8 it still fails. Guess I'll have to wait for it to trickle into the packages. Best regards Andreas From owner-freebsd-current@freebsd.org Tue Sep 11 14:18: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 4368F1092205 for ; Tue, 11 Sep 2018 14:18:35 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 B8DEB78409 for ; Tue, 11 Sep 2018 14:18:34 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id D03691604A; Tue, 11 Sep 2018 16:18:25 +0200 (CEST) Date: Tue, 11 Sep 2018 16:20:00 +0200 From: Steffen Nurpmeso To: Eric van Gyzen Cc: freebsd-current@freebsd.org Subject: Re: Request for Review: Generate /etc/services from the IANA registry Message-ID: <20180911142000.unrYV%steffen@sdaoden.eu> In-Reply-To: <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> Mail-Followup-To: Eric van Gyzen , freebsd-current@freebsd.org User-Agent: s-nail v14.9.11-45-g9c6690b7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 11 Sep 2018 14:18:35 -0000 Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net>: |On 9/10/18 12:04 PM, Eric van Gyzen wrote: |> Would anyone like to review this change to generate /etc/services from= =20 |> the IANA registry? |>=20 |> =C2=A0=C2=A0=C2=A0=C2=A0https://reviews.freebsd.org/D17106 | |If that review made your browser unhappy, try this one instead: Yes it did. | https://reviews.freebsd.org/D17115 I mean, i have nothing to do with FreeBSD except that i use it since 4.7 (though some yours only indirectly as Mac OS X), and i am in opposition to quite some directions taken, but who am i, that is ok, i have a very narrow use case. But this is one of the things i really do not understand, bringing XML and Python stuff needlessly into FreeBSD seems very odd. For example, ArchLinux and CRUX Linux use a simple portable awk script to generate services and protocols, and all you need to count the number of services is a normal Unix pipeline which strips comments and then calls wc -l. I'll paste the script below this. Thank you. And ciao already here #!/bin/sh - #@ Update protocols and services from IANA. #@ Taken from ArchLinux script written by Gaetan Bisson. Adjusted for CRUX. awk=3Dawk curl=3Dcurl url_pn=3Dhttps://www.iana.org/assignments/protocol-numbers/protocol-numbers= .xml url_snpn=3Dhttps://www.iana.org/assignments/service-names-port-numbers/\ service-names-port-numbers.xml datetime=3D`date +'%FT%T%z'` download() { echo 'Downloading protocols' ${curl} -o protocols.xml ${url_pn} [ ${?} -eq 0 ] || exit 20 echo 'Downloading services' ${curl} -o services.xml ${url_snpn} [ ${?} -eq 0 ] || exit 21 } process() { echo 'Processing protocols' ${awk} -F "[<>]" -v URL=3D"${url_pn}" -v DT=3D"${datetime}" ' BEGIN{ print "# /etc/protocols, created " DT print "# Source: " URL } / protocols.new [ ${?} -eq 0 ] || exit 30 echo 'Processing services' ${awk} -F "[<>]" -v URL=3D"${url_snpn}" -v DT=3D"${datetime}" ' BEGIN{ print "# /etc/services, created " DT print "# Source: " URL } / services.new [ ${?} -eq 0 ] || exit 31 } update() { mv protocols.new protocols [ ${?} -eq 0 ] || exit 40 mv services.new services [ ${?} -eq 0 ] || exit 41 rm -f protocols.xml services.xml } download process #update --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Tue Sep 11 14:24: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 D110110925AF for ; Tue, 11 Sep 2018 14:24:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FC7788D8 for ; Tue, 11 Sep 2018 14:24:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f54.google.com with SMTP id i7-v6so20501804lfh.5 for ; Tue, 11 Sep 2018 07:24:41 -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; bh=jKmlGFKzXPoc9qWV8l2FXJVa1UWImfBL7z9uPqkKS+g=; b=pnVITS49IdcOHZrQCDDoQnQr4CY0n1Vx9DJkPlVpaOApkmGh0kFvYN0gmjvUygvsLd QbS7QoaeuqbbhsvcdvcjG4iZIbmzYPZqC6LT9HviPkY7jDq0620p8kX7ZArdLgaMZeoi dKqm6XvToxPHgR3dbhUcUT3NJRgZIbRDcA/SzTY5V5aJLZtdYIAVy2g2nXSucMBrnTJu DYFDfLE+UPhcEkUmLX6bxugNoz4/9xMIHh8AA9PpWY6tL683tHrIUHTic/ypSquMrISX PI2/dswmNwOj9kgY+ZJh33o+7Qat3oScSJEA+WiUCH1Tbij6+5eROf29Bgyb/ONrTNMM h8yQ== X-Gm-Message-State: APzg51DWTD5VCPiOn+cuz+xB9Y3trkteH24Lgw5NwgK2Coic/2Ys1rlz Wi0Nw7NrWJdc/117tRT7xuBzjwLio72KwU9v5IA= X-Google-Smtp-Source: ANB0VdbLwEZs0/8YW08agUmHZTiNG0AGiL6N30pSYbURI2yf3PeJGIIghE748Y65mrlEe7dZCJ8SL7CWrxDjdiD4ZQM= X-Received: by 2002:a19:2841:: with SMTP id o62-v6mr14965158lfo.86.1536675879240; Tue, 11 Sep 2018 07:24:39 -0700 (PDT) MIME-Version: 1.0 References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> <20180911142000.unrYV%steffen@sdaoden.eu> In-Reply-To: <20180911142000.unrYV%steffen@sdaoden.eu> From: Alan Somers Date: Tue, 11 Sep 2018 08:24:25 -0600 Message-ID: Subject: Re: Request for Review: Generate /etc/services from the IANA registry To: Eric van Gyzen , FreeBSD CURRENT , steffen@sdaoden.eu 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: Tue, 11 Sep 2018 14:24:42 -0000 Don't worry Steffen. Python won't be a build requirement for FreeBSD even after Eric's patch. His Python script will only need to be run whenever IANA updates its database, and the results will be checked into source control. So for a normal user, there is no change to "make buildworld && make installworld". As for Python vs Awk, I too tried to do this with Awk. However, Awk can't easily handle things like IANA's representation of aliases, and it can't easily format the list in the same order as our current list. Python is truly a better choice. -Alan On Tue, Sep 11, 2018 at 8:19 AM Steffen Nurpmeso wrote: > Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net > >: > |On 9/10/18 12:04 PM, Eric van Gyzen wrote: > |> Would anyone like to review this change to generate /etc/services from > |> the IANA registry? > |> > |> https://reviews.freebsd.org/D17106 > | > |If that review made your browser unhappy, try this one instead: > > Yes it did. > > | https://reviews.freebsd.org/D17115 > > I mean, i have nothing to do with FreeBSD except that i use it > since 4.7 (though some yours only indirectly as Mac OS X), and > i am in opposition to quite some directions taken, but who am i, > that is ok, i have a very narrow use case. But this is one of the > things i really do not understand, bringing XML and Python stuff > needlessly into FreeBSD seems very odd. For example, ArchLinux > and CRUX Linux use a simple portable awk script to generate > services and protocols, and all you need to count the number of > services is a normal Unix pipeline which strips comments and then > calls wc -l. I'll paste the script below this. Thank you. > And ciao already here > > #!/bin/sh - > #@ Update protocols and services from IANA. > #@ Taken from ArchLinux script written by Gaetan Bisson. Adjusted for > CRUX. > > awk=awk > curl=curl > url_pn= > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml > url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\ > service-names-port-numbers.xml > > > datetime=`date +'%FT%T%z'` > > download() { > echo 'Downloading protocols' > ${curl} -o protocols.xml ${url_pn} > [ ${?} -eq 0 ] || exit 20 > echo 'Downloading services' > ${curl} -o services.xml ${url_snpn} > [ ${?} -eq 0 ] || exit 21 > } > > process() { > echo 'Processing protocols' > ${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" ' > BEGIN{ > print "# /etc/protocols, created " DT > print "# Source: " URL > } > / / / /<\/record/ && n && v != ""{ > printf "%-12s %3i %s\n", tolower(n), v, n > } > ' < protocols.xml > protocols.new > [ ${?} -eq 0 ] || exit 30 > > echo 'Processing services' > ${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" ' > BEGIN{ > print "# /etc/services, created " DT > print "# Source: " URL > } > / / / / /Unassigned/ || /Reserved/ || /historic/ {c = 1} > /<\/record/ && n && u && p && !c{ > printf "%-15s %5i/%s\n", n, u, p > } > ' < services.xml > services.new > [ ${?} -eq 0 ] || exit 31 > } > > update() { > mv protocols.new protocols > [ ${?} -eq 0 ] || exit 40 > mv services.new services > [ ${?} -eq 0 ] || exit 41 > rm -f protocols.xml services.xml > } > > download > process > #update > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > _______________________________________________ > 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 Tue Sep 11 14:28:18 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 824ED109270C; Tue, 11 Sep 2018 14:28:18 +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 3104E78EC7; Tue, 11 Sep 2018 14:28:18 +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 3ED9C2156E; Tue, 11 Sep 2018 10:28:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 11 Sep 2018 10:28:17 -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=toqoRAYFXHukRjNUoOYLoPiz3oW6yzGW1Yqn2998Y7A=; b=EgdkZvMg o+3hb34X+MDBZF4d6sG2MmOtMVRVlY3JgbfTiyOJYhG40aEcT5s2XxngmoLx9tCv DReXNW4du9SXYSeViPC9MFCvNH+pd34wpxJASaKwW+cf6GwBLSqy9DtJkhY4Xj6F V2G/7MfgTegDLQ5K0BTbbsKBLuPbt0SaN3vrvOUEj8NcXoFEMomNY7ucifa6evl8 KPSatHQOCA0FGYU0Q15YX/KXnPshSfHCe8I6VEDlqueVwS3Tct0ocHjDUd/y++qa wB5DF5KRQ8UdyFJ9aopTHBvaeXJuX3fgtOKa5hpWcEuK1OwT1/teFhdkgkqGIN7J KTeT6Us9xFRnVQ== 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=toqoRAYFXHukRjNUoOYLoPiz3oW6y zGW1Yqn2998Y7A=; b=ezj210YbvyDdfMHLxfssbXxHCFwvGW1rMgsBiUply32xd E9mA9QF+isLUNZDpm1BwJbh4xAC+QW/t8CHpeaOBMkOZ/bTijaIiSZe3wYzGA0D2 of4QYpzWZ6tXRJr4zQihEjXbBUfWmANgbsEACi1B/mLWMWs4JD9EvTuQRcsHAzuk IHRHE1cvUC9jR44JJ/0+Rl6RfXLXiuZFPoj+MjUSgnQVXvQjr8NTO0sfoUL+jPpj V41lYDXC+3nOIfQlsjUSbroCNQDpggQvPXaaDEn9yNJEvoGUJ6Js4lfU5pVbZMgp S1/TzjAJeBTWLwDQITLQnAe2UQRhEEi2oy3jht8HA== 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 97B73E463E; Tue, 11 Sep 2018 10:28:16 -0400 (EDT) To: FreeBSD Current Cc: freebsd-ports@freebsd.org From: tech-lists Subject: how to enforce one version of python Organization: none Message-ID: Date: Tue, 11 Sep 2018 15:28:15 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.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: Tue, 11 Sep 2018 14:28:18 -0000 Hi, There are a number of ports that seem to have their own preferential flavour of python, and some for example want to install python27 and python36 in the same place, and it's a pain when using portupgrade or similar tools. I have this in my /etc/make.conf: DEFAULT_VERSIONS+= python=2.7 Is this incorrect? I assume it must be, as for example devel/pylint (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1 thanks, -- J. From owner-freebsd-current@freebsd.org Tue Sep 11 14:51: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 D4256109328B; Tue, 11 Sep 2018 14:51:53 +0000 (UTC) (envelope-from bapt@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 8AD2279FD5; Tue, 11 Sep 2018 14:51:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 6D683B8A3; Tue, 11 Sep 2018 14:51:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 3AE589334C; Tue, 11 Sep 2018 16:51:52 +0200 (CEST) Date: Tue, 11 Sep 2018 16:51:52 +0200 From: Baptiste Daroussin To: tech-lists Cc: FreeBSD Current , freebsd-ports@freebsd.org Subject: Re: how to enforce one version of python Message-ID: <20180911145151.zgyeaiobnvkuo2rg@ivaldir.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45f625nenfj3ksxi" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 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, 11 Sep 2018 14:51:54 -0000 --45f625nenfj3ksxi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 03:28:15PM +0100, tech-lists wrote: > Hi, >=20 > There are a number of ports that seem to have their own preferential flav= our > of python, and some for example want to install python27 and python36 in = the > same place, and it's a pain when using portupgrade or similar tools. >=20 > I have this in my /etc/make.conf: >=20 > DEFAULT_VERSIONS+=3D python=3D2.7 >=20 > Is this incorrect? I assume it must be, as for example devel/pylint > (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1 >=20 That is because portupgrade is not flavor aware (or badly if it has been pa= tched to support flavors) Best regards, Bapt --45f625nenfj3ksxi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAluX1oUACgkQY4mL3PG3 PlpMHA//ZgBO5Ic5FdgWcuTwNn1Mo5FmhLeESPTFNXwmQw0ruFy2tg7KyWs3LIm0 3YD6+Mk5o1Sm38HnmNXuPe5RWdaikelpnusZ/CSurPrw6oBn1DHDLhJe5n2qojty 2EPvJOHGjeMPMlfTaf9TY9kgkTyW6YHyC5s3C+9dLUyQ6gcvV6428qgMfVwjVa3a FU4HbbcF3PMCqDBLF5g27tckF6i4oQCIs6pg4/G2m9MlC3dG0t0D7xh6BvvB2j6/ aDfXVE72d4kU5Mp5PUhGoF14U44rrpUhOEP5b0h+AFGuRxEGNnEeSho8sj6H7rID 14LLX0pVh6jxO/IHYDzwgcCIQ4k/nqXQ6gzjjKscvkyFFs9iOUpELxgP3gHz16wP hv0or4PsnUwFqznFnIwU1aUzPpaXU8ZGYJvNWJhRIlcSWW9l9KShURZBqKtimC/G eANooxaAGeP6vUARlmlwI/PPquwO2pvOtHR5O5v98NR7GsaImbV3FXsi5QgBdYOK 63MJOMa6Uo+NkUtLTHIw5Nx5ZzzA3O5SyApDttAWHh43qDhWHy4aeFawFtQuaFj9 nqtTSkCLDkbnNUjQpCmeqentENtnItB/yoH56XC79Hsas2yLmP7hgcjZdZ+e0+7G zCp7a7LdtZtU/4mQBk2fMg6/mbi5DL+gCsJgllE3VXHUIH7/bPY= =sala -----END PGP SIGNATURE----- --45f625nenfj3ksxi-- From owner-freebsd-current@freebsd.org Tue Sep 11 14:56: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 AA7961093640 for ; Tue, 11 Sep 2018 14:56:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2ADF47A317 for ; Tue, 11 Sep 2018 14:56:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x644.google.com with SMTP id ba4-v6so11451811plb.11 for ; Tue, 11 Sep 2018 07:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UF/jid3HGW222hoo/PCaNohaX5omwNRZT4GlMtt3uLs=; b=mSU9HRgIIQ7hM4a0zK5ePbI7Q6aZGMSbH6qaEaGPk/07IkeQGMS4jUluTKH49ooKjs wY3j0GxtoQ6ffK/R8mDYoJtniwA8CL1JrbqE2G0nLsSnTgoIiO/75EvgLjcBKhOycH5X z5FHKE2xQMoLtuR0rIaYG1UuKgZ9RSMzseBIeUjfgQN7+pRo8fV2A/20MuW3UW6JAh5C ZJd0PekQuz2W6PVJQ6RNthOUb9VbZLXHksHVbP5uqO0HmHNWgr7owFSTatZ/DkQpxR/9 Cm3Ya+cPcKrDvbDsn8P9Ge3/xsgJgE+/Birr6jsgJvfV4T2bwAwN8/ABwJq0KVy+Kop6 0ZFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=UF/jid3HGW222hoo/PCaNohaX5omwNRZT4GlMtt3uLs=; b=PyRXzDMzZdJ3lpFJEG/piEZWhr4MXT8BtogyPbg8b15WTeAGxLu6T1esgouH9jryvu /E1vHqPYiengYcDgVbAWjnM2LydpS+PoL/uuv9F9tZ413T5QmuOB+kQXA2TusYKEyKn/ 4e1VCOucQWgNvsI5KMBkowqa6X8etOBzb9FIpQ5wOz30+WZqTz+tVWtW7SnjhqCTgGez axV15bGwkuiPUMjvUClJVLYZnt0gu32iVH+kr1UrZvmMRkf8xyo6lwFu4BhMK+EOEL2d 0BZ7T1+cHFbzyrkxRSMTfsmjbloFcWm2dX5Z8Jd7PddvDYRgX2YycCB8OtW2kS7kWv9o ds6Q== X-Gm-Message-State: APzg51DUhwupcg1J+nctir6OcysLnrWEgmdsassEStxiejq9E806Ar4c wo3yhlK28Xnf5fHorY7dO0/cVT2K X-Google-Smtp-Source: ANB0VdY5coxxPY1GC5K3dksnAZlyFrnKvzJWWonL5QwcZvgcvMcr5iOcdfqMcFJgGRB7YEU/a4brqA== X-Received: by 2002:a17:902:704c:: with SMTP id h12-v6mr27502792plt.237.1536677808982; Tue, 11 Sep 2018 07:56:48 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id i7-v6sm21376659pgs.17.2018.09.11.07.56.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 07:56:48 -0700 (PDT) Sender: Mark Johnston Date: Tue, 11 Sep 2018 10:56:45 -0400 From: Mark Johnston To: Andrea Venturoli Cc: freebsd-current@freebsd.org Subject: Re: testing early microcode loading Message-ID: <20180911145645.GC92634@raichu> References: <20180910182655.GA2849@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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, 11 Sep 2018 14:56:50 -0000 On Tue, Sep 11, 2018 at 10:20:56AM +0200, Andrea Venturoli wrote: > On 9/10/18 8:26 PM, Mark Johnston wrote: > > Hi, > > > > Support for boot-time loading of Intel microcode updates has landed in > > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. > > Thanks for your work. > Altough I cannot test it yet, I appreciate it. > > Just one question: what about AMD? > Is support for this brand coming in the future? > Is it impossible for some reason? I do plan to work on it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231024 From owner-freebsd-current@freebsd.org Tue Sep 11 15:03: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 64D221093D11 for ; Tue, 11 Sep 2018 15:03:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 087F57AC95; Tue, 11 Sep 2018 15:03:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 1A2C61604A; Tue, 11 Sep 2018 17:03:22 +0200 (CEST) Date: Tue, 11 Sep 2018 17:04:56 +0200 From: Steffen Nurpmeso To: Alan Somers Cc: Eric van Gyzen , FreeBSD CURRENT Subject: Re: Request for Review: Generate /etc/services from the IANA registry Message-ID: <20180911150456.JQd44%steffen@sdaoden.eu> In-Reply-To: References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> <20180911142000.unrYV%steffen@sdaoden.eu> Mail-Followup-To: Alan Somers , Eric van Gyzen , FreeBSD CURRENT , Steffen Nurpmeso User-Agent: s-nail v14.9.11-45-g9c6690b7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 11 Sep 2018 15:03:23 -0000 Alan Somers wrote in : |Don't worry Steffen.=C2=A0 Python won't be a build requirement for FreeBS= D \ |even after Eric's patch.=C2=A0 His Python script will only need to be run= \ |whenever IANA=20 |updates its database, and the results will be checked into source contro\ |l.=C2=A0 So for a normal user, there is no change to "make buildworld && = make=20 |installworld". I cannot, unfortunately. I use binary updates and even preinstalled VM images (thanks for that, by the way). |As for Python vs Awk, I too tried to do this with Awk.=C2=A0 However, Awk= \ |can't easily handle things like IANA's representation of aliases, and \ |it can't=20 |easily format the list in the same order as our current list.=C2=A0 Pytho= n \ |is truly a better choice. I absolutely fail to see what you mean. The script (which is in actual use, mind you) generates the desired output except that comments get lost, but this could be added upon interest, of course. It (or a derivative) would have been a good candidate for /usr/share/misc/ in elder times i guess, too. |-Alan Ciao. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Tue Sep 11 15:10: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 7C09810940BA for ; Tue, 11 Sep 2018 15:10:17 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) (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 27D487B156; Tue, 11 Sep 2018 15:10:16 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 50F965646F; Tue, 11 Sep 2018 10:10:10 -0500 (CDT) Subject: Re: Request for Review: Generate /etc/services from the IANA registry To: Alan Somers , FreeBSD CURRENT , Steffen Nurpmeso References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> <20180911142000.unrYV%steffen@sdaoden.eu> <20180911150456.JQd44%steffen@sdaoden.eu> From: Eric van Gyzen Message-ID: Date: Tue, 11 Sep 2018 10:10:09 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180911150456.JQd44%steffen@sdaoden.eu> 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: Tue, 11 Sep 2018 15:10:17 -0000 On 9/11/18 10:04 AM, Steffen Nurpmeso wrote: > Alan Somers wrote in w@mail.gmail.com>: > |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \ > |even after Eric's patch.  His Python script will only need to be run \ > |whenever IANA > |updates its database, and the results will be checked into source contro\ > |l.  So for a normal user, there is no change to "make buildworld && make > |installworld". > > I cannot, unfortunately. I use binary updates and even > preinstalled VM images (thanks for that, by the way). So there will be no impact on you at all, except that /etc/services will have a lot more services. As Alan said, Python and XML will only be added to the developer workflow. > |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \ > |can't easily handle things like IANA's representation of aliases, and \ > |it can't > |easily format the list in the same order as our current list.  Python \ > |is truly a better choice. > > I absolutely fail to see what you mean. The script (which is in > actual use, mind you) generates the desired output except that > comments get lost, but this could be added upon interest, of > course. It (or a derivative) would have been a good candidate for > /usr/share/misc/ in elder times i guess, too. That awk script depends on the formatting of the XML file. It will break if the IANA decides to format it differently. Granted, this is unlikely, but it's possible. Also, that script would become much more complex if it supported local additions and overrides, which are unfortunately necessary in our case. Eric From owner-freebsd-current@freebsd.org Tue Sep 11 15:48: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 0908C1095021 for ; Tue, 11 Sep 2018 15:48:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (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 941E07C7F0 for ; Tue, 11 Sep 2018 15:48:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: x78ZPcIVM1mhH3zDsAQngublf5Wo.WDv1Y56rUWndAqS6C8XUZsHxteLTJMHfU2 LqkYWw8_VoQgxXk_6eNtH6I.3qTBG7MF2odXjAjbS3hTf8wKzd47J8W.89BmU6J3_N3_VlPyR5Lj w8FkZOsJZuYwhkqyWTDQSGX5LPuxban1kjlsQeYkz6_zcKn7Atw_uVcgmDohcVetOiVwYGvhBCEw fIgEegynPYYVOGuzN1rL6UCwVdpWrHsHQplogDxtry_i5BhmJYZd5pxp7d7La34pXAqPoNcmn_q4 HABVaEZPdyzd29xniXyetBXMJVnbb4IieYw5dTbb2LfWMLFDRUrgZm30WVEP9z9VVbIzeajVBPUa Sdv_.FfTAluH894X41ge7XUBEQmWdkbgkphdR4a.FAmrw3aLKOc4pdctcF6LoSaa6BGjxcV24YCI RYbwi6oz9oHZqElJ4ftorYXbv_5DDlFqwN571Gai8oDr7aQEl3ww.TWq2i04jdb2oaVOVLVR8P3d StzKD6eRJOvnsA1bmtzIlas86S7_LetUuCR8YYSi4XebeBjzJa6oVqJqNpwSr_55e0nfurI_tP8t Dlm4QvZSKCvBiIsTSV89meiJqmGzgpx.UdVIXWJiDeNq9Ccvy0Bujq.y23kopmfthRg6NQyIiOuu HKir7aLYUAJjXZMniY1.yxyuo2mF4QM.kpPgyDEkPn6Shgxak7HsqHnxQO0MyX3qspjeeh1keDE2 zzlrVJqNyy_GpyGYg4xdmrf09DPXyty7wKDuud44HQiTL7Tjzoy5GaNXcv25YHi9TrduEsf1y9La 0.aYzlIE6lG.5IvGuaTM52zWhmBaXjgA4Ykd9DN1hDJ2YcV.A9ivSksPLqVUuPcWtvisqSaEz0OV hhTyRtDcdqbRWjUYoykVFkIuOrvJwgi5AydOyWSbtKNDKuXOsIY0KTq_2Vh20RNONWfM7zUM3UGQ M6LLCFKs6lB8JhOQ_7x44AuXbF.FXmIwWNsAOuX4.nUzOyHiRrT65MWxI1pEiuHPvrKE4HwNjw_w F_s7AW_U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 11 Sep 2018 15:48:07 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp401.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 451ae66fd0229211cc86b1d6ad14bc7f; Tue, 11 Sep 2018 15:48:05 +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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Date: Tue, 11 Sep 2018 08:48:03 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: 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, 11 Sep 2018 15:48:15 -0000 [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. lib/libc/string/memcmp_test:diff is one of them.] On 2018-Sep-11, at 2:44 AM, Mark Millard wrote: > [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] >=20 > I got 14 failures. I've not enabled any configuration properties. >=20 > I do not know if official devel/kyua tests are part of the head -> > stable transition for any tier or not. I'm not claiming to know if > anything here could be a significant issue. >=20 > Someone may want to test an official aarch64 build rather than presume > that my personal build is good enough. But I expect that its results > should be strongly suggestive, even if an official tests uses a more > normal-for-FreeBSD configuration of an aarch64 system. >=20 > The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal > configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file > system. This might let some things pass that otherwise would time out. >=20 >=20 > =3D=3D=3D> Failed tests > lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] > lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.107s] > lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] > lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] > lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output = for more details [0.013s] > lib/msun/trig_test:special -> failed: 8 checks failed; see output = for more details [0.013s] > local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] > local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: Line = 420: atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) = not met [4.470s] > local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] > local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] > local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] > sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] > usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see = the output of the test for details [0.151s] > usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] > =3D=3D=3D> Summary > Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db > Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, = 14 failed > Total time: 6688.125s >=20 >=20 >=20 >=20 > I'll note that the console reported over 73720 messages like (with = figures > where I've listed ????'s): >=20 > md????.eli: Failed to authenticate ???? bytes of data at offset ????. >=20 > There are also device created and destroyed/removed notices with = related > material. Overall there were over 84852 lines reported with = "GEOM_ELI:" > on the line. >=20 > This did not prevent tests from passing. >=20 > (The huge console output is unfortunate in my view: it makes finding > interesting console messages a problem while watching messages > go by.) >=20 >=20 >=20 > I did get the console message block: >=20 > kern.ipc.maxpipekva exceeded; see tuning(7) > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with = non-tentative address (epair2Freed UMA keg (rtentry) was not = empty (18 items). Lost 1 pages of memory. > a) > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >=20 > But no failure reports seemed to be associated. >=20 > Still, I wonder if the block of messages is significant. >=20 >=20 > Some other console messages seen (extracted from various places): >=20 > GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] > GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] > GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] > GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). > GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). > GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] > GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] > GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] >=20 > Again no failure reports seemed to be associated. >=20 >=20 > Some or all of the following may be normal/expected: >=20 > Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: exited = on signal 3 (core dumped) > Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited = on signal 6 (core dumped) > Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: = exited on signal 6 (core dumped) > Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited = on signal 6 > Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited = on signal 11 (core dumped) > Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited on = signal 11 (core dumped) > Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited on = signal 3 > Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited on = signal 3 > Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated > Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited = on signal 6 > Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited = on signal 6 > Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited on = signal 6 > Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited = on signal 5 (core dumped) > Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: exited = on signal 11 (core dumped) >=20 > I'm not sure that they all would be expected. =3D=3D=3D> Broken tests lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case = received signal 6 (core dumped) [3.962s] lib/libregex/exhaust_test:regcomp_too_big -> broken: Premature exit; = test case received signal 11 (core dumped) [8.997s] lib/msun/exponential_test:main -> broken: Received signal 6 [3.893s] lib/msun/fenv_test:main -> broken: Received signal 6 [4.326s] lib/msun/fma_test:main -> broken: Received signal 6 [4.315s] lib/msun/invtrig_test:main -> broken: Received signal 6 [4.345s] lib/msun/logarithm_test:main -> broken: Received signal 6 [3.921s] lib/msun/lrint_test:main -> broken: Received signal 6 [4.416s] lib/msun/nearbyint_test:main -> broken: Received signal 6 [4.389s] lib/msun/next_test:main -> broken: Received signal 6 [4.401s] lib/msun/rem_test:main -> broken: Received signal 6 [4.385s] sbin/growfs/legacy_test:main -> broken: TAP test program yielded = invalid data: Load of '/tmp/kyua.5BsFl9/3782/stdout.txt' failed: = Reported plan differs from actual executed tests [0.476s] sys/cddl/zfs/ ones ignored here: no zfs context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Sep 11 17:21: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 833451097755 for ; Tue, 11 Sep 2018 17:21:41 +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 278D4807A3 for ; Tue, 11 Sep 2018 17:21:41 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id DDC751097741; Tue, 11 Sep 2018 17:21: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 CC8B1109773F for ; Tue, 11 Sep 2018 17:21:40 +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 6FF188079C for ; Tue, 11 Sep 2018 17:21:40 +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 1fzmM0-0003T0-5c for current@freebsd.org; Tue, 11 Sep 2018 19:21:32 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1fzmM0-0004sP-3g for current@freebsd.org; Tue, 11 Sep 2018 19:21:32 +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 ; Tue, 11 Sep 2018 17:21:31 GMT From: "Jeffrey Bouquet" To: "current" Subject: Upcoming release of V 12 Date: Tue, 11 Sep 2018 10:21:31 -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: Tue, 11 Sep 2018 17:21:41 -0000 I'm running v12 as HEAD [ 12.0-CURRENT] And am at a loss as to how to change it to 12.0-STABLE vs one day running a non-rebuilt 13.0-CURRENT=20=20 Without risking a scenario such as: svn up 12.0, fail for some reason to be able to build the GPU driver, so= I should have stuck with svn up 13.0 ???=20 As I've no second machine setup as backup. due to moving issues.=20 =20 Background At present I've various OSVERSION and UNAME_ENV set in make.conf to work around some type of kernel mismatch issue which prevents otherwise many ports building. However it is working seamlessly and I wish it to continue to do so after the day CURRENT changes from 12 to 13...=20 The system was crafted from a thumbdrive ISO so still has=20 /mnt/usr/freebsd-dist/base.txz ...=20 Otherwise it is all good.=20= From owner-freebsd-current@freebsd.org Tue Sep 11 19:35:56 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 BF2D5109B078 for ; Tue, 11 Sep 2018 19:35:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55C6586BCD for ; Tue, 11 Sep 2018 19:35:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id q5-v6so4567596iop.3 for ; Tue, 11 Sep 2018 12:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ll4qmPW5DoRWT1koiLZOgZL0e/UBFSZiBHlrTdmrTt4=; b=ThgYC6TqSwY9tPqvpjsTQ8AA1k21DZunUZNAn1aBqhDm1G3V6vSeYw/utZE/3pywnT owEfHt5yiXHIvSBEvInjDcsrLfuHfWfbwWyUFZNDKhO1LXq/DFpBoSS/yUiiQDxBF3UK iNn7rX2qGGL7TVmOhAOP3P+GHpq8JHNWN2TiAxsJRkZFrQCfPrv9x9sBH0C9dQix2qVw 3m+av20taLoVT/0+3kyzHFu6PxXMZT9kwxsD39HQ5hjWD/DWlXjeMUfiMxb0ux32LuGb xRZX9D9+Bj87CkpQ+iBnasYdZgtpT6xU3pQei+nsYD+yQzP0rqjUm5zLWJiyNqvRkuae bbLA== 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=Ll4qmPW5DoRWT1koiLZOgZL0e/UBFSZiBHlrTdmrTt4=; b=muk7rAP+yen5D83JlLAAhfXCvIXqc2eptYCjW3ek1HkxtBnL4ou4l02j772y7ir7cJ roMVyQrfW2Daurj9jPR5TGwiZnApG/8zLvoQc1lel6pOKlS8gjHS42JWd0ejbF6PAMbm e79HCZESgkT0nahIBJuhTcj/CAedfkJa0585B6aRnqGbkqGPYBFgUWEGLhYXJXsZ5Zo9 s8sBCREIjiUcDNr/vON47p9qqYVC9mObsfePGnX5HqwD/TzKO59u3DaMtdeCJJKsZKZD 5hGZHYMDP8mqMQ5QOnRp9LwBrC24TNOIxWLu7fJGDSOiDgPY/3LlbaPdaThZcGdSeBqN mGpw== X-Gm-Message-State: APzg51A0PWOYqWabtLUCMI+RLaVSQwANGlVPuXUF/OfLujCW8OERDk5c bqDzl4JmmiySoi5SSwdRR0B8sHqWlis6gjh6vHn6SA== X-Google-Smtp-Source: ANB0VdZDo3H+sVQ4WKMgdPuRN3aAfahINdjUD3pW718878UnQSM48EwiiUNSgz9zeRb38JU+QdfF8hsqpX6FytSoyI0= X-Received: by 2002:a6b:e716:: with SMTP id b22-v6mr23551814ioh.239.1536694555532; Tue, 11 Sep 2018 12:35:55 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 12:35:34 -0700 (PDT) In-Reply-To: <20180911203520.3b927661a8488aec280b6e11@dec.sakura.ne.jp> References: <20180911203520.3b927661a8488aec280b6e11@dec.sakura.ne.jp> From: Ed Maste Date: Tue, 11 Sep 2018 15:35:34 -0400 X-Google-Sender-Auth: z8QlA0MrBd_56R84Gbnh6ijjM6c Message-ID: Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL To: junchoon@dec.sakura.ne.jp 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: Tue, 11 Sep 2018 19:35:56 -0000 On 11 September 2018 at 07:35, Tomoaki AOKI wrote: > I prefer releng, rather than stable, to make it default. > Binary releases requiring reproducible builds are built from > release and releng branches. This might be the reasonable long-term strategy, but we don't yet have experience running through the release process with it enabled. I would like to enable it by default on the branch, at least initially, to avoid discovering issues only immediately prior to the release. From owner-freebsd-current@freebsd.org Tue Sep 11 19:58: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 55616109B8A3 for ; Tue, 11 Sep 2018 19:58:12 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.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 DF6C487680 for ; Tue, 11 Sep 2018 19:58:11 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id A3A4E109B8A2; Tue, 11 Sep 2018 19:58:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 819C1109B8A1 for ; Tue, 11 Sep 2018 19:58:11 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 311B78767F for ; Tue, 11 Sep 2018 19:58:10 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id w8BJw2jJ077640 for ; Tue, 11 Sep 2018 15:58:02 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id w8BJw2Ja077639 for current@freebsd.org; Tue, 11 Sep 2018 15:58:02 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 11 Sep 2018 15:58:02 -0400 From: "Michael W. Lucas" To: current@freebsd.org Subject: jail exec.clean busted in 12? Message-ID: <20180911195802.GA77575@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Tue, 11 Sep 2018 15:58:03 -0400 (EDT) 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, 11 Sep 2018 19:58:12 -0000 Hi, storm~;uname -a FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep 6 12:29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 It appears that exec.clean is busted. Here's my jail.conf: --- $j="/jail"; path="$j/$name"; host.hostname="$name.mwl.io"; mount.devfs; exec.clean=0; exec.start="sh /etc/rc"; exec.stop="sh /etc/rc.shutdown"; loghost { ip4.addr="203.0.113.231"; allow.raw_sockets=1; jid=99; } logdb { host.hostname="logdb.mwl.io"; ip4.addr="203.0.113.232"; } --- exec.clean is not explicitly defined on the command line, but it's the default, so it maybe shouldn't be? storm~;jls -n devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable jid=8 linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=6 host.domainname="" host.hostid=0 host.hostname=logdb.mwl.io host.hostuuid=00000000-0000-0000-0000-000000000000 ip4.addr=203.0.113.232 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 linux.oss_version=198144 devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=7 host.domainname="" host.hostid=0 host.hostname=loghost.mwl.io host.hostuuid=00000000-0000-0000-0000-000000000000 ip4.addr=203.0.113.231 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 linux.oss_version=198144 Anyway, I found this by: # jexec loghost env HOME=/home/mwlucas PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin TERM=xterm LC_COLLATE=C LANG=en_US.UTF-8 SSH_CLIENT=203.0.113.70 59076 22 SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22 SSH_TTY=/dev/pts/2 SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492 LC_CTYPE=en_US.ISO-8859-1 MAIL=/var/mail/root ... I'm highly confident my SSH environment shouldn't be in the jail. Yes, it goes away if I add -l, but my (admittedly sketchy) reading of the jexec source says that jexec handles stripping the environment before running the command. Even if I start it the hard way (from a discussion at https://github.com/iocage/iocage/issues/610) storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 persist storm~;jls JID IP Address Hostname Path 9 loghost /jail/loghost storm~;jexec 9 env | grep -i ssh SSH_CLIENT=203.0.113.70 59076 22 SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22 SSH_TTY=/dev/pts/2 SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492 storm~; Any ideas? Thanks, ==ml -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc... From owner-freebsd-current@freebsd.org Tue Sep 11 21:14: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 41D04109DFFB for ; Tue, 11 Sep 2018 21:14:28 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "mail.nomadlogic.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F7D38B229; Tue, 11 Sep 2018 21:14:27 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from creek.local (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id d50a3bdc TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Tue, 11 Sep 2018 14:14:20 -0700 (PDT) Subject: Re: testing early microcode loading From: Pete Wright To: Mark Johnston Cc: freebsd-current@freebsd.org References: <20180910182655.GA2849@raichu> <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> <20180911004117.GE2849@raichu> <6eee4e31-b6ff-bc32-5974-9bb261eb82df@nomadlogic.org> Message-ID: Date: Tue, 11 Sep 2018 14:14:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <6eee4e31-b6ff-bc32-5974-9bb261eb82df@nomadlogic.org> Content-Type: text/plain; charset=utf-8 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: Tue, 11 Sep 2018 21:14:28 -0000 On 9/10/18 8:55 PM, Pete Wright wrote: > On 9/10/18 5:41 PM, Mark Johnston wrote: >> On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >>> On 9/10/18 11:26 AM, Mark Johnston wrote: >>>> Hi, >>>> >>>> Support for boot-time loading of Intel microcode updates has landed in >>>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>>> I'd like to solicit some testing of the feature ahead of 12.0. >>> Hey there Mark, >>> So I've just tested this on a kabylake system running a kernel/world >>> from Sept 7th which I believe is recent enough. >>> >>> After updating /boot/loader.conf as per your email I am not sure if any >>> microcode updates are being applied.  I'm not seeing any messages >>> regarding firmware updates being applied in the dmesg buffer.  >> Right, we currently print something only if an update was configured >> but failed to apply. We should probably print something either way, >> perhaps only if the kernel is booted with -v. > i could certainly as being helpful for debugging. >>> running x86info results in the following: >>> >>> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >>> Microcode version: 0x000000000000008e >>> >>> this is after rebooting with the updated loader.conf as well as running >>> the rc script by hand.  i didn't think to compare the output of x86info >>> before running the rc script, i can do that later today. >> Thanks. If the boot-time update succeeded, the rc script should have >> been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages >> in /var/log/messages? That would indicate that the rc script applied an >> update, which would imply that the boot-time update failed somehow. > > when i ran the rc script after boot i saw the CPU related messages in > dmesg on the console (CPU count, type, features, etc).  i did not see > anything in /var/log/messages of interest either.  i'll re-test tomorrow > when i get back into the office and let you know if i see anything of > interest.  my plan is to: ok had time to test during lunch: > - boot with the /boot/loader.conf additions for applying microcode and > save the output from x86info Microcode version: 0x0..48 > > - boot with loader.conf settings uncommented, view output of x86conf Microcode version: 0x0...8e > - then run rc script and get output of x86conf Microcode version: 0x0..8e great, so it looks like this is working on my kabylake workstation.  the only time i see a log entry is when i update the microcode via rc, i do not see anything when its updated via loader.conf. cheers, -pete -- Pete Wright pete@nomadlogic.org 310.309.9298 From owner-freebsd-current@freebsd.org Tue Sep 11 21:13:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31AF1109DF62 for ; Tue, 11 Sep 2018 21:13:40 +0000 (UTC) (envelope-from davewrobison@gmail.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AEDF8B0AD for ; Tue, 11 Sep 2018 21:13:39 +0000 (UTC) (envelope-from davewrobison@gmail.com) Received: by mail-pl1-x634.google.com with SMTP id u11-v6so11905751plq.5 for ; Tue, 11 Sep 2018 14:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=GMYk7PyWnD8bNU6mz3byn6S8mi2MaGvp/62XE2hFqGs=; b=NPzth+odu78qzTlhU11Ae8tPRk99LWbiTufJYDuXRR58WEOJ2F64VlvkKF1GLWr2AE NLxfqbo2M//kANjO54qmg7RpHybx9En+dtTICJRCSjWZwhpNmzZe04xcrfuz44Z/Zg1Y uMRB9n8xz2f6dbnGlDVoMmZPrAZ0rSSC1L8AtSaaAYbTE0EhV7eE8z8p+M5a3N8d1arc LlmpGAnQCndj1W0buztJ5MQIbjnaZT+1Pa/0SoU0eZZ1NvV6FKb1iQqfiSN+hTcQRO2e s6puVl9bEyjZzV19hIlgMWJ9xyIRizl8JkvL23NHBRNhYfINv1RlYVTXx3Z6K4pwMjDz Le5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=GMYk7PyWnD8bNU6mz3byn6S8mi2MaGvp/62XE2hFqGs=; b=jbCAwTpPmh09PGoN/Wi2Sq8LFFAgXrS9mO+q0apDJ6l7rrlrHPAbNRZJfky08uqced lJovbdZzDdZiLd+ecLLeeQjyj7ic7qEHc7+6b7bP/ZowZRy2FzDpiwhvwp8Zuuy8lbcq 0Nnzfl+GYs02UD4QC0wEn/TlS47VT5aE1DyKbYcdqbww7/Mafmx+7bt4clX0CMRR/x/Y YSEmXMFFS2Uh/fQyvcSj7kSXerCSEtAJiGXtFWOORBBLEf3ieU1tBTNapKsnUkjfNbpy BraFnO/ANy5XOfTTNodH1QPPvOBJ4t2cTfN1GYRea9/vfYFFg8w129wrYD0xWA5+yLbD qGGg== X-Gm-Message-State: APzg51A0SN1sb8bUJbmnshrTvGeRoCuUk8QnBN4wwL2AcBFiI2KcVE1W xKze+5d81v6mxCWpUgayD0HSgwUU X-Google-Smtp-Source: ANB0VdbDUzfgMbzbZA5gF+0SLi2LjPMOWy53Euqlj24eVVT8hgnVm93AoAqOJjy1LV8hM+spaB6mxg== X-Received: by 2002:a17:902:7246:: with SMTP id c6-v6mr29332007pll.28.1536700418560; Tue, 11 Sep 2018 14:13:38 -0700 (PDT) Received: from ?IPv6:2600:380:475c:f40d:ddbd:9b16:a47f:de33? ([2600:380:475c:f40d:ddbd:9b16:a47f:de33]) by smtp.gmail.com with ESMTPSA id l79-v6sm36099313pfi.172.2018.09.11.14.13.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 14:13:37 -0700 (PDT) From: Dave Robison Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 11 Sep 2018 14:13:36 -0700 Subject: Routine Panic on HP Proliant G10 Message-Id: <0BFC62B6-FA94-4FA9-9AC9-3200DB7007BF@gmail.com> Cc: cayford.burrell@fisglobal.com, hiro.matsunami@necam.com, rainier@ultra-secure.de To: freebsd-current@freebsd.org X-Mailer: iPhone Mail (15G77) X-Mailman-Approved-At: Tue, 11 Sep 2018 21:20:13 +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: Tue, 11 Sep 2018 21:13:40 -0000 Hiya, I'm currently evaluating two classes of server which we source through NEC. H= owever, the motherboards for these machines are HP. I can routinely panic bo= th of these machines using 12.0-A4, as well as 11.1-R with a shoehorned in S= ES/SMARTPQI driver, and 11.2-R with its native SES/SMARTPQI driver. NEC seem= s to think this is a ZFS issue and they may be correct. If so I suspect ARC,= though as I explain further down, I haven't had a problem on other hardware= .=20 I've managed to get a core dump on 11.1 and 11.2, but on 12.0 when the panic= occurs, I can backtrace and force a panic and the system claims it is writi= ng out a core dump, but on reboot there is no core dump. Machine A: HP ProLiant DL360 Gen 10 with a Xeon Bronze 3106 and 16 gigs RAM a= nd three hard drives. Machine B: HP Proliant DL380 Gen 10 with a Xeon Silver 4114 and 32 gigs RAM a= nd five hard drives. I install 12.0-A4 using ZFS on root. I install with 8 gigs of swap but other= wise it's a standard FreeBSD install. I can panic these machines rather easi= ly in 10-15 minutes by firing up 6 instances of bonnie++ and a few memtester= s, three using 2g and three using 4g. I've done this on the 11.x installs wi= thout memtester and gotten panics within 10-15 minutes. Those gave me core d= umps, but the panic error is different than with 12.0-A4. I have run some te= sts using UFS2 and did not manage to force a panic. At first I thought the problem was the HPE RAID card which uses the SES driv= er, so I put in a recent LSI MegaRAID card using the MRSAS driver, and can p= anic that as well. I've managed to panic Machine B while it was using either= RAID card to create two mirrors and one hot spare, and I've managed to pani= c it when letting the RAID cards pass through the hard drives so I could cre= ate a raidz of 4 drives and one hot spare. I know many people immediately th= ink "Don't use a RAID card with ZFS!" but I've done this for years without a= problem using the LSI MegaRAID in a variety of configurations. It really seems to me that when ARC starts to ramp up and hits a lot of memo= ry contention, a panic occurs. However, I've been running the same test on a= previous generation NEC server with an LSI MegaRAID using the MRSAS driver u= nder 11.2-R and it has been running like clockwork for 11 days. We use this i= teration of server extensively. If this were a problem with ARC, I assume (p= erhaps presumptuously) that I would see the same problems. I also have serve= rs running 11.2-R with ZFS and rather large and very heavily used JBOD array= s and have never had an issue. The HPE RAID card info, from pciconf -lv: smartpqi0@pci0:92:0:0: class=3D0x010700 card=3D0x0654103c chip=3D0x028f9005= rev=3D0x01 hdr=3D0x00 vendor =3D 'Adaptec' device =3D 'Smart Storage PQI 12G SAS/PCIe 3' class =3D mass storage subclass =3D SAS And from dmesg: root@hvm2d:~ # dmesg | grep smartpq smartpqi0: port 0x8000-0x80ff mem 0xe6c00000-0xe6c07fff a= t device 0.0 on pci9 smartpqi0: using MSI-X interrupts (40 vectors) da0 at smartpqi0 bus 0 scbus0 target 0 lun 0 da1 at smartpqi0 bus 0 scbus0 target 1 lun 0 ses0 at smartpqi0 bus 0 scbus0 target 69 lun 0 pass3 at smartpqi0 bus 0 scbus0 target 1088 lun 0 smartpqi0: port 0x8000-0x80ff mem 0xe6c00000-0xe6c07fff a= t device 0.0 on pci9 smartpqi0: using MSI-X interrupts (40 vectors) da0 at smartpqi0 bus 0 scbus0 target 0 lun 0 da1 at smartpqi0 bus 0 scbus0 target 1 lun 0 ses0 at smartpqi0 bus 0 scbus0 target 69 lun 0 pass3 at smartpqi0 bus 0 scbus0 target 1088 lun 0 However, since I can panic these with either RAID card, I don't suspect the H= PE RAID card as the culprit. Here is an image with the scant bt info I got from the last panic: https://ibb.co/dzFOn9 This thread from Saturday on -stable sounded all too familiar: https://lists.freebsd.org/pipermail/freebsd-stable/2018-September/089623.htm= l I'm at a loss so I have gathered as much info as I can to predict questions a= nd requests for more info. Hoping someone can point me in the right directio= n for further troubleshooting or at least isolation of the problem to a spec= ific area. Thanks for your time, Dave From owner-freebsd-current@freebsd.org Tue Sep 11 22:57:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5B05109FAFB for ; Tue, 11 Sep 2018 22:57:02 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.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 6C2918DF07 for ; Tue, 11 Sep 2018 22:57:02 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2D9CA109FAFA; Tue, 11 Sep 2018 22:57:02 +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 0B8A1109FAF9 for ; Tue, 11 Sep 2018 22:57:02 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84B5F8DF06 for ; Tue, 11 Sep 2018 22:57:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x52a.google.com with SMTP id f4-v6so259367edq.3 for ; Tue, 11 Sep 2018 15:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/vs4ubuUVZjXz+URCJCqE508HvWQhC/8BDTsggqec/c=; b=hqbvzQQwbEYs4tVzAXXjfw0VZJPi9oQfxHPJwaeF/LhoTpGoFW0rRevz9g2MnpPX13 9IrPKPppM2+8MaRR53FfGI5NsmJcBSDtitxsbDVROIzJjudpmFhpFFT3QJP9LCN7D/XO sXdEldlQe7SeaV7RZ8kHWYPXYM/4sr2+UK2V3hErrJu+GHjmTRPIcgp3PWFpOGgtVc/6 TwKP/dJ9Y3Hc+5dOPfh8nDWe/OWQu8+U8duibsKizEQa6+tWv0tf0UCu/SrlhQRk179s JNolSr4pm4+/yo9it6nb5jPhYNrxHQGQKBgHb7hMDDe1Aan+RphIrrms3I+vmkdRdgsU Kd7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/vs4ubuUVZjXz+URCJCqE508HvWQhC/8BDTsggqec/c=; b=oxjSdZf0BIWQb7+UZpX9oHzE80gioI5laCeCqh7hhwOpPEWitAcJo1F29+0Z8UGyLG GhNBRZnkCMcRYDw+5W/7b2vOkldOTHRSfpLO38IywYqVV2pXi02NuZAeTbOMWaCEsDHq hE8wfeHP8DXPYhpxGIvJQyY0vQy49USiJy9I1kf0zIh2lWm41Zezt4zDLlQg3HNK+W33 6fzzLKg8RfwP2LjRMZuOxtGjzTjl+krIYeyVXTOcMuHeLZHM89Mam08y+8nlR1yUcw1o N8dGkVlji3SXsEWjxLKrZOKerNbFCaYMZTj6mIJCFTsAJ0z2vJt9dAdU11+le7Wg5N6W gMQQ== X-Gm-Message-State: APzg51A6hhO3PlGqd76vE3WdOMZvkTAri5cEV5XD2Uk1G+3Eaf+TbAUc 6VaHdISPmRl6V3SfBYkONF+256boiOoQEA== X-Google-Smtp-Source: ANB0VdbLah0PwVpx6kVEXhxLLNaZ5AsWSQQUDM5cazf2+XpCV8cYGFD1qUf8cj5E9DLFfGCuHLf21A== X-Received: by 2002:a50:bdc5:: with SMTP id z5-v6mr29882325edh.46.1536706620243; Tue, 11 Sep 2018 15:57:00 -0700 (PDT) Received: from mutt-hbsd (exit1.ipredator.se. [197.231.221.211]) by smtp.gmail.com with ESMTPSA id m42-v6sm4782091edd.46.2018.09.11.15.56.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 15:56:59 -0700 (PDT) Date: Tue, 11 Sep 2018 18:55:56 -0400 From: Shawn Webb To: "Michael W. Lucas" Cc: current@freebsd.org Subject: Re: jail exec.clean busted in 12? Message-ID: <20180911225556.4koxpwp7u2e4jvyu@mutt-hbsd> References: <20180911195802.GA77575@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xpbbum7cp4unlcji" Content-Disposition: inline In-Reply-To: <20180911195802.GA77575@mail.michaelwlucas.com> X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 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, 11 Sep 2018 22:57:03 -0000 --xpbbum7cp4unlcji Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 03:58:02PM -0400, Michael W. Lucas wrote: >=20 > Hi, >=20 > storm~;uname -a > FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep 6 12:= 29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd= 64 >=20 > It appears that exec.clean is busted. Here's my jail.conf: >=20 > --- >=20 > $j=3D"/jail"; > path=3D"$j/$name"; > host.hostname=3D"$name.mwl.io"; >=20 > mount.devfs; > exec.clean=3D0; > exec.start=3D"sh /etc/rc"; > exec.stop=3D"sh /etc/rc.shutdown"; >=20 > loghost { > ip4.addr=3D"203.0.113.231"; > allow.raw_sockets=3D1; > jid=3D99; > } >=20 > logdb { > host.hostname=3D"logdb.mwl.io"; > ip4.addr=3D"203.0.113.232"; > } >=20 > --- >=20 > exec.clean is not explicitly defined on the command line, but it's the > default, so it maybe shouldn't be? >=20 > storm~;jls -n > devfs_ruleset=3D0 nodying enforce_statfs=3D2 host=3Dnew ip4=3Ddisable ip6= =3Ddisable jid=3D8 linux=3Dnew name=3Dlogdb osreldate=3D1200084 osrelease= =3D12.0-ALPHA4 parent=3D0 path=3D/jail/logdb nopersist securelevel=3D-1 sys= vmsg=3Ddisable sysvsem=3Ddisable sysvshm=3Ddisable vnet=3Dinherit allow.noc= hflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofdescf= s allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allow.m= ount.notmpfs allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.res= erved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.c= ur=3D0 children.max=3D0 cpuset.id=3D6 host.domainname=3D"" host.hostid=3D0 = host.hostname=3Dlogdb.mwl.io host.hostuuid=3D00000000-0000-0000-0000-000000= 000000 ip4.addr=3D203.0.113.232 ip4.saddrsel ip6.addr=3D ip6.saddrsel linux= =2Eosname=3DLinux linux.osrelease=3D2.6.32 linux.oss_version=3D198144 > devfs_ruleset=3D0 nodying enforce_statfs=3D2 host=3Dnew ip4=3Ddisable ip6= =3Ddisable jid=3D99 linux=3Dnew name=3Dloghost osreldate=3D1200084 osreleas= e=3D12.0-ALPHA4 parent=3D0 path=3D/jail/loghost nopersist securelevel=3D-1 = sysvmsg=3Ddisable sysvsem=3Ddisable sysvshm=3Ddisable vnet=3Dinherit allow.= nochflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofde= scfs allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allo= w.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets allow.re= served_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.= cur=3D0 children.max=3D0 cpuset.id=3D7 host.domainname=3D"" host.hostid=3D0= host.hostname=3Dloghost.mwl.io host.hostuuid=3D00000000-0000-0000-0000-000= 000000000 ip4.addr=3D203.0.113.231 ip4.saddrsel ip6.addr=3D ip6.saddrsel li= nux.osname=3DLinux linux.osrelease=3D2.6.32 linux.oss_version=3D198144 >=20 > Anyway, I found this by: >=20 > # jexec loghost env > HOME=3D/home/mwlucas > PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home= /mwlucas/bin > TERM=3Dxterm > LC_COLLATE=3DC > LANG=3Den_US.UTF-8 > SSH_CLIENT=3D203.0.113.70 59076 22 > SSH_CONNECTION=3D203.0.113.70 59076 203.0.113.50 22 > SSH_TTY=3D/dev/pts/2 > SSH_AUTH_SOCK=3D/tmp/ssh-ZfvZOatcsu/agent.60492 > LC_CTYPE=3Den_US.ISO-8859-1 > MAIL=3D/var/mail/root > ... >=20 > I'm highly confident my SSH environment shouldn't be in the jail. Yes, > it goes away if I add -l, but my (admittedly sketchy) reading of the > jexec source says that jexec handles stripping the environment before > running the command. >=20 > Even if I start it the hard way (from a discussion at > https://github.com/iocage/iocage/issues/610) >=20 > storm~;jail -c path=3D/jail/loghost/ host.hostname=3Dloghost exec.clean= =3D1 persist > storm~;jls > JID IP Address Hostname Path > 9 loghost /jail/loghost > =20 > storm~;jexec 9 env | grep -i ssh > SSH_CLIENT=3D203.0.113.70 59076 22 > SSH_CONNECTION=3D203.0.113.70 59076 203.0.113.50 22 > SSH_TTY=3D/dev/pts/2 > SSH_AUTH_SOCK=3D/tmp/ssh-ZfvZOatcsu/agent.60492 > storm~; >=20 > Any ideas? Hey Michael, It appears the jail.exec option is for jail(8) only. You need to pass the -l option to jexec(8) to sanitize the environment. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --xpbbum7cp4unlcji Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluYR/cACgkQaoRlj1JF bu5Geg/9GK9mLxQHZv/C7uL00sokOL1sFIEvqkWiDLdigDn3I0LzYAorMVSmfvqn uAr00sKV0IZzXVhhoPbSKQrbvDSJXzdXdj7pH+OFj6VFL9nL0R9MxTRlQ8UsSh0O beTdQ6klTcGV8d1C56A35pW5CI+EvMqJX4FubSRspacIHi1E+4De+jGV5IG/hYnj uWXxxEORktZ7OtZwS64JXlZJ35AArIivJwMjrdQRx5z/K7PL5pC6Ck+FWr/s9u5P 4OXzn3pXw3DmUSBaUw/VgX0ZT2oyvb/NOYOcVJNn7bIBCBX5PI8Neiw/gRwiKqf2 XH5l2WyAAdQGHUcy1UYJ7BN5oC8D78O3e6ca3SKieQjjg9nCnwSCgxfnEqrj14P3 LRX6jatHc2AAQDdZocELYnKU31sn34JUAkQLnTtBRnWIHUlQ8EbtHwQI0Oy+fB9r NL+phOjVnSfwOB2YgURAOW01E5Dd9qAb0MwBUIwOSCeNT9HzFwkmw1ZnyISD5Wm1 YFdlsVmMdQTEwuF+LHU+ZU/iDHlFsuOktQQs6A7/Q4IlVn4hBq2lCQ9b9KxVXvUm dPxc5WmIsNZbaYiHoOlQJFrmicRGMKFDx70AFQzlrkK3VlVKbVqqtWW+CfdwcuUK Hum1/4Bh/RSd3ogbueKUCBVDEZCTIL51uzmMEig9KhfWdMtRh1Q= =5wtD -----END PGP SIGNATURE----- --xpbbum7cp4unlcji-- From owner-freebsd-current@freebsd.org Wed Sep 12 00:09:05 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 7FFFA10A2D59 for ; Wed, 12 Sep 2018 00:09:05 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 0B78590501; Wed, 12 Sep 2018 00:09:04 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 1FE361604A; Wed, 12 Sep 2018 02:09:03 +0200 (CEST) Date: Wed, 12 Sep 2018 02:10:44 +0200 From: Steffen Nurpmeso To: Eric van Gyzen Cc: Alan Somers , FreeBSD CURRENT Subject: Re: Request for Review: Generate /etc/services from the IANA registry Message-ID: <20180912001044.ArUMb%steffen@sdaoden.eu> In-Reply-To: References: <8b7930bc-1086-05d3-c019-052368ddf097@vangyzen.net> <59cd421e-f5d4-855a-83ec-65726f792555@vangyzen.net> <20180911142000.unrYV%steffen@sdaoden.eu> <20180911150456.JQd44%steffen@sdaoden.eu> Mail-Followup-To: Eric van Gyzen , Alan Somers , FreeBSD CURRENT , Steffen Nurpmeso User-Agent: s-nail v14.9.11-45-g9c6690b7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 12 Sep 2018 00:09:05 -0000 Eric van Gyzen wrote in : |On 9/11/18 10:04 AM, Steffen Nurpmeso wrote: |> Alan Somers wrote in w@mail.gmail.com>: |>|Don't worry Steffen.=C2=A0 Python won't be a build requirement for Free= BSD \ |>|even after Eric's patch.=C2=A0 His Python script will only need to be r= un \ |>|whenever IANA |>|updates its database, and the results will be checked into source contr= o\ |>|l.=C2=A0 So for a normal user, there is no change to "make buildworld &= & make |>|installworld". |>=20 |> I cannot, unfortunately. I use binary updates and even |> preinstalled VM images (thanks for that, by the way). | |So there will be no impact on you at all, except that /etc/services will= =20 |have a lot more services. As Alan said, Python and XML will only be=20 |added to the developer workflow. Oh please, of course. For me personally the FreeBSD version is good enough anyway, it is just that i discovered this script for a pretty common Linux distribution, and adopted it for a lesser common one when there was a need to update the DBs. To be honest i have discovered it in the packaging system in some repository, and that is a pity. FreeBSD as i got to know it, and i would have snooped around in /usr/share/misc of a default install in that case first, and if i would have been lucky i would have discovered good stuff to help me out. That is all. |>|As for Python vs Awk, I too tried to do this with Awk.=C2=A0 However, A= wk \ |>|can't easily handle things like IANA's representation of aliases, and \ |>|it can't |>|easily format the list in the same order as our current list.=C2=A0 Pyt= hon \ |>|is truly a better choice. |>=20 |> I absolutely fail to see what you mean. The script (which is in |> actual use, mind you) generates the desired output except that |> comments get lost, but this could be added upon interest, of |> course. It (or a derivative) would have been a good candidate for |> /usr/share/misc/ in elder times i guess, too. | |That awk script depends on the formatting of the XML file. It will=20 |break if the IANA decides to format it differently. Granted, this is=20 |unlikely, but it's possible. If you argue like this, anything is possible, is it. If IANA changes the XML tags, the Python script needs to be adjusted, too. And if you ask me, i would vote for, and change to JSON. No offense, i said the same on a Unicode list, for example. |Also, that script would become much more complex if it supported local=20 |additions and overrides, which are unfortunately necessary in our case. Come one. I mean, come on. What are you talking about? You have written these things, and they will likely enter FreeBSD. This does not make it just just any better in my eyes. (Though the counting program could be adjusted and be used as a test if the sorted output would be compared against a sed(1) run on /etc/services.) If it would be me, a very small awk script would enter /usr/share/misc, and some makefile would be adjusted and call it, or a duplicate. Base system self-contained, and some nice hint to be found for someone who looks around. I mean, i really looked out of interest at some review page in the webbrowser (glad that you posted this for people who do not like browsers that much, or get email notifications or whatever), which was so large or whatever, anyway it blocked the tab. Isn't that absurd for a simple update framework for IANA databases in /etc? (And what about protocols, by the way.) Just my one cent, of course. I am not even a developer. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Wed Sep 12 00:16:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B0D710A31C7 for ; Wed, 12 Sep 2018 00:16:03 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BFD690ABA for ; Wed, 12 Sep 2018 00:16:03 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-io0-x233.google.com with SMTP id q4-v6so92249iob.8 for ; Tue, 11 Sep 2018 17:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=a9KNXv61i0ldiumGMbgWntiYexzGCcKQaOzMHxj1hTU=; b=kF9ZI691dMHRysE0j3OxhrzLuwn9QHXtXioTMp6SCVT8thPoTnFxBjHzmxIMgCyedm L/t8WDFy7A7aDen5CZVnRPlPC12HXnGWVPztPNRAlh4PeqBKaW/1bYHF9xYC/kQo96J+ 44NdAkU1IW+/v8Qr+KWMK2VcE8qmpuT5863T0= 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=a9KNXv61i0ldiumGMbgWntiYexzGCcKQaOzMHxj1hTU=; b=ARfLCXreBo3OUDGV8p8AaRvOfAd4l8lKxfBoIq0dGHTBGrnKRk6UPNdQ3SCROJdj8z nm7xOJ2VJPzitibNxL8gP7IESQersL1iKZU9GlHWtwk9ILaAv/oawxXAnopIfMzMXs7k pM5O00GM0/w+u7h4Z7nhZPPUBqOBXwc85RU72Aak6czlrvj0I59JOPuFw+OiXZhhmhJV Xr2lkDIt+54ucs8wuGul8AaDuRJofjXXetdaWISXWXgBTSXmLktLTjlk8htUDlqbUKsw j1tLjW8lftOgmPgXy7R6fq7oV6g14OnDWVBtlrm4xrQ8bJy7h484OAMWBQpbDFMIFhaE JsxA== X-Gm-Message-State: APzg51CRFiTrSz95DO4rJhBRns7D2u+JvL/x8bAMpueJFdvUlWpwWtlW z/yHnCyNMhzejgQTtjeuxEW3FxDJ2Z4xej90oAEo9H/FmWYfng== X-Google-Smtp-Source: ANB0VdbCCDYyNallK71bCpBFg047Uliy6WGF95NDl2v1ce+9x9m/UajWpJP8scfk6XQUf9zVt7Tnt5GG/Wm/7HYLWK4= X-Received: by 2002:a6b:1992:: with SMTP id 140-v6mr24543940ioz.251.1536711362066; Tue, 11 Sep 2018 17:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6416:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 17:16:01 -0700 (PDT) From: Kevin Bowling Date: Tue, 11 Sep 2018 17:16:01 -0700 Message-ID: Subject: amd64: enable options NUMA ing GENERIC and MINIMAL To: freebsd-current@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: Wed, 12 Sep 2018 00:16:03 -0000 -CURRENT users, in svn rS338602, 'options NUMA' has just been enabled for amd64 GENERIC and MINIMAL kernels. This should provide good effect to systems with more than one physical CPU with associated memory, certain high core count Intel chips when configured to use Cluster-on-Die or Sub-NUMA-Clustering, and recent AMD products with multiple chiplets like Thread Ripper and EPYC. If you have a single domain system, there is no expected change. If you have such NUMA machines, early testing would be greatly appreciated in order to ensure the quality and stability of the 12.0 release. You can confirm configuration of NUMA domains with 'sysctl vm.ndomains', example output: vm.ndomains: 2 This work was sponsored by Dell EMC Isilon and Netflix and led by Jeff Roberson. Some folks have participated for a long time in bi-weekly calls and stabilization. It is known to be used in production configurations for some time at Netflix and Limelight Networks. If you encounter any issues where you suspect this is the root cause, please disable 'options NUMA' in the kernel configuration and reproduce before reporting as such. This would be a good time to audit your kernel config if copied from GENERIC and consider if you can instead use 'include GENERIC-NODEBUG' to only track local modifications. Regards, Kevin Bowling From owner-freebsd-current@freebsd.org Wed Sep 12 00:39: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 8AEE510A3DA1 for ; Wed, 12 Sep 2018 00:39:48 +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 05A6C91A63; Wed, 12 Sep 2018 00:39:47 +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 w8C0dd8d085178; Tue, 11 Sep 2018 17:39:39 -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 w8C0dcn9085177; Tue, 11 Sep 2018 17:39:38 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809120039.w8C0dcn9085177@pdx.rh.CN85.dnsmgr.net> Subject: Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL In-Reply-To: To: Ed Maste Date: Tue, 11 Sep 2018 17:39:38 -0700 (PDT) CC: junchoon@dec.sakura.ne.jp, 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: Wed, 12 Sep 2018 00:39:48 -0000 > On 11 September 2018 at 07:35, Tomoaki AOKI wrote: > > I prefer releng, rather than stable, to make it default. > > Binary releases requiring reproducible builds are built from > > release and releng branches. > > This might be the reasonable long-term strategy, but we don't yet have > experience running through the release process with it enabled. I > would like to enable it by default on the branch, at least initially, > to avoid discovering issues only immediately prior to the release. I wish we had done this before ALPHA1 it would of given us a larger window to work in. There should be a set of builds Thursday, can we get this turned on for them so we can get at least a build with it before we branch? IE, commit this to ^head/ now. Then once stable/12 is branched we can turn it off in head so the developers are not disturbed. And further then once releng/12.0 is branched we can turn it off in stable/12 so that those users have status quo. This I think gives us maximal test time, including the binary upgrade bits that should get tested between each BETA and RC build. And minimal impact to developers and users. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Sep 12 00:41: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 539A910A3F6C for ; Wed, 12 Sep 2018 00:41:43 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.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 E6E3491D5A for ; Wed, 12 Sep 2018 00:41:42 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id ABB0410A3F6B; Wed, 12 Sep 2018 00:41:42 +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 89C1510A3F6A for ; Wed, 12 Sep 2018 00:41:42 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 3D3F091D55 for ; Wed, 12 Sep 2018 00:41:41 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id w8C0fdSu079001; Tue, 11 Sep 2018 20:41:39 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id w8C0fdFY079000; Tue, 11 Sep 2018 20:41:39 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 11 Sep 2018 20:41:39 -0400 From: "Michael W. Lucas" To: Shawn Webb Cc: "Michael W. Lucas" , current@freebsd.org Subject: Re: jail exec.clean busted in 12? Message-ID: <20180912004139.GA78983@mail.michaelwlucas.com> References: <20180911195802.GA77575@mail.michaelwlucas.com> <20180911225556.4koxpwp7u2e4jvyu@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180911225556.4koxpwp7u2e4jvyu@mutt-hbsd> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Tue, 11 Sep 2018 20:41:40 -0400 (EDT) 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, 12 Sep 2018 00:41:43 -0000 On Tue, Sep 11, 2018 at 06:55:56PM -0400, Shawn Webb wrote: > On Tue, Sep 11, 2018 at 03:58:02PM -0400, Michael W. Lucas wrote: > > > > Hi, > > > > storm~;uname -a > > FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep 6 12:29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > > > It appears that exec.clean is busted. Here's my jail.conf: > > > > --- > > > > $j="/jail"; > > path="$j/$name"; > > host.hostname="$name.mwl.io"; > > > > mount.devfs; > > exec.clean=0; > > exec.start="sh /etc/rc"; > > exec.stop="sh /etc/rc.shutdown"; > > > > loghost { > > ip4.addr="203.0.113.231"; > > allow.raw_sockets=1; > > jid=99; > > } > > > > logdb { > > host.hostname="logdb.mwl.io"; > > ip4.addr="203.0.113.232"; > > } > > > > --- > > > > exec.clean is not explicitly defined on the command line, but it's the > > default, so it maybe shouldn't be? > > > > storm~;jls -n > > devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable jid=8 linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=6 host.domainname="" host.hostid=0 host.hostname=logdb.mwl.io host.hostuuid=00000000-0000-0000-0000-000000000000 ip4.addr=203.0.113.232 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 linux.oss_version=198144 > > devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=7 host.domainname="" host.hostid=0 host.hostname=loghost.mwl.io host.hostuuid=00000000-0000-0000-0000-000000000000 ip4.addr=203.0.113.231 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 linux.oss_version=198144 > > > > Anyway, I found this by: > > > > # jexec loghost env > > HOME=/home/mwlucas > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin > > TERM=xterm > > LC_COLLATE=C > > LANG=en_US.UTF-8 > > SSH_CLIENT=203.0.113.70 59076 22 > > SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22 > > SSH_TTY=/dev/pts/2 > > SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492 > > LC_CTYPE=en_US.ISO-8859-1 > > MAIL=/var/mail/root > > ... > > > > I'm highly confident my SSH environment shouldn't be in the jail. Yes, > > it goes away if I add -l, but my (admittedly sketchy) reading of the > > jexec source says that jexec handles stripping the environment before > > running the command. > > > > Even if I start it the hard way (from a discussion at > > https://github.com/iocage/iocage/issues/610) > > > > storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 persist > > storm~;jls > > JID IP Address Hostname Path > > 9 loghost /jail/loghost > > > > storm~;jexec 9 env | grep -i ssh > > SSH_CLIENT=203.0.113.70 59076 22 > > SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22 > > SSH_TTY=/dev/pts/2 > > SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492 > > storm~; > > > > Any ideas? > > Hey Michael, > > It appears the jail.exec option is for jail(8) only. Ah, okay. Thanks. Not obvious, but makes sense. (So you can run your dirty environment in the jail through jexec? Cool.) ==ml > You need to pass > the -l option to jexec(8) to sanitize the environment. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc... From owner-freebsd-current@freebsd.org Wed Sep 12 00:54: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 5A54310A440D for ; Wed, 12 Sep 2018 00:54:53 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D06549245E for ; Wed, 12 Sep 2018 00:54:52 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id j192-v6so476292wmj.1 for ; Tue, 11 Sep 2018 17:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=w1vupS0mKA+Wpanbx6WL+7ricsXxvPhbeQwTFl4hyxQ=; b=hpxlB6gSAPB/hsAzHkoa5kcH1mu+IsA9GDSgxdP7iYTHXbc+9s6D2sPMMNT8v+ZR7m GSdbUO+2ZjF6DqSUQ+kHkTaqGaTFQzNTelTPwxi3dnW4O2ttiQGge3itPEvEc3LrxhuX PuLoyqC68/TSPuAJM9++YJMVAYN43kKt1430R9eEbMe0sR/RqPrFDm+weOHpLJSmx5US dAVt7rv8Z1EjaUa84iE0y/+9EhU4CAkrozkXGyVjn23bBHyFWKyQ6QDGWSOlPritU7V1 ct/5FLk14K0tI9ntD1k0Z1jmoD8yvQo06Nz3vDcMCJHagVyGHyHmnSpxLOc5/TQ8KmO/ kX5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=w1vupS0mKA+Wpanbx6WL+7ricsXxvPhbeQwTFl4hyxQ=; b=RXRBYdJOrCClLRJ7BUiGujx9C78n6s/nSj+uYrJbZ7U81kRl9JxBD/01ePDxjVDjYH wyFUQll7YnaBujR8qfX7HjuES7pfoc76oz6UAflyGuVIwEUFNG3nmYuXWEsrtJGFn2rU GulBOMDm3n84A7GrlzeFksgMmN4Nn+IpTUVC5SJ5O98WsHFgRGS1sk58MSoVXNXeynYV azii/yIar+wUXcyGUjBBMU0eH1V6Oxa9v3NJxG2FVoqwYDzyt7DkvDAZfQutmBc3l510 V55nofobdfL/0RZwz0oPVrhqfZ8NwA5FCbJHkFwExirGhsLtVmKSpV9yl75mcPRu5JHs XcwA== X-Gm-Message-State: APzg51AmI6+6lykH6bkkkjQoleb7XGVmpulmJGNvzcPzlIVf0jZGbQzz 6AeHR8llw5y4Rl97iqnNr67t6NClML4= X-Google-Smtp-Source: ANB0VdaBeuv7tDo3FEX+8YkQbTMJHcM+1DQSrzkJvasmbtZv2vBqT0UEKJLNv3kr+KPVaEb1cLbgEA== X-Received: by 2002:a1c:3a92:: with SMTP id h140-v6mr3048351wma.41.1536713690975; Tue, 11 Sep 2018 17:54:50 -0700 (PDT) Received: from [192.168.1.231] (79-66-139-63.dynamic.dsl.as9105.com. [79.66.139.63]) by smtp.gmail.com with ESMTPSA id j133-v6sm4141241wmd.12.2018.09.11.17.54.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 17:54:49 -0700 (PDT) Subject: Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M To: Pete Wright , freebsd-current References: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> From: Graham Perrin Message-ID: <64b8ed0a-0a90-5b70-3288-81a091dde0fd@gmail.com> Date: Wed, 12 Sep 2018 01:54:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> Content-Type: text/plain; charset=utf-8 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: Wed, 12 Sep 2018 00:54:53 -0000 On 22/08/2018 17:50, Pete Wright wrote: > > On 8/22/18 2:11 AM, Graham Perrin wrote: >> HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M. … >> With and without drm-next-kmod: >> if boot is hybrid UEFI with CSM, >> then suspend occurs, but resume fails. No beep, the computer restarts. >> >> debug.acpi.resume_beep=1 >> in /boot/loader.conf for an audible beep. >> >> ---- >> >> Please: might graphics/drm-devel-kmod be better for either the tearing (without CSM) or for suspend? > > not sure this will address this specific issue - but have you tested setting this sysctl knob and seeing if that fixes your resume issues: > hw.acpi.reset_video=1 > > -pete > Thanks again. Briefly: - with CSM - with hw.acpi.reset_video=1 - without using /boot/modules/radeonkms.ko - FreeBSD 12.0-ALPHA2 #2 r337986: Fri Aug 17 22:01:23 BST 2018 Result: - endless beep when resume is attempted. A short press on the power button (around two seconds, not long enough to stop the computer) temporarily silences the beep. ---- there's the additional advice from Johannes Lundberg. Updating the OS etc. now, I'll share test results in due course. * * From owner-freebsd-current@freebsd.org Wed Sep 12 02:19:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEA8810A6516 for ; Wed, 12 Sep 2018 02:19:25 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A04694D30 for ; Wed, 12 Sep 2018 02:19:25 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id 20-v6so260686wrb.12 for ; Tue, 11 Sep 2018 19:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=SM6ZvsUzr9eNUqrulwuWfh7yaF/t/b7PckkurUkA3H0=; b=JKr8nYGHUvT6RWhsh3PLOGyVyvrSeDyflFmeKdzzYm2s4QsMypKMKng6cU4vnR5ftr iAwIq90TZ6ZeG3MmiUqC1459vlZj89mUZIfeL1iZpK4tyr489l6/3C/0zNWkil1VmU1s 6NAiihT6YsMKoGLuMJvo776ayj0XR+pIdTkJFHwIXeEIoCB3TVhZKrkIy0AokW+O14Nw KZVad6bnTmUwS+dl4R/BsFdyc9sZjtm2NJ0q1B6SNxP9SOmhQSOrozlt3Qhli8lw6VIj 33LHuoQa3SZ9MEOAILESRbnmuXyOSIkBt1BSTzcoVqkNVSZZj4LTWIr9fhqzJR7yFHwn DquQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=SM6ZvsUzr9eNUqrulwuWfh7yaF/t/b7PckkurUkA3H0=; b=qNj5IhYvCwFq4LNs1ihZ+hNPKI2JSrifeYQg4H7mfiIFGiU7gRKwgXK7vLVdthjpIR ySbjZEVW61JvGKu9tX1jOeH2oNba2SSqnKEe5yuCcVkFJemHb2LbEFA3v7Lt04SEJpUk TIy4cNF4oA4Lm7iwr0D9nklM0M/GqhJAk38xsMW+SkAJwOJJOwd65KgnnxgbMBjIGLHG RpyFa+ka1N1TQhZZBd+INewaFVbi6v9RKCmyef6wHxDi+6+tjIs1N7v4pJlRyCq7M27G Zeg2ZzHKyuFiJXWrG/DF3RtN3+wBg0inv5iyFNYKpwPeDEL3MSWLJPb5fBOnXYTbmjYj nSdw== X-Gm-Message-State: APzg51A2nl6nFHsc1BJ9rqMO/6bfx0bqkW9Gm6ne727WAvqyGEkBRnBg L78UcnM2QKsrdn3uKUyk/EMYFV5WaZs= X-Google-Smtp-Source: ANB0VdbsV2w45LX4k2T7cXKqRXPMy13c3vODX1TscnsYZLfSR2LfifKTEW9KKgUttiCiTOS8wCZ3NQ== X-Received: by 2002:adf:ea4f:: with SMTP id j15-v6mr21855576wrn.224.1536718762971; Tue, 11 Sep 2018 19:19:22 -0700 (PDT) Received: from [192.168.1.231] (79-66-139-63.dynamic.dsl.as9105.com. [79.66.139.63]) by smtp.gmail.com with ESMTPSA id s13-v6sm26874951wrq.39.2018.09.11.19.19.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 19:19:21 -0700 (PDT) Subject: Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12) To: freebsd-current@freebsd.org References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Graham Perrin Message-ID: <5c54cb3c-2ada-356c-4bec-510c1893198b@gmail.com> Date: Wed, 12 Sep 2018 03:19:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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: Wed, 12 Sep 2018 02:19:25 -0000 On 25/08/2018 09:32, Ali Abdallah wrote: > Isn't Intel supposed to be working on a native drm driver for FreeBSD? > > https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/ … Not that I can see.  A more recent blog post mentions "Help i915 drm-next-kmod work". HTH From owner-freebsd-current@freebsd.org Wed Sep 12 02:24: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 A52D710A67CB for ; Wed, 12 Sep 2018 02:24:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.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 0B2B29518C for ; Wed, 12 Sep 2018 02:24:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3ZdQWm4VM1l4hYoOYczE3I0zvmitYtLmi_P3xuvWE1mFOLf3c71VsWVVvWZ5jTb gSGzUzfT.Erbj7bPCYDVO9ducmWL5zTkGygURKCKbZXXdLT02qMlf8AyIfGEFvk0UfCtvhOtUaIW HS.xEaV2XmmOIsqHN26D5z8LEE.s3b2WBacvgJyhN_iN.xgJ261cYi84Tk..8z_Q_SlT596HMuhm zKtVg9di4.a1uU3Q4_7OjQAjY4AiDsUFRtHt1Ii9H.XDwHtNmzaXKOmW3.HJSYy8Ta68swsO0BE7 yQzs8ozpLoR.HsIPQ5C6olnRzMHWQcz7XXCTUqodQiLy.4Lpn4dcs1_.JSOItSkE1_tcZ6K6qeYK iTDuiqml10WmzBbMUQaOwHwefCdhyl2TXTQPA0Nb4wb_IJTwC3E2AU12MUQ1NIsPWDt2ZGJekVM2 CwAskKdAvKLUc0.vvJJNLG0.INwTyEW3XjAxXbN1KXZCu3H4nHJWxBv7X7_OO6hfS7piVcTGm1EU 6sl98UUsfHeZS6KDVC5xsTulAgpPz7QAuztA3L23_e.PqPW3P_ap1zINDP7f1D4ujmoBLWIDqB7I AmaI1pJz3zu5XL7Lqsf8b7.STNXLS5gmkKbf4xSOwTPUPDaDSwSns3eRcxEFpoExcdgKQNJgecZ8 9Hwa8ZeDzOIwwK39axGMt_R7eQX_LIUxp9ugg0XvwnnPrs4X2rNXaEV8nnQoP0JZ_fKRtlGWQLSw SMmbyy72Cu5QS4qk6BXZhtpAhuay1Eu6wXMHL.DY4t85HB8FygT0Z6TtSHpR4VAPk08N99vpDOws Xri3naB2HT6LgCPOTg3ED1NmV1d4cOTSz9hg9zMIq3Pmq7gg2BHb8NSX0Az9ZKxrlMJBb4k7REry PhQ1zrfzmBl85RMI7PBXJygRChPg8t8iEA2FfPH1XyfFL8VimYVhvKp2ngyVL32m91Se38VwJXD8 3b66xz2vp7aDWvMeruHaRGYdH_8GHeY10mJFLT3lS__JzZYglYqMuL6pNy3bHxuoDsIOVOxFIvFK fTnENYQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Sep 2018 02:24:04 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 927b9386155167cb3794e88956251398; Wed, 12 Sep 2018 02:24:01 +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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context [md related processes left waiting (and more)] Date: Tue, 11 Sep 2018 19:24:00 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: <3E3E4449-E132-4F59-87C8-22A0AD2092BF@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: Wed, 12 Sep 2018 02:24:11 -0000 [After the run top -CawSopid shows something interesting/odd: lots of g_eli[?] and md?? processes are still around in=20 geli:w state for g_eli[?] and mdwait for md??. Also there are 4 processes in aiordy state.] On 2018-Sep-11, at 8:48 AM, Mark Millard wrote: > [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. > lib/libc/string/memcmp_test:diff is one of them.] >=20 > On 2018-Sep-11, at 2:44 AM, Mark Millard wrote: >=20 >> [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] >>=20 >> I got 14 failures. I've not enabled any configuration properties. >>=20 >> I do not know if official devel/kyua tests are part of the head -> >> stable transition for any tier or not. I'm not claiming to know if >> anything here could be a significant issue. >>=20 >> Someone may want to test an official aarch64 build rather than = presume >> that my personal build is good enough. But I expect that its results >> should be strongly suggestive, even if an official tests uses a more >> normal-for-FreeBSD configuration of an aarch64 system. >>=20 >> The e.MMC is V5.1 is operating in DDR52 mode and is faster than = normal >> configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file >> system. This might let some things pass that otherwise would time = out. >>=20 >>=20 >> =3D=3D=3D> Failed tests >> lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] >> lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see = the output of the test for details [0.107s] >> lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] >> lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] >> lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output = for more details [0.013s] >> lib/msun/trig_test:special -> failed: 8 checks failed; see output = for more details [0.013s] >> local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] >> local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: = Line 420: atf::utils::grep_file("^frame 1$", = exit_handle.stderr_file().str()) not met [4.470s] >> local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] >> local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] >> local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] >> sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] >> usr.bin/indent/functional_test:nsac -> failed: atf-check failed; = see the output of the test for details [0.151s] >> usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] >> =3D=3D=3D> Summary >> Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db >> Test cases: 7301 total, 212 skipped, 37 expected failures, 116 = broken, 14 failed >> Total time: 6688.125s >>=20 >>=20 >>=20 >>=20 >> I'll note that the console reported over 73720 messages like (with = figures >> where I've listed ????'s): >>=20 >> md????.eli: Failed to authenticate ???? bytes of data at offset ????. >>=20 >> There are also device created and destroyed/removed notices with = related >> material. Overall there were over 84852 lines reported with = "GEOM_ELI:" >> on the line. >>=20 >> This did not prevent tests from passing. >>=20 >> (The huge console output is unfortunate in my view: it makes finding >> interesting console messages a problem while watching messages >> go by.) >>=20 >>=20 >>=20 >> I did get the console message block: >>=20 >> kern.ipc.maxpipekva exceeded; see tuning(7) >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with = non-tentative address (epair2Freed UMA keg (rtentry) was not = empty (18 items). Lost 1 pages of memory. >> a) >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >>=20 >> But no failure reports seemed to be associated. >>=20 >> Still, I wonder if the block of messages is significant. >>=20 >>=20 >> Some other console messages seen (extracted from various places): >>=20 >> GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] >> GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] >> GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] >> GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). >> GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). >> GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] >> GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] >> GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] >>=20 >> Again no failure reports seemed to be associated. >>=20 >>=20 >> Some or all of the following may be normal/expected: >>=20 >> Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: = exited on signal 3 (core dumped) >> Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited = on signal 6 (core dumped) >> Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: = exited on signal 6 (core dumped) >> Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited = on signal 6 >> Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited = on signal 11 (core dumped) >> Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited = on signal 11 (core dumped) >> Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited = on signal 3 >> Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited = on signal 3 >> Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated >> Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited = on signal 6 >> Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited = on signal 6 >> Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited = on signal 6 >> Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited = on signal 5 (core dumped) >> Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) >> Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) >> Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: = exited on signal 11 (core dumped) >>=20 >> I'm not sure that they all would be expected. >=20 > =3D=3D=3D> Broken tests > lib/libc/string/memcmp_test:diff -> broken: Premature exit; test = case received signal 6 (core dumped) [3.962s] > lib/libregex/exhaust_test:regcomp_too_big -> broken: Premature exit; = test case received signal 11 (core dumped) [8.997s] > lib/msun/exponential_test:main -> broken: Received signal 6 = [3.893s] > lib/msun/fenv_test:main -> broken: Received signal 6 [4.326s] > lib/msun/fma_test:main -> broken: Received signal 6 [4.315s] > lib/msun/invtrig_test:main -> broken: Received signal 6 [4.345s] > lib/msun/logarithm_test:main -> broken: Received signal 6 [3.921s] > lib/msun/lrint_test:main -> broken: Received signal 6 [4.416s] > lib/msun/nearbyint_test:main -> broken: Received signal 6 [4.389s] > lib/msun/next_test:main -> broken: Received signal 6 [4.401s] > lib/msun/rem_test:main -> broken: Received signal 6 [4.385s] > sbin/growfs/legacy_test:main -> broken: TAP test program yielded = invalid data: Load of '/tmp/kyua.5BsFl9/3782/stdout.txt' failed: = Reported plan differs from actual executed tests [0.476s] >=20 > sys/cddl/zfs/ ones ignored here: no zfs context. One more thing of note after kyua completed (the Pine64+ 2GB has been mostly idle since then), top shows: last pid: 59782; load averages: 0.22, 0.25, 0.19 = = up 0+19:13:11 19:11:36 122 processes: 2 running, 119 sleeping, 1 waiting CPU: 0.0% user, 0.0% nice, 0.0% system, 0.1% interrupt, 99.9% idle Mem: 2164K Active, 1474M Inact, 14M Laundry, 365M Wired, 202M Buf, 122M = Free Swap: 3584M Total, 3584M Free PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 82157 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md27] 82156 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md27] 82155 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md27] 82154 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md27] 82147 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md27] 82001 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md26] 81941 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md25] 81940 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md25] 81939 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md25] 81938 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md25] 81925 root 1 -8 - 0 16K 0 mdwait 1 0:00 = 0.00% [md25] 81777 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md24p1] 81776 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md24p1] 81775 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md24p1] 81774 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md24p1] 81701 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md24] 81598 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md23] 72532 root 1 -8 - 0 16K 0 mdwait 0 0:01 = 0.00% [md22] 70666 root 1 -8 - 0 16K 0 mdwait 2 0:01 = 0.00% [md21] 70485 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md20] 70484 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md20] 70483 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md20] 70482 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md20] 70479 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md20] 70413 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md19.nop] 70412 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md19.nop] 70411 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md19.nop] 70410 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md19.nop] 70393 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md19] 70213 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md18] 70212 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md18] 70211 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md18] 70210 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md18] 70193 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md18] 70088 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md17] 59763 root 1 -8 - 0 16K 0 mdwait 3 0:01 = 0.00% [md16] 49482 root 1 -8 - 0 16K 0 mdwait 2 0:01 = 0.00% [md15] 27196 root 1 -8 - 0 16K 0 mdwait 0 0:04 = 0.00% [md14] 27018 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md13] 26956 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md12] 26364 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md11] 16100 root 1 -8 - 0 16K 0 mdwait 2 0:03 = 0.00% [md10] 15556 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md9] 15498 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md8] 15497 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md8] 15496 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md8] 15495 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md8] 15462 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md8] 13400 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md7] 13101 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md6] 13005 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md5] 13004 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md5] 13003 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md5] 13002 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md5] 12995 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md5] 12877 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md4] 12719 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md3] 12621 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md2] 12559 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md1] 12558 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md1] 12557 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md1] 12556 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md1] 12549 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md1] 12477 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md0] 1345 root 1 -16 - 0 16K 0 aiordy 1 0:00 = 0.00% [aiod4] 1344 root 1 -16 - 0 16K 0 aiordy 3 0:00 = 0.00% [aiod3] 1343 root 1 -16 - 0 16K 0 aiordy 2 0:00 = 0.00% [aiod2] 1342 root 1 -16 - 0 16K 0 aiordy 0 0:00 = 0.00% [aiod1] 34265 root 1 20 0 14M 2668K 0 CPU3 3 3:10 = 0.28% top -CawSores 34243 root 1 23 0 12M 1688K 0 wait 2 0:00 = 0.00% su (sh) 34242 markmi 1 20 0 13M 1688K 0 wait 2 0:00 = 0.00% su 34236 markmi 1 21 0 12M 1688K 0 wait 0 0:00 = 0.00% -sh (sh) 34235 markmi 1 20 0 20M 1312K 0 select 1 0:09 = 0.01% sshd: markmi@pts/1 (sshd) 34230 root 1 21 0 20M 3460K 0 select 3 0:00 = 0.00% sshd: markmi [priv] (sshd) 898 root 1 52 0 12M 1688K 0 ttyin 1 0:00 = 0.00% su (sh) 897 markmi 1 21 0 13M 1688K 0 wait 2 0:00 = 0.00% su 889 markmi 1 26 0 12M 1688K 0 wait 3 0:00 = 0.00% -sh (sh) 888 markmi 1 20 0 21M 1016K 0 select 1 0:03 = 0.00% sshd: markmi@pts/0 (sshd) 885 root 1 23 0 20M 3460K 0 select 2 0:00 = 0.00% sshd: markmi [priv] (sshd) 836 root 1 20 0 12M 2164K 0 ttyin 0 0:03 = 0.00% -sh (sh) 835 root 1 20 0 13M 1688K 0 wait 1 0:00 = 0.00% login [pam] (login) 785 root 1 52 0 11M 884K 0 nanslp 0 0:01 = 0.00% /usr/sbin/cron -s 781 smmsp 1 20 0 15M 796K 0 pause 3 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = (sendmail) 778 root 1 20 0 15M 1832K 0 select 2 0:02 = 0.00% sendmail: accepting connections (sendmail) 775 root 1 20 0 19M 788K 0 select 1 0:00 = 0.00% /usr/sbin/sshd 731 root 1 20 0 18M 18M 0 select 3 0:07 = 0.01% /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g 694 root 32 52 0 11M 1112K 0 rpcsvc 0 0:00 = 0.00% nfsd: server (nfsd) After the run top -CawSopid shows something interesting/odd: lots of g_eli[?] and md?? processes are still around in geli:w state for g_eli[?] and mdwait for md??. Also there are 4 aiod? processes in the aiordy state as well. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Sep 12 03:03:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEB5810A73A0 for ; Wed, 12 Sep 2018 03:03:25 +0000 (UTC) (envelope-from kaduk@mit.edu) 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 62A0E963B3 for ; Wed, 12 Sep 2018 03:03:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: by mailman.ysv.freebsd.org (Postfix) id 271F310A739F; Wed, 12 Sep 2018 03:03:25 +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 15ADF10A739E for ; Wed, 12 Sep 2018 03:03:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B0A1963B2 for ; Wed, 12 Sep 2018 03:03:24 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-0b1ff70000005071-a1-5b9880c8f89d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A6.23.20593.8C0889B5; Tue, 11 Sep 2018 22:58:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8C2wDVI030762; Tue, 11 Sep 2018 22:58:14 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8C2w9Q2028470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Sep 2018 22:58:12 -0400 Date: Tue, 11 Sep 2018 21:58:09 -0500 From: Benjamin Kaduk To: Jeffrey Bouquet Cc: current Subject: Re: Upcoming release of V 12 Message-ID: <20180912025809.GL48265@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nonuyYUa0wZ+tghYTrvxgsvj64Suz A5PHjE/zWTyuv+xkDGCK4rJJSc3JLEst0rdL4Mro//KKtaCZteLToV/sDYyvmbsYOTkkBEwk duz4y97FyMUhJLCYSeLLvKlQzkZGiflvv7JCOFeZJB7t/MQE0sIioCqxZ/F7MJtNQEWiofsy 2CgRAX2JZzf3sYHYzAKKEqcPzGIBsYWB6nfN+QMW5wVaN/fFG8YuRg6goQYS09eEQYQFJU7O fMIC0aolcePfSyaQEmYBaYnl/zhAwpwChhL9h3aATREVUJbY23eIfQKjwCwk3bOQdM9C6F7A yLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjKEg5JXl2MJ5543WIUYCDUYmH d8W+6dFCrIllxZW5hxglOZiURHmPGMyIFuJLyk+pzEgszogvKs1JLT7EKMHBrCTC+y0DKMeb klhZlVqUD5OS5mBREuc9qzs5WkggPbEkNTs1tSC1CCYrw8GhJMF7ph6oUbAoNT21Ii0zpwQh zcTBCTKcB2j4I5Aa3uKCxNzizHSI/ClGXY4/76dOYhZiycvPS5US560EKRIAKcoozYObA0ou Etn7a14xigO9Jcz7GKSKB5iY4Ca9AlrCBLRk3fkpIEtKEhFSUg2MatE7tt989dD9P3f1L229 K1FxPEUlZnvfrszLFkvOZkrvyW79vfxU75XCA10fYxKMt0toPOnSPls8g+Xkr8fac72SbN/l hV/P8PmQeHNH2CF9betnKhwLSoM9mjZK7+r6WCb52eTn7El8B4VrUti+t1TNOlRo9fne5CPT UkO3O2lt63p96WqmEktxRqKhFnNRcSIApxJHMwkDAAA= 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, 12 Sep 2018 03:03:26 -0000 On Tue, Sep 11, 2018 at 10:21:31AM -0700, Jeffrey Bouquet wrote: > I'm running v12 as HEAD [ 12.0-CURRENT] > > And am at a loss as to how to change it to 12.0-STABLE vs one day > running a non-rebuilt 13.0-CURRENT > > Without risking a scenario such as: > svn up 12.0, fail for some reason to be able to build the GPU driver, so I should > have stuck with svn up 13.0 ??? > As I've no second machine setup as backup. due to moving issues. The stable/12 branch does not yet exist in Subversion. Once it does, you'd be able to use 'svn switch' to switch from tracking base/head to tracking base/stable/12 . -Ben From owner-freebsd-current@freebsd.org Wed Sep 12 14:33:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDCC11094FBA for ; Wed, 12 Sep 2018 14:33:24 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BBD384F4B for ; Wed, 12 Sep 2018 14:33:24 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by mail-lf1-x12e.google.com with SMTP id m26-v6so1914301lfb.0 for ; Wed, 12 Sep 2018 07:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zcv9iHDTs9ls2gOzrtNnrCJyEgXNcK8BqyvH8+1lyxs=; b=LHVl8bJeKb87nc7j3FGLEbzkBIJBi5JpR4X9z3sW9kjHLh1Hk6dPRQair3WazLJ/FC ucOXXahlxPB+A4eYpmH3qH5DwUdf4qCPFOBK8oYVILv7WsaeC+c2ZBJ/5cjCTwii0BaH 4lqCEgQ/A9/zTwgb1PbIOiUPqXSAMYQZG8Ma7nbT1wwCilWGVjnqVRtMRqSmaRS563TK qyX/kZfypHnX+WVBtqFs/EzaJh0c66JC591ptEw6q8FU48bOFmP2jE6ShjIrIicW6GD7 zXtzVkNn9BRZfzuknvPVsaMX0CdsPZ4apzhsazNA2bOb2C+8s1/cArFtXeDC5DwQqxbv FcOg== 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=zcv9iHDTs9ls2gOzrtNnrCJyEgXNcK8BqyvH8+1lyxs=; b=j05rP111hCKijw0DDs4TluTrGF2T1OCXjMOT3UMpAyQSUoE81eAJz2DQgWVQ64JQw3 t9tEGTDG313JJhDgepv0nQt7hX1J1OAHLpYaHI30FNTSfnAyFwf7nAeMKnSgZFo9F19a WtkahM1d3V/Eg3ZzNzgKZRGP/r2V9aYxosf/M8UTOHhHlScdO2bE9aaGyX9vSIggPHMB UiEtYNOpcuOnk106gPgq19HamKGaxCsTMAo3svh7/S+8Z30oHzcKoUzh6rR8nREG48cn DD1jxjXcCbwMfq5rFitZ93n0gewyGLsa4eOc5XlI4xj+sqBe8RHxzcBnurrCSuSVF8fs Xxww== X-Gm-Message-State: APzg51BYarXH79XIWmpC6rs6C3hmy9lKfUGB5rmxEIv/IfVWJdFjguay dRgMZ6XnAeUlVB4UVcZekjEeWEYrsHGXBVb8gzI= X-Google-Smtp-Source: ANB0VdaEHL94nkcudimgexZgx5ciZ24y1atEcbdCPPFmZTxbsxnfqM0dZ/efVaasLmW08040sSYXTrF8BM2y92dsLe0= X-Received: by 2002:a19:c646:: with SMTP id w67-v6mr1818919lff.108.1536762802766; Wed, 12 Sep 2018 07:33:22 -0700 (PDT) MIME-Version: 1.0 References: <72380894-6f0c-30e9-b755-d79a8a38a1eb@gmail.com> In-Reply-To: <72380894-6f0c-30e9-b755-d79a8a38a1eb@gmail.com> From: Max Ignatenko Date: Wed, 12 Sep 2018 15:33:10 +0100 Message-ID: Subject: Re: r336876 breaks sysutils/acpi_call To: theron.tarigo@gmail.com Cc: freebsd-current X-Mailman-Approved-At: Wed, 12 Sep 2018 16:03:24 +0000 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, 12 Sep 2018 14:33:25 -0000 Hi, Sorry for a late reply! First of all, thank you for taking time to investigate and even providing a fix (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230993) ! Your patch makes perfect sense to me and modifying userspace memory from kernel is indeed something I didn't consider to be a problem at the time. Second, I'm not actively participating in FreeBSD community and development at the moment, and if you're willing to take over sysutils/acpi_call - I'll be happy to cooperate. Otherwise, I'll try to take time to incorporate your fix in the few upcoming weeks. On Sun, 26 Aug 2018 at 04:51, Theron wrote: > > A recent change in CURRENT has sysutils/acpi_call reliably cause a > kernel panic when run on a Dell XPS laptop system. I bisected this to > r336876: Use SMAP on amd64. I would have thought that this is a simple > compatibility problem requiring only a port update, except that the same > kernel and acpi_call on different hardware are not affected. On the > problematic system, the kernel module loads without incident; it is when > executing ACPI commands, even normally harmless operations such as > requesting read-only constants, that the system freeze occurs. ACPI > functionality seems otherwise unaffected. > > Kernel debugging console and crash dumps are also broken on this system > (I suspect due to Intel graphics) however it is an unrelated problem, > and is only an excuse for my inability to provide any further crash > information. > > Having already bisected to the breaking commit, is there anything else I > should do to improve the chances this problem gets fixed, or are there > any hardware compatibility notes I may have missed? > > Theron > From owner-freebsd-current@freebsd.org Wed Sep 12 18:48: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 D41BD109A64C for ; Wed, 12 Sep 2018 18:48:16 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D2A08DCFF for ; Wed, 12 Sep 2018 18:48:16 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id 13-v6so5861456ois.1 for ; Wed, 12 Sep 2018 11:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G/AxUp3EbtMiULQuovRmXE2t1uZp8HlVCLwZ3d1ND14=; b=Kp+qshYYX7nVO+iLVB+8imZ5D39NbkyGc9eNgzpsDKqsY7m71AYlfHVSYbJCMslxG4 WvHTecFEbApK5QCVrOEX9Uq6cuuEdDGO8a9UaxJ4fZC+F7bg3jCYSBX9G2XVCZ4aHfs3 D1dhNcNP0EBd2FRS5dDzyz6TI457iuG287MC+600Oyt6H1OuXrrRLmwbC5QRTT1otBBM FSZm0fLW7vNhXX0h7KeZbqJ1TUDSfZsssrfsveyu8tQCijwj4iGPI7qiTKyspke7+xH+ 5r3OEUMQHXw+BzxwjEbiTszIL3a3xsrDtYPISbCu59g8ZiErX9rMDH9PKeel73L6flZT JILw== 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=G/AxUp3EbtMiULQuovRmXE2t1uZp8HlVCLwZ3d1ND14=; b=cwkzWkAjwTJuojbIO1uYm6QDMli/QwpZ7YH/neFaN4URljKnnA1Dpu8a6C+to9v5oe lcwOTZjnsIw3L4n4+wqAUoCqQFatggvodWXk/5z1lv7BJi+N3wFXQAzWDwtc8VGOiBFT 5Gr/SiZX3SXzlYsUnOCjnU/2qoQzZCM2jO1rCwlllMzyFetiMxtsdIcfGpfwdbl831+d RveWY4NzfM2F2GGCbEwl5cg8xqqy4ZND9ppdOA5wxevdtcSyYXW/Fvo+769xyBLxzLm1 8GjaKlfZ87M+Zw8LJxCIHSas6lnhkpRaheztYomyM0JE6iOceQsGn178stPTZUu9tVae cJ3A== X-Gm-Message-State: APzg51CV2nBi9b8OQrH5YP9kFT6fizLioo3MvvnUkkLANGGs8tZC19Tz JpgITFL6gsRAn72kot/2PmnP+JlKuQFRtL8vnfw= X-Google-Smtp-Source: ANB0VdYOJHTYtjNsrQb2R84UItbMaCHQy+l4Oh+5Uz9HrrZvja3LfeiQrzHKEHV7uB1g9fOudSfMfxS0xDK+lNdlyrA= X-Received: by 2002:aca:d4cd:: with SMTP id l196-v6mr3508953oig.15.1536778095599; Wed, 12 Sep 2018 11:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:72c2:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 11:48:15 -0700 (PDT) In-Reply-To: <5c54cb3c-2ada-356c-4bec-510c1893198b@gmail.com> References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <5c54cb3c-2ada-356c-4bec-510c1893198b@gmail.com> From: Ali Abdallah Date: Wed, 12 Sep 2018 20:48:15 +0200 Message-ID: Subject: Re: Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12) To: Graham Perrin Cc: freebsd-current 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: Wed, 12 Sep 2018 18:48:17 -0000 On Wed, Sep 12, 2018 at 4:19 AM, Graham Perrin wrote: > On 25/08/2018 09:32, Ali Abdallah wrote: > > Isn't Intel supposed to be working on a native drm driver for FreeBSD? > > > > https://bwidawsk.net/blog/index.php/2018/06/i965- > compiler-architecture-from-2015/ > =E2=80=A6 > > Not that I can see. > > A more recent blog post index.php/2018/06/freebsd-work-week-2/> mentions "Help i915 drm-next-kmod > work". > I saw that post already, It also mentions "Create native Intel graphics driver." > > HTH > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Wed Sep 12 21:13:56 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 85ADA109D380 for ; Wed, 12 Sep 2018 21:13:56 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 EDF23723E3 for ; Wed, 12 Sep 2018 21:13:55 +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 22D2D344 for ; Wed, 12 Sep 2018 17:13:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 12 Sep 2018 17:13:54 -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=Gtx8nCR9iVsN8crfBVv6e2hJq5pE4 qH7PzPS72iP9yI=; b=pkEEKPCOHJk5DjE1lAHswtezAda6QOeXL1CgurkGFrn8f K15XVgB8xyBWBa5zOMxOg4BWI8bkofJU4YLym2WPQ2sA3WLY4sZJzsiKxwek7HKz 2sioheTiPbgZwFzdtc/GGPBGvs8VF7Zke6eNvCVtS/PtVL8E48xWQftBzuj8W52v UVazQYII8Huxj4sMhzaCgG26fFCu0lXtIrNwARyzzNwDAlyPEOEJZu7b6FUAOxVO tPFwUeWsdGYV8uBxJAC3dNWfan1prYf2JrBxzHLepBBSHcLnNvh4FMVG6Fws8PcQ DEeJXblcmnGcBcBbbSd+XoZ9qYXqT9FNkI66+2FKA== 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=Gtx8nC R9iVsN8crfBVv6e2hJq5pE4qH7PzPS72iP9yI=; b=TBOrIa/jiAlaga2vYnTWWU L7Lxf9+1gCtwFHRhgZEsL1VD28dSur2EYFdJNxLTDgFm6CfzzT34QFSmaCBIinpy TQ65HRUUk+bbE7l8k/ykbdW9DalLlOfjOA7WqEYBh+2NPSkqRuaPprCw7nXOK55p 8z557JNQ7abThHMAUm/W1clTw4f559mQFdthKXdG+0TLTpKvRZR211Uuu+pJao5D QHkJz8nso0pYy0y9sNgjyUUFQjKVx+GaHzpOuYYLQO98Bvy6MqQs0z+OEJAK9Zcr wSxxS+k42gGUFG9yzF2gJwlus7W7jHKqZVdHkcCi8zbXADfXUHyycJPMQNvC2TOg == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.113.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F20B102D6 for ; Wed, 12 Sep 2018 17:13:52 -0400 (EDT) Subject: Re: r336876 breaks sysutils/acpi_call To: freebsd-current References: <72380894-6f0c-30e9-b755-d79a8a38a1eb@gmail.com> From: Yuri Pankov Message-ID: Date: Thu, 13 Sep 2018 00:13:51 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.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: Wed, 12 Sep 2018 21:13:56 -0000 Max Ignatenko wrote: > Hi, > > Sorry for a late reply! > > First of all, thank you for taking time to investigate and even providing a > fix (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230993) ! Your patch > makes perfect sense to me and modifying userspace memory from kernel is > indeed something I didn't consider to be a problem at the time. > > Second, I'm not actively participating in FreeBSD community and development > at the moment, and if you're willing to take over sysutils/acpi_call - I'll > be happy to cooperate. Otherwise, I'll try to take time to incorporate your > fix in the few upcoming weeks. > > > On Sun, 26 Aug 2018 at 04:51, Theron wrote: > >> >> A recent change in CURRENT has sysutils/acpi_call reliably cause a >> kernel panic when run on a Dell XPS laptop system. I bisected this to >> r336876: Use SMAP on amd64. I would have thought that this is a simple >> compatibility problem requiring only a port update, except that the same >> kernel and acpi_call on different hardware are not affected. On the >> problematic system, the kernel module loads without incident; it is when >> executing ACPI commands, even normally harmless operations such as >> requesting read-only constants, that the system freeze occurs. ACPI >> functionality seems otherwise unaffected. >> >> Kernel debugging console and crash dumps are also broken on this system >> (I suspect due to Intel graphics) however it is an unrelated problem, >> and is only an excuse for my inability to provide any further crash >> information. >> >> Having already bisected to the breaking commit, is there anything else I >> should do to improve the chances this problem gets fixed, or are there >> any hardware compatibility notes I may have missed? Just wondering if we could follow what DFBSD did, and integrate this utility in the base as it seems simple enough, and apparently useful in a lot of cases. From owner-freebsd-current@freebsd.org Wed Sep 12 22:13: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 4A28B109E2F5 for ; Wed, 12 Sep 2018 22:13:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C69F773B62 for ; Wed, 12 Sep 2018 22:13:22 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id w8CMDJLZ078079 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Sep 2018 00:13:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id w8CMDJMU078078; Thu, 13 Sep 2018 00:13:19 +0200 (CEST) (envelope-from marius) Date: Thu, 13 Sep 2018 00:13:19 +0200 From: Marius Strobl To: Jakob Alvermark Cc: FreeBSD Current Subject: Re: SD card reader only works after a suspend/resume Message-ID: <20180912221319.GL21523@alchemy.franken.de> References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> <20180906224108.GA65506@alchemy.franken.de> <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (alchemy.franken.de [0.0.0.0]); Thu, 13 Sep 2018 00:13:20 +0200 (CEST) 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, 12 Sep 2018 22:13:23 -0000 On Fri, Sep 07, 2018 at 04:52:12PM +0200, Jakob Alvermark wrote: > On 9/7/18 12:41 AM, Marius Strobl wrote: > > On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: > >> Hi, > >> > >> > >> I discovered this by chance. > >> > >> The SD card reader in my laptop has never worked, but now I noticed it > >> does after suspending and resuming. > >> > >> The controller is probed and attached on boot: > >> > >> sdhci_acpi1: iomem > >> 0x90a00000-0x90a00fff irq 47 on acpi0 > >> > >> But nothing happens if I put a card in. Unless I suspend and resume: > >> > >> mmc1: on sdhci_acpi1 > >> mmcsd0: 32GB at mmc1 > >> 50.0MHz/4bit/65535-block > >> > >> Then I can remove and replug cards and it seems to work just fine. > > I believe that making SD card insertion/removal with the integrated > > SDHCI controlers of newer Intel SoCs work out-of-the-box requires > > support for ACPI GPE interrupts and ACPI GPIO events respectively to > > be added to FreeBSD. Otherwise insertion/removal interrutps/events > > aren't reported and polling the card present state doesn't generally > > work as a workaround with these controllers either, unfortunately. > > I'm not aware of anyone working on the former, though. > > > > Polling the card present state happens to work one time after SDHCI > > initialization with these controllers which is why a card will be > > attached when inserted as part of a suspend/resume cycle (resume of > > mmc(4) had some bugs until some months ago, which probably explains > > why that procedure hasn't worked as a workaround for you in the past). > > Inserting the card before boot, unloading/loading sdhci_acpi.ko or > > triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow > > to attach a card, too. > > > If a card is inserted before booting it is not detected. > > Removing and inserting card after boot is not detected unless I suspend > and resume. > > After I have suspended and resumed once, cards are detected. Removals > and insertions are detected as they happen. Okay, then you are seeing somewhat different behavior than I do. What SoC model is this? Are you loading a GPIO controller driver such as bytgpio(4) or chvgpio(4)? Doing so might be sufficient to kick ACPI GPIO events into working but would be missing dependency information between drivers (which might explain what you are experiencing if sdhci_acpi1 attaches first) and some other bits to do it properly. Also, could you please try whether doing a suspend/resume cycle of sdhci_acpi1 via devctl(8) only kicks the card detection into working? That test should indicate whether the firmware plays a role in making the latter work. Marius From owner-freebsd-current@freebsd.org Wed Sep 12 23:46: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 4D98310A00D7 for ; Wed, 12 Sep 2018 23:46:49 +0000 (UTC) (envelope-from lev@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 E862A77D10 for ; Wed, 12 Sep 2018 23:46:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id AD36F10A00D4; Wed, 12 Sep 2018 23:46: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 9BE2610A00D2 for ; Wed, 12 Sep 2018 23:46:48 +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 3E25777D0C; Wed, 12 Sep 2018 23:46:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd86:f15a:5ec9:e91e]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 175197BC; Thu, 13 Sep 2018 02:46:47 +0300 (MSK) Date: Thu, 13 Sep 2018 02:46:46 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <43892083.20180913024646@serebryakov.spb.ru> To: current@FreeBSD.org CC: brnrd@FreeBSD.org, jkim@FreeBSD.org Subject: Speed problems with both system openssl and security/openssl-devel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 12 Sep 2018 23:46:49 -0000 Hello Brnrd, I'm benchmarking new hardware (rather limited one, but still) which supports AES-NI (Celeron J3160). I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed -evp aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug options turned off) and Debian Linux 9.5.0 booted from install DVD (without installation). Simple "openssl speed aes-256-cbc" shows same numbers both in single-threaded and multi-threaded mode (for all 4 cores). Linux is marginally faster, but it is in the margin of measurement error. But "openssl speed -evp aes-256-cbc" gives me very disappointing results. FreeBSD's openssl is WAY slower than Linux one. It is even slower than non-evp mode for small blocks. Here are results (As reported by openssl, with fractions dropped): Lin 18942 20637 21300 57967 58769 58769 Free 18931 20591 21282 58342 58731 58779 Lin-evp 97049 151466 183905 194385 197514 197727 Free-evp 2838 10845 35362 81892 131264 137579 Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl (1.0.2p) and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), results are virtually the same. I have "ASM" and "SSE2" options enabled in port. What happens here? Why does FreeBSD's build of openssl use AES-NI so inefficient? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Sep 13 03:32: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 E15E710A3D9B for ; Thu, 13 Sep 2018 03:32:49 +0000 (UTC) (envelope-from kob6558@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 6AB367D98B for ; Thu, 13 Sep 2018 03:32:49 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2EFD610A3D8D; Thu, 13 Sep 2018 03:32: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 0D11010A3D8C for ; Thu, 13 Sep 2018 03:32:49 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 928887D985; Thu, 13 Sep 2018 03:32:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id l82-v6so7963381oih.11; Wed, 12 Sep 2018 20:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eCu1sHS15gdldwyaJkJ+HTT4dL7qtulwWdJ4ovKy6Js=; b=Ztc6bmxPJPAY80Wq5fD5rLifw7HiO+h0xMXZe+k6F00sNbpqbCDwdFCVowmPdes4ay U7Xb+qGEO9NIjmIHxxv2FmD7zELeMNedBXKq7+THih3ytpNw50qWSfI0W2bmSvrv1sqJ G4rrBkbBiTlpxPkuHDY1gJP8ksct0hukN7QYTvIgTeMSwiL8bxy8bcdC9sKKoJQMG6Xs YCVjTE5Zv1zV236Wu3/LyFkW0wQwQB0qyCwWKGQ5jnWr/eqbi8rHYnmBIkOyfWSGl4yi yQIPrRvT5b3ZJeIbJvkeDM7WmlRiInb61dmiaW/s475bS9VkQmF+mF1QCbnVX/ZiREMm M5kQ== 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=eCu1sHS15gdldwyaJkJ+HTT4dL7qtulwWdJ4ovKy6Js=; b=i5rgU70tvlSSeULhKSdN9Ljflsj2vYQEcOB1BmbtV5gMrvh0kcOtTd1LSA/9+26KFK GnIbo09JRyy3E9Qct1bmvjlK/GfutU7rF4rPYBrFHrmHhQw1G90/6zF8AKOsBeQKKDpr h3oauKIAK9GpFtqcVZ2tLHToQbh34p293Zc7wCw0kz8tLL3eok+MWwmDEzjBx2voFZGo t/81oPlW0tJqTMShVl+EOV1fBBNbZhJmA08atXYejuxG5YRuvRksAJpDz0xjiFDA8PCF DmtZ1p7Vrl0NpiqaxJhjAJDskY+6FkSW+PikObLJLDay2U8+VcbDojOsKHiHCaTM+NJf 2hqg== X-Gm-Message-State: APzg51Blf5YhuCC1WH89LIuQvszZaY36UrCN95GO+jAHY7Y10Ymw9O6P NZeZpe13s8VjIJmDZtfVFf+QG/PTU9smKUQ/PJB4Nj8k X-Google-Smtp-Source: ANB0VdYIW6+StbTR3aqV83fL/k/2BVyIi+R6M57PyFJtednf+D1rgybQ43/kk2a3CAjvyjksEkAgedv6stRAglYIou4= X-Received: by 2002:aca:6206:: with SMTP id w6-v6mr5608424oib.201.1536809567370; Wed, 12 Sep 2018 20:32:47 -0700 (PDT) MIME-Version: 1.0 References: <43892083.20180913024646@serebryakov.spb.ru> In-Reply-To: <43892083.20180913024646@serebryakov.spb.ru> From: Kevin Oberman Date: Wed, 12 Sep 2018 20:32:30 -0700 Message-ID: Subject: Re: Speed problems with both system openssl and security/openssl-devel To: Lev Serebryakov Cc: current , brnrd@freebsd.org, Jung-uk Kim 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: Thu, 13 Sep 2018 03:32:50 -0000 On Wed, Sep 12, 2018 at 4:48 PM Lev Serebryakov wrote: > Hello Brnrd, > > I'm benchmarking new hardware (rather limited one, but still) which > supports AES-NI (Celeron J3160). > > I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed -evp > aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug options > turned off) and Debian Linux 9.5.0 booted from install DVD (without > installation). > > Simple "openssl speed aes-256-cbc" shows same numbers both in > single-threaded and multi-threaded mode (for all 4 cores). Linux is > marginally faster, > but it is in the margin of measurement error. > > But "openssl speed -evp aes-256-cbc" gives me very disappointing results. > FreeBSD's openssl is WAY slower than Linux one. It is even slower than > non-evp mode for small blocks. > > Here are results (As reported by openssl, with fractions dropped): > > Lin 18942 20637 21300 57967 58769 58769 > Free 18931 20591 21282 58342 58731 58779 > Lin-evp 97049 151466 183905 194385 197514 197727 > Free-evp 2838 10845 35362 81892 131264 137579 > > Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl > (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), > results are > virtually the same. I have "ASM" and "SSE2" options enabled in port. > > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? > > -- > Best regards, > Lev mailto:lev@FreeBSD.org This is probably not the issue, but aesni is not in the GENERIC kernel. Are you sure aesni.ko is loaded? % kldstat | grep aesni If not found, "kldload aesni" and add aesni_load="YES" to /boot/loader.conf -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Thu Sep 13 08:27: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 E461210A9D2D for ; Thu, 13 Sep 2018 08:27:51 +0000 (UTC) (envelope-from lev@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 891688657D for ; Thu, 13 Sep 2018 08:27:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4E63D10A9D2C; Thu, 13 Sep 2018 08:27:51 +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 3CF6210A9D2B for ; Thu, 13 Sep 2018 08:27:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id C9A408657A; Thu, 13 Sep 2018 08:27:50 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:f5fa:1c0c:fd38:95e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 163F8801; Thu, 13 Sep 2018 11:27:43 +0300 (MSK) Date: Thu, 13 Sep 2018 11:27:42 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <7316152.20180913112742@serebryakov.spb.ru> To: Kevin Oberman CC: current , brnrd@freebsd.org, Jung-uk Kim Subject: Re: Speed problems with both system openssl and security/openssl-devel In-Reply-To: References: <43892083.20180913024646@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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, 13 Sep 2018 08:27:52 -0000 SGVsbG8gS2V2aW4sDQoNClRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTgsIDY6MzI6MzAg QU0sIHlvdSB3cm90ZToNCg0KDQo+IFRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBpc3N1ZSwg YnV0IGFlc25pIGlzIG5vdCBpbiB0aGUgR0VORVJJQyBrZXJuZWwuwqAgQXJlIHlvdSBzdXJl IGFlc25pLmtvIGlzIGxvYWRlZD8NCj4gJSBrbGRzdGF0IHwgZ3JlcCBhZXNuaQ0KIEknbSBu b3QgdXNpbmcgbW9kdWxlcywgYXMgaXQgaXMgTmFub0JTRCBpbWFnZSBidWlsZCBmb3IgbWlu aW1hbCBzaXplIGFudA0KbWF4aW1hbCBlZmZpY2llbmN5LiBCdXQgSSBoYXZlIGFlc25pIGlu IG15IGtlcm5lbCBjb25maWcgZm9yIHN1cmU6DQoNCiUgZ3JlcCBhZXNuaSB+L25hbm9ic2Qv Z2F0ZXZheS52My9KMzE2MA0KZGV2aWNlICAgICAgIGFlc25pDQolDQoNCi0tIA0KQmVzdCBy ZWdhcmRzLA0KIExldiAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYWlsdG86bGV2QEZy ZWVCU0Qub3Jn From owner-freebsd-current@freebsd.org Thu Sep 13 08:52:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4048A1080E8E for ; Thu, 13 Sep 2018 08:52:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D385B8814E for ; Thu, 13 Sep 2018 08:52:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 98B3F1080E8C; Thu, 13 Sep 2018 08:52:23 +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 85A8F1080E8B for ; Thu, 13 Sep 2018 08:52:23 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19D3088146; Thu, 13 Sep 2018 08:52:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [10.10.158.185] (unknown [185.93.6.11]) (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 B55ED4EFFF; Thu, 13 Sep 2018 10:52:15 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C35844C2-83C7-44A3-A1C9-18AC804D6715"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Speed problems with both system openssl and security/openssl-devel Date: Thu, 13 Sep 2018 10:52:08 +0200 In-Reply-To: <43892083.20180913024646@serebryakov.spb.ru> Cc: current@FreeBSD.org, brnrd@FreeBSD.org, jkim@FreeBSD.org To: Lev Serebryakov References: <43892083.20180913024646@serebryakov.spb.ru> 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, 13 Sep 2018 08:52:24 -0000 --Apple-Mail=_C35844C2-83C7-44A3-A1C9-18AC804D6715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Sep 2018, at 01:46, Lev Serebryakov wrote: >=20 > I'm benchmarking new hardware (rather limited one, but still) which > supports AES-NI (Celeron J3160). >=20 > I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed = -evp > aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug = options > turned off) and Debian Linux 9.5.0 booted from install DVD (without > installation). >=20 > Simple "openssl speed aes-256-cbc" shows same numbers both in > single-threaded and multi-threaded mode (for all 4 cores). Linux is = marginally faster, > but it is in the margin of measurement error. >=20 > But "openssl speed -evp aes-256-cbc" gives me very disappointing = results. > FreeBSD's openssl is WAY slower than Linux one. It is even slower than > non-evp mode for small blocks. >=20 > Here are results (As reported by openssl, with fractions dropped): >=20 > Lin 18942 20637 21300 57967 58769 58769 > Free 18931 20591 21282 58342 58731 58779 > Lin-evp 97049 151466 183905 194385 197514 197727 > Free-evp 2838 10845 35362 81892 131264 137579 >=20 > Linux have openssl 1.1.0f, and I've tried both system = /usr/bin/openssl (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), = results are > virtually the same. I have "ASM" and "SSE2" options enabled in port. >=20 > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? I can't reproduce your findings, at least not on a Core i7-4790K: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes FreeBSD 93454 89077 117328 281016 285456 Ubuntu 93405 88892 114192 122346 120266 FreeBSD-evp 633283 688010 700775 701168 700669 Ubuntu-evp 623889 681075 697211 700505 698460 That was with base openssl 1.0.2p on FreeBSD 12-ALPHA5, and 1.1.0g on Ubuntu 18.04. -Dimitry --Apple-Mail=_C35844C2-83C7-44A3-A1C9-18AC804D6715 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW5olOAAKCRCwXqMKLiCW o/ydAKCCkZKk7NLRwrHC9zybjRVjK8aSkQCfUeG58R6ezFosk0r+YUEBuXEDiPw= =DF2O -----END PGP SIGNATURE----- --Apple-Mail=_C35844C2-83C7-44A3-A1C9-18AC804D6715-- From owner-freebsd-current@freebsd.org Thu Sep 13 09:18: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 1F8B21081C3B for ; Thu, 13 Sep 2018 09:18:36 +0000 (UTC) (envelope-from lev@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 B896088EF7 for ; Thu, 13 Sep 2018 09:18:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7DF131081C3A; Thu, 13 Sep 2018 09:18:35 +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 6CBA81081C39 for ; Thu, 13 Sep 2018 09:18:35 +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 0C75888EF2; Thu, 13 Sep 2018 09:18:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:f5fa:1c0c:fd38:95e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id AFBE2818; Thu, 13 Sep 2018 12:18:33 +0300 (MSK) Date: Thu, 13 Sep 2018 12:18:32 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1108637790.20180913121832@serebryakov.spb.ru> To: Dimitry Andric CC: current@FreeBSD.org, brnrd@FreeBSD.org, jkim@FreeBSD.org Subject: Re: Speed problems with both system openssl and security/openssl-devel In-Reply-To: References: <43892083.20180913024646@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2018 09:18:36 -0000 Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: I can not reproduce it on E3-1220v3 + 11-STABLE either. But security/openssl111 works as expected on J3160 and it bothers me. Something is wrong not with hardware, but with software here. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Sep 13 09:21: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 7330E1082028 for ; Thu, 13 Sep 2018 09:21:29 +0000 (UTC) (envelope-from lev@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 18871893A7 for ; Thu, 13 Sep 2018 09:21:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D1FEF1082027; Thu, 13 Sep 2018 09:21:28 +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 C0AF81082025 for ; Thu, 13 Sep 2018 09:21:28 +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 65F18893A0; Thu, 13 Sep 2018 09:21:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:f5fa:1c0c:fd38:95e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id A8F1481C; Thu, 13 Sep 2018 12:21:27 +0300 (MSK) Date: Thu, 13 Sep 2018 12:21:27 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <205887838.20180913122127@serebryakov.spb.ru> To: Dimitry Andric CC: current@FreeBSD.org, brnrd@FreeBSD.org, jkim@FreeBSD.org Subject: Re: Speed problems with both system openssl and security/openssl-devel In-Reply-To: References: <43892083.20180913024646@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2018 09:21:29 -0000 Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > FreeBSD 93454 89077 117328 281016 285456 > Ubuntu 93405 88892 114192 122346 120266 > FreeBSD-evp 633283 688010 700775 701168 700669 > Ubuntu-evp 623889 681075 697211 700505 698460 > That was with base openssl 1.0.2p on FreeBSD 12-ALPHA5, and 1.1.0g on > Ubuntu 18.04. Here are additional numbers on J3160, with security/openssl111 port added: Lin 1.1.0f 18942 20637 21300 57967 58769 58769 Free 1.0.2p 18938 20627 21243 57940 58785 Free 1.1.0i 18929 20593 21285 58287 58766 58751 Free 1.1.1 18936 20588 21266 57923 58690 58731 Lin-evp 1.1.0f 97049 151466 183905 194385 197514 197727 Free-evp 1.0.2p 2828 10665 35364 81836 130502 Free-evp 1.1.0i 2869 10813 34932 81292 131308 137376 Free-evp 1.1.1 96959 151359 183390 194431 197076 197686 I've checked poudriere logs, all ports are built with -DAES_ASM. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Sep 13 06:52: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 2489210A77B8 for ; Thu, 13 Sep 2018 06:52:33 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from mail.anongoth.pl (mail.anongoth.pl [46.248.190.61]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anongoth.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A464E82DCB for ; Thu, 13 Sep 2018 06:52:32 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from anongoth.pl (unknown [10.8.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pkubaj", Issuer "anongoth.pl" (not verified)) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id AB6762E063 for ; Thu, 13 Sep 2018 08:52:20 +0200 (CEST) Date: Thu, 13 Sep 2018 08:52:20 +0200 From: Piotr Kubaj To: freebsd-current@freebsd.org Subject: Error when compiling lang/qt5-qml on today's CURRENT Message-ID: <20180913065220.GD15657@smtp.iq.pl> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0/kgSOzhNoDC5T3a" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailman-Approved-At: Thu, 13 Sep 2018 10:02:14 +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: Thu, 13 Sep 2018 06:52:33 -0000 --0/kgSOzhNoDC5T3a Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --- .obj/qv4jit.o --- c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/qv4jit-c801df.cpp c++: note: diagnostic msg: /tmp/qv4jit-c801df.sh c++: note: diagnostic msg: ******************** --- .obj/OSAllocatorPosix.o --- --- .obj/qv4jit.o --- *** [.obj/qv4jit.o] Error code 254 make[3]: stopped in /tmp/usr/ports/lang/qt5-qml/work/qtdeclarative-everywhe= re-src-5.11.1/src/qml When I run /tmp/qv4jit-c801df.sh, I get: Assertion failed: (TRI && "LivePhysRegs is not initialized."), function add= Reg, file /usr/src/contrib/llvm/include/llvm/CodeGen/LivePhysRegs.h, line 80. Abort trap (core dumped) make.conf: BOOT_COMCONSOLE_SPEED=3D115200 BOOT_COMCONSOLE_PORT=3D"0x2f8" CPUTYPE?=3Dnative DEVELOPER=3Dyes DISTDIR=3D/tmp DEFAULT_VERSIONS=3D mysql=3D102m php=3D72 linux=3Dc7_64 pgsql=3D10 ruby=3D= 2.5 python=3D3.6 ssl=3Dlibressl-devel DWM_CONF=3D/usr/ports/x11-wm/dwm/files/config.h ST_CONF=3D/usr/ports/x11/sterm/files/config.h WRKDIRPREFIX=3D/tmp When I remove CPUTYPE, it happens as well. --=20 ______________________________________=20 / There is nothing wrong with Southern \ | California that a rise in the ocean | | level wouldn't cure. | | | \ -- Ross MacDonald / --------------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --0/kgSOzhNoDC5T3a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJkBAABCgBOFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAluaCSQwFIAAAAAAFQAS cGthLWFkZHJlc3NAZ251cGcub3JncGt1YmFqQGFub25nb3RoLnBsAAoJEHpZm4Ug g5ydi+IQAInsZjSLTaYGZSpYn0woQ0QLBdGWqNs1LFckgWPs8ParacmkECjvBpZ/ LxhZL7aFKpMKj4Y+PWiZ3rTOFVub4M4ewNJJnFNFEiLoDKqjUYBJBvmRThypYVq0 G43MAuJSBawBW4GbaP2i1/tO98IOyI3OZVTDllORcWjQ48TMy8HFkwp5Gcmur3qf 0Nh/QjI6HKya0mHjM7g6LpMyGC0f2oT3xwiEg5KWUj4gOoRLQ+9IdWMH3Ya7JPtS pvubdmbopxnBUW64iaN7P+ZBVkpCJRGBBDP+q1CJSp/i9ht6/R+CsA6Kw1i+rnke vAotVkuF8K1nCpzK7C6+uyLMbhvgw98ZAVe/45U+rEh4vEeKvDMsdSoqjh7o47tH v9lwfiMH0u9u05HVYRm+eJygEFi/h585y+IetRAZOcjxAyB1CRyuBrJWS+vPZVrf PzTN7x5lXwPJAe3S9LAb0VhsXf5y+TQdS9Y6gVa9itDl/xgtV4zYrANJ0zvz6RV1 3gdMuO9zrhS8/5H0ZvxRe5PxA8BqZRipKy38SlwEbqqEXHMe2mqi2bjQMm9+Qz5s Gi/xS8QzVWHENVuf0il6JJD4532QU016iGzhxcNdN7zQ3XpUkhbeVJX+KombbRgk waJDxAXamTKQrMoRC302vYnn06GsyhHMVbxih/OOYa/nr4q9Yith =tUyE -----END PGP SIGNATURE----- --0/kgSOzhNoDC5T3a-- From owner-freebsd-current@freebsd.org Thu Sep 13 10:32:14 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 C62D5108966F for ; Thu, 13 Sep 2018 10:32:13 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4796D8BCCF for ; Thu, 13 Sep 2018 10:32:12 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback9g.mail.yandex.net (mxback9g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:170]) by forward105o.mail.yandex.net (Yandex) with ESMTP id BA81A44469AF; Thu, 13 Sep 2018 13:31:58 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback9g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id S8gBVR889b-VwFijM7S; Thu, 13 Sep 2018 13:31:58 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1536834718; bh=iKTpOv8skxS8nqhEENeBU+OaxSCieRLzoTEWJ8/gZnA=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=nXT/Q8qNxYakr6FVArg+46QV/xrcsXe3Z4TDFgxv28UXqka+S0eTZRpHAWcCZLp++ pgIO57/Vqw8SItVMoEnnGJ2IhGWX0++zxn1hZstgAX+D9u5SL+U3U/seUQH4aDkIZY Iypa78gC+/UJKAch2IGOy/280Q2uwJXnAJGYEP4Q= Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ym5WbPAhk8-VvgGDE14; Thu, 13 Sep 2018 13:31:57 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1536834717; bh=iKTpOv8skxS8nqhEENeBU+OaxSCieRLzoTEWJ8/gZnA=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=fWxzyT9URrtp3HR404fKCdn9M4qThqplYZ7WqfwYAoPll58PpNduvW14EdUPlVIDb 4k5zfCR6edKnPL71OAIgVYFSpCshLcAU4ZQd4+C2FoSKbFqF1yzHgxUgQA6tphfroK EsrOZ9zTD5L/xlikIFFwGhI73pMBlnunZTgmhpXI= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: make packages fails recent -current To: Andreas Nilsson , mikael.urankar@gmail.com Cc: Current FreeBSD References: From: Boris Samorodov Message-ID: <7743a7e2-351d-9438-a713-7b55748e2c10@passap.ru> Date: Thu, 13 Sep 2018 13:31:57 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-English 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: Thu, 13 Sep 2018 10:32:14 -0000 On 11.09.2018 16:20, Andreas Nilsson wrote: > On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar > wrote: > >> 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : >> >>> Hello, >>> >>> I have for about a week been trying to get new (base)packages built. make >>> buildworld/buildkernel works as expected, however make packages has been >>> failing: >>> >>> ===> Creating FreeBSD-runtime-12.0.s20180910124534 >>> pkg: duplicate directory listing: /boot, ignoring >>> pkg: duplicate directory listing: /etc, ignoring >>> ... >>> pkg: duplicate directory listing: /etc/syslog.d, ignoring >>> pkg: duplicate directory listing: /root, ignoring >>> pkg: duplicate directory listing: /root, ignoring >>> pkg: duplicate directory listing: /root, ignoring >>> pkg: Plist error, @config /root/.cshrc: not a regular file >>> pkg: Plist error, @config /root/.profile: not a regular file >>> pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring >>> pkg: duplicate directory listing: /usr/lib, ignoring >>> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring >>> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring >>> pkg: duplicate directory listing: /usr/lib32, ignoring >>> ... >>> >>> Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode >>> for >>> building. I'm currently building from scratch just to rule out metamode. >>> >> >> See >> https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html >> > > Thanks, that would explain it. Although even after installing > pkg-devel-1.10.99.8 it still fails. Guess I'll have to wait for it to > trickle into the packages. The rev. 479255 was an update to version 1.10.99.9. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serv From owner-freebsd-current@freebsd.org Thu Sep 13 13:18: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 2615A108D7D5 for ; Thu, 13 Sep 2018 13:18:38 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 C91CD705F0; Thu, 13 Sep 2018 13:18:37 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 9C9405646F; Thu, 13 Sep 2018 08:18:36 -0500 (CDT) To: freebsd-current , markj@FreeBSD.org From: Eric van Gyzen Subject: arc_reclaim_thread running hot Message-ID: <0cdba37f-6b47-0929-fb72-dcca7e70a05a@vangyzen.net> Date: Thu, 13 Sep 2018 08:18:17 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.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: Thu, 13 Sep 2018 13:18:38 -0000 This morning, I found the arc_reclaim_thread running hot on my laptop running 12.0-ALPHA5 r338572. vfs.zfs.arc_max="4294967296" <-- 4 GiB last pid: 13288; load averages: 1.32, 1.26, 1.16 Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other 89M Compressed, 361M Uncompressed, 4.03:1 Ratio 22 root -8 - 0 256K CPU2 2 309:20 99.75% zfskern{arc_reclaim_thread} zfs_arc_meta_strategy is still the default of 1. I sampled the thread's stacks with for N in `jot 1000`; do procstat -kk 100101; done | grep 100101 and put the results here: https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt I'm happy to help debug this. Just let me know what you need. Eric From owner-freebsd-current@freebsd.org Thu Sep 13 15:06: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 25B4A1090677 for ; Thu, 13 Sep 2018 15:06:10 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A3974EC7; Thu, 13 Sep 2018 15:06:09 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-yw1-xc2a.google.com with SMTP id x83-v6so1285011ywd.4; Thu, 13 Sep 2018 08:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QzvpVB2MHHTix4Bm2rW0OSmG1O10qQ00VM7h3Mb5j18=; b=V6XioMhyyLUoxMq8bXC+xclTYHZzkXBYodS5rkStNfIttKE9cY/6Xt9M9TIprVUY8t tYlxA/ueGhEr5Ov+1q5pzcH6dAJrGjEIe6ZNK+fNqQAibBe3rNyWRt/3E891uJ04azyd WZwmy9AyswFWwVS8C7kcgA9R2qm/oYmZY+EqzyucdcTf4geV1SgCan+FdDcaCf6aHUtx 3nSrdh5o5GzSkhRWt9j/t6vxO8mCIk0etKNms/v9T0xx17lfkGPQ2waYVSFOxJqrR5P0 9B+baUtgRvCgi4DFQqN+r6ag5rOObiqjyOreSRnDMr8LA/8tWSF85ROFJL6Rzy0CTnVb wPeg== 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=QzvpVB2MHHTix4Bm2rW0OSmG1O10qQ00VM7h3Mb5j18=; b=FFSTG3fjgpVwdNHfZq1vPV2ZlJMmHijAyq9PNysu0G6Us3+Y11cVOM+5A37juLbnU2 H7ysDVCOWcnKdl5z43MpzzyTG/E98c8syFmoLuMs6BKK3K4ds3AIIxAO6Te039/9uTY0 wBzQnUznhKpFp2uXKUZaxR1FmCi72eub0RSpzmiS6HDaFsGRxBfQotbSk1FmB0iMh3Ea lqTPKC46yQND0/ySa2oKLTHiXRmGKdBE7LHUKWogZtoClyA+tBDj7p48tCvBQtwVTu4o m0mO+540CqhPFoeddMmktIOFnO9gAKagdIuhfbuXeLSA23i0tSrTgzTeg1NsTkxqt7px /NlA== X-Gm-Message-State: APzg51CkDibvFGLyWTrQhZnHXYUcBH78ddwrJW4C5iMJlT+TXk7zMeU0 Inx15UonwMt5xn6wkJJVc7KXYskmj4KAt+7F0P8= X-Google-Smtp-Source: ANB0VdaL3h9SQKpUu1k0LONc4d4DVghgw+wUzScgSHW+a1Rp3xwxSncPJo5N8rRFwQJh6a0j3Nc3S7a8eKLeoMQbtv4= X-Received: by 2002:a0d:e707:: with SMTP id q7-v6mr3513033ywe.436.1536851168719; Thu, 13 Sep 2018 08:06:08 -0700 (PDT) MIME-Version: 1.0 References: <0cdba37f-6b47-0929-fb72-dcca7e70a05a@vangyzen.net> In-Reply-To: <0cdba37f-6b47-0929-fb72-dcca7e70a05a@vangyzen.net> From: Daniel Nebdal Date: Thu, 13 Sep 2018 16:14:32 +0200 Message-ID: Subject: Re: arc_reclaim_thread running hot To: eric@vangyzen.net Cc: Current , markj@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: Thu, 13 Sep 2018 15:06:10 -0000 On Thu, 13 Sep 2018 at 15:19, Eric van Gyzen wrote: > > This morning, I found the arc_reclaim_thread running hot on my laptop > running 12.0-ALPHA5 r338572. > > vfs.zfs.arc_max="4294967296" <-- 4 GiB > > last pid: 13288; load averages: 1.32, 1.26, 1.16 > > Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free > ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other > 89M Compressed, 361M Uncompressed, 4.03:1 Ratio > > 22 root -8 - 0 256K CPU2 2 309:20 99.75% > zfskern{arc_reclaim_thread} > > zfs_arc_meta_strategy is still the default of 1. > > I sampled the thread's stacks with > > for N in `jot 1000`; do procstat -kk 100101; done | grep 100101 > > and put the results here: > > https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt > > I'm happy to help debug this. Just let me know what you need. > > Eric Just to summarize, these are the top 15 active (guessing that the leftmost function is "current"): 22 arc_space_return 22 uma_dbg_free 26 uma_dbg_alloc 30 mi_switch 31 uma_zalloc_arg 33 multilist_sublist_lock 34 __mtx_unlock_flags 39 46 _sx_xlock 48 hdr_full_cons 50 uma_zfree_arg 58 aggsum_add 91 arc_adjust 156 _sx_xunlock 185 arc_evict_state And the top 15 in total (that is, no matter where in the call stack): 44 multilist_sublist_lock 44 uma_dbg_free 46 _sx_xlock 47 uma_dbg_alloc 61 arc_space_return 127 aggsum_add 139 hdr_full_cons 156 _sx_xunlock 211 uma_zfree_arg 219 uma_zalloc_arg 833 arc_evict_state 926 arc_adjust 961 arc_reclaim_thread 961 fork_exit 961 fork_trampoline (I have nothing sensible to add about the actual problem.) -- Daniel Nebdal From owner-freebsd-current@freebsd.org Thu Sep 13 15:11: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 1D6731090A11 for ; Thu, 13 Sep 2018 15:11:41 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 C2E81752E8; Thu, 13 Sep 2018 15:11:40 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 3DFA55646F; Thu, 13 Sep 2018 10:11:33 -0500 (CDT) Subject: Re: arc_reclaim_thread running hot From: Eric van Gyzen To: freebsd-current , markj@FreeBSD.org References: <0cdba37f-6b47-0929-fb72-dcca7e70a05a@vangyzen.net> Message-ID: <064f770e-e035-d3a3-c138-54e3f667a9be@vangyzen.net> Date: Thu, 13 Sep 2018 10:11:26 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <0cdba37f-6b47-0929-fb72-dcca7e70a05a@vangyzen.net> 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: Thu, 13 Sep 2018 15:11:41 -0000 On 9/13/18 8:18 AM, Eric van Gyzen wrote: > This morning, I found the arc_reclaim_thread running hot on my laptop > running 12.0-ALPHA5 r338572. > > vfs.zfs.arc_max="4294967296"  <-- 4 GiB > > last pid: 13288;  load averages:  1.32,  1.26,  1.16 > Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free > ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other >      89M Compressed, 361M Uncompressed, 4.03:1 Ratio > >    22 root         -8    -      0   256K CPU2     2 309:20  99.75% > zfskern{arc_reclaim_thread} > > zfs_arc_meta_strategy is still the default of 1. > > I sampled the thread's stacks with > > for N in `jot 1000`; do procstat -kk 100101; done | grep 100101 > > and put the results here: > > https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt > > I'm happy to help debug this.  Just let me know what you need. The thread eventually returned to normal, and I've rebooted the system since then, so I no longer have any state. The thread started running hot at 03:00, so maybe the daily periodic run triggered it. I have to work now, but I'll try running the periodic stuff manually when I have time. Eric From owner-freebsd-current@freebsd.org Thu Sep 13 15:12: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 260611090A43 for ; Thu, 13 Sep 2018 15:12:21 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB787753CB for ; Thu, 13 Sep 2018 15:12:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [10.10.158.185] (unknown [185.93.6.11]) (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 C0D534F037; Thu, 13 Sep 2018 17:12:18 +0200 (CEST) From: Dimitry Andric Message-Id: <406F751D-78F7-4E25-91FC-CCE1151FF9CB@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1437F324-A180-41C4-97AB-A80DC3A29891"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Error when compiling lang/qt5-qml on today's CURRENT Date: Thu, 13 Sep 2018 17:12:14 +0200 In-Reply-To: <20180913065220.GD15657@smtp.iq.pl> Cc: freebsd-current@freebsd.org To: Piotr Kubaj References: <20180913065220.GD15657@smtp.iq.pl> 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, 13 Sep 2018 15:12:21 -0000 --Apple-Mail=_1437F324-A180-41C4-97AB-A80DC3A29891 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Sep 2018, at 08:52, Piotr Kubaj wrote: >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/qv4jit-c801df.cpp > c++: note: diagnostic msg: /tmp/qv4jit-c801df.sh > c++: note: diagnostic msg: >=20 > ******************** > --- .obj/OSAllocatorPosix.o --- > --- .obj/qv4jit.o --- > *** [.obj/qv4jit.o] Error code 254 >=20 > make[3]: stopped in = /tmp/usr/ports/lang/qt5-qml/work/qtdeclarative-everywhere-src-5.11.1/src/q= ml >=20 > When I run /tmp/qv4jit-c801df.sh, I get: > Assertion failed: (TRI && "LivePhysRegs is not initialized."), = function addReg, file = /usr/src/contrib/llvm/include/llvm/CodeGen/LivePhysRegs.h, line > 80. > Abort trap (core dumped) Can you please create a PR, and attach a compressed tarball with qv4jit-c801df.cpp and qv4jit-c801df.sh in it? You can assign the PR to me. -Dimitry --Apple-Mail=_1437F324-A180-41C4-97AB-A80DC3A29891 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW5p+TgAKCRCwXqMKLiCW o3PbAJ99mhADk8ab7nZBg/MO82NRlX000ACfX3k6hoXSmoo61LBYinpO0YX1yt4= =YfEV -----END PGP SIGNATURE----- --Apple-Mail=_1437F324-A180-41C4-97AB-A80DC3A29891-- From owner-freebsd-current@freebsd.org Thu Sep 13 16:11: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 A0BA9109234D for ; Thu, 13 Sep 2018 16:11:30 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 3EB6277843; Thu, 13 Sep 2018 16:11:29 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0UDH-0005fd-KL; Thu, 13 Sep 2018 18:11:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QqI9kef6zXoD04Rc7uulP/uNSQhxbMXhVohW1UlG9nk=; b=FBvhUbYegiDfRVMv/0aYzS/6Tk d91halCH8nkwy/ozlM8GrXwlDLYp0nGBozau+gN+8xpjkCLh9HXAGLNrrxE4/BzO8nlWXSmifay8q 0k1iYWQzxER7hrF8/V5rX9UJd8gtJay+4m30PMu0tM9Mj4p7pVDRWSGzF9bhOfIKhmw0+Q1H0iXil TOHlJpXEsYTmni2Zhs7fn9ju0OR35VdSGvSjFCIdGEoN5HgrYYW5fVkyKAUiYcgRmYyCS301bky2L gbONs/LUE8sD2tgVWtLVygq3jd1sUlL0t2IDY31U+xhhiQYt+wAiptktTwQqkeT82is0Ex/HVTVLM 5W4rD4zA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0UDH-000MY3-3i; Thu, 13 Sep 2018 18:11:27 +0200 From: Jakob Alvermark Subject: Re: SD card reader only works after a suspend/resume To: Marius Strobl Cc: FreeBSD Current References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> <20180906224108.GA65506@alchemy.franken.de> <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> <20180912221319.GL21523@alchemy.franken.de> Message-ID: Date: Thu, 13 Sep 2018 18:11:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180912221319.GL21523@alchemy.franken.de> 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, 13 Sep 2018 16:11:30 -0000 On 9/13/18 12:13 AM, Marius Strobl wrote: > On Fri, Sep 07, 2018 at 04:52:12PM +0200, Jakob Alvermark wrote: >> On 9/7/18 12:41 AM, Marius Strobl wrote: >>> On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: >>>> Hi, >>>> >>>> >>>> I discovered this by chance. >>>> >>>> The SD card reader in my laptop has never worked, but now I noticed it >>>> does after suspending and resuming. >>>> >>>> The controller is probed and attached on boot: >>>> >>>> sdhci_acpi1: iomem >>>> 0x90a00000-0x90a00fff irq 47 on acpi0 >>>> >>>> But nothing happens if I put a card in. Unless I suspend and resume: >>>> >>>> mmc1: on sdhci_acpi1 >>>> mmcsd0: 32GB at mmc1 >>>> 50.0MHz/4bit/65535-block >>>> >>>> Then I can remove and replug cards and it seems to work just fine. >>> I believe that making SD card insertion/removal with the integrated >>> SDHCI controlers of newer Intel SoCs work out-of-the-box requires >>> support for ACPI GPE interrupts and ACPI GPIO events respectively to >>> be added to FreeBSD. Otherwise insertion/removal interrutps/events >>> aren't reported and polling the card present state doesn't generally >>> work as a workaround with these controllers either, unfortunately. >>> I'm not aware of anyone working on the former, though. >>> >>> Polling the card present state happens to work one time after SDHCI >>> initialization with these controllers which is why a card will be >>> attached when inserted as part of a suspend/resume cycle (resume of >>> mmc(4) had some bugs until some months ago, which probably explains >>> why that procedure hasn't worked as a workaround for you in the past). >>> Inserting the card before boot, unloading/loading sdhci_acpi.ko or >>> triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow >>> to attach a card, too. >> If a card is inserted before booting it is not detected. >> >> Removing and inserting card after boot is not detected unless I suspend >> and resume. >> >> After I have suspended and resumed once, cards are detected. Removals >> and insertions are detected as they happen. > Okay, then you are seeing somewhat different behavior than I do. What > SoC model is this? CPU: Intel(R) Pentium(R) CPU  N3540  @ 2.16GHz (2166.73-MHz K8-class CPU) > Are you loading a GPIO controller driver such as > bytgpio(4) or chvgpio(4)? Doing so might be sufficient to kick ACPI > GPIO events into working but would be missing dependency information > between drivers (which might explain what you are experiencing if > sdhci_acpi1 attaches first) and some other bits to do it properly. I have bytgpio_load="YES" in /boot/loader.conf But I tried removing it, doesn't change the behavior. With or without the bytgpio driver, inserting or removing cards is only detected after a suspend/resume cycle of the computer. > Also, could you please try whether doing a suspend/resume cycle of > sdhci_acpi1 via devctl(8) only kicks the card detection into working? > That test should indicate whether the firmware plays a role in making > the latter work. Tried that. devctl suspend sdhci_acpi1 devctl resume sdhci_acpi1 Doesn't make any difference. Also tried devctl disable/enable. No change. Jakob From owner-freebsd-current@freebsd.org Thu Sep 13 18:08: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 498FC10952FC for ; Thu, 13 Sep 2018 18:08:17 +0000 (UTC) (envelope-from billprofane@gmail.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEB6F7C579 for ; Thu, 13 Sep 2018 18:08:16 +0000 (UTC) (envelope-from billprofane@gmail.com) Received: by mail-pg1-x52b.google.com with SMTP id s7-v6so3126373pgc.0 for ; Thu, 13 Sep 2018 11:08:16 -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=8cj1n/xbdW8V8+w2jA2gSo7ayXFitbTxN2kmirIL4UM=; b=Dxn9AsOpOJAyuB8JPWVSD/4uAYZVgmzuvJTwceS9sQdv2aDCn4CMq6wS8m8bHy6p7E l+P1TMW83+XA954UCZbBXBf3h7W1PctFiDFAmz4FQjuEuT+x8UvBf5ad/1g1aOQT1co8 SyKWB4y96cp8ieKAArUuQ+KDLpKgCVdKbid/65gBdHv3D//HxrO6WCT57gA/5Y3vGqaN pUZymVtOma3G1Wi0QCX3nmofP65UzW2h2/yNQW9oQGOWSWPA36AmZUxi8yOaPrfB0GBE xkERSGdPRZD+ontmhVJCzMJ4pwr5mtskqcEqb53kcNPrB0n9MSHRRbtVroyk/H6uUiq7 9glg== 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=8cj1n/xbdW8V8+w2jA2gSo7ayXFitbTxN2kmirIL4UM=; b=L3Gj5omTjow6aAt1Um+hneTI+T5cIQq6Eb+MSRhtrYu0Ed2Yyd1J4EyuQwLXWMZOHl wIDusnmVAY0QojOenN/rgEQqvmvzI5OlLUF9+yqmrcZohsrq0sU/IaLJVk3E8XNKuz55 dC1/aQ45WV/a9F2R15g+o4s0O3yHT+TIDcEvcF3Pfw5yAQytt7PCTEd++SmbUe/7W6rw RmwT9CRb9VVdCDL3QfLjdd0P4Wo7vRb4/lNaA4TDE5Zpuek49Hr4Rjg/usPoloZVd9fn uifM4XbJtjb24d9wjf36hdxbpxAyQ0cJd5NFSKNuJmgniY6FVp7RLJMx8ZHAwgYWuq7c mCmA== X-Gm-Message-State: APzg51AWctJF7LMfx9H2q/Zo1cflSZVXq6/+R7Erir4NLtq4gA+ahcAs eEmnDf9BoMLkCH6ehOXPLgWAAVFpC7xcaQu85OrMFYYk X-Google-Smtp-Source: ANB0Vda/p4iGbo/HgSxM3FLOi6Wp9KtQjTQjKsNSyrmVmz1eKQ1k1DQX89f1V+NB2fWcyGfTRwKF/nhz9fKtdU9MhZs= X-Received: by 2002:a63:1b07:: with SMTP id b7-v6mr8197780pgb.444.1536862095724; Thu, 13 Sep 2018 11:08:15 -0700 (PDT) MIME-Version: 1.0 From: bill profane Date: Thu, 13 Sep 2018 11:08:04 -0700 Message-ID: Subject: Implementing my Quantum data parallization library as a FreeBSD module To: freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 13 Sep 2018 19:05:04 +0000 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: Thu, 13 Sep 2018 18:08:17 -0000 Sorry if this message sounds a little off, I'm on meds But I have a C library that could be of use for bleeding edge BSD distrobutions: The code is hosted at github at https://github.com/unidef/quantum Basically, it implements huge multidimension arrays using pointers and structures, and features a way to move data in and out of the "neuron". Each neuron consists of a data structure that has a pointer to char description and features a broken multidimensional binary tree It's memory intensive for now since there is no code to write data to disk (I'm a little rusty on my C), and broken since I cant figure out #ifdef But it could be of use for the FreeBSD kernel, it follows the BSD license For convenience: git clone https://github.com/unidef/quantum . Sorry again for the crappy and incomplete code, been dealing with medical issues. If this is considered spam, please tell me and I will desist in future posts such as this. Thank you Bill "unidef" Profane From owner-freebsd-current@freebsd.org Thu Sep 13 21:07: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 A8CE7109970D for ; Thu, 13 Sep 2018 21:07:58 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 264E482F70 for ; Thu, 13 Sep 2018 21:07:57 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id w8DL7tr0024235 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Sep 2018 23:07:55 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1536872875; bh=xg1aGI31qbDNKDxfYKm8coi4O6fx414QB63qtUuXcn0=; h=Date:From:To:Subject; b=i6Al6q0opOsjPJH7NQH9vn6uLVN7BXSQErg1xPU1+mvZKVS68uJFTdqHQE5Tvfm5o mNjA6WDs7iH9qieU1MZHY9oEtNjHu0aUZ80AEIdeLaJ4YYMJNz37Uxyp0izvIsnxrM SSwEmyxSZxLipjXPpL/noaIQR8oW4emPCMt3SOypaPipZ6OEhEVYrnUH9nBnWi6NsF Su5e62uN0f883nq/zv86RXKsiw9P0ZoRXVqchdNUwBpp7Qf2Tr6mVSKPsaAiRx3dJ0 lQ4kcJOiKCsud0mULoS7UwRAzFwWu+pZ3Hm7NPvbPcR0oA/ciwI2J6j7NVU5iYGC+D aH/QLXhz14CCg== Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id w8DL7tF2024234 for freebsd-current@freebsd.org; Thu, 13 Sep 2018 23:07:55 +0200 (CEST) (envelope-from zarychtam) Date: Thu, 13 Sep 2018 23:07:55 +0200 From: Marek Zarychta To: freebsd-current@freebsd.org Subject: ntpd user and group missing when upgrading from sources from 11-stable to 12-current Message-ID: <20180913210755.GA23935@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) 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, 13 Sep 2018 21:07:58 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? -- =20 Marek Zarychta --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlua0agACgkQdZ/s//1S jSzzRggAvwobiaiZybtqK38NldxN8wRvlMFwyHuAqqwnoPX7wJEt37oVPv2Dswtb roUCf3sX/nI67XoMijW3ayzr2V/XvqYFGV8D01t+16U6P3yM9Dl7j8csEXMPXoKc NdP/K/MXD8irkBDHGdQFijHxhltaduKA0usXK4gNwC6WuS4zqErkN62/rpoJWV72 3WnZuZsBN9LPudwUA/c0hi2Jejce3EEuNEMoiwAnVyCZBAXiNEVVuASfU6e3nqy8 cywoX26oDxIpauiqYIrRarhDvbAfVoV7tnJXq4t5e9zCrf/yageEpVIszz7EcpJN Mwmvhsdvi2Ao90QO6mQe2PHT3EfPJQ== =sLnf -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@freebsd.org Thu Sep 13 21:16:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3CF01099C1D for ; Thu, 13 Sep 2018 21:16:31 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) (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 63EDE83595 for ; Thu, 13 Sep 2018 21:16:31 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D3EF45646F; Thu, 13 Sep 2018 16:16:29 -0500 (CDT) Subject: Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current To: Marek Zarychta , freebsd-current@freebsd.org References: <20180913210755.GA23935@plan-b.pwste.edu.pl> From: Eric van Gyzen Message-ID: Date: Thu, 13 Sep 2018 16:16:26 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180913210755.GA23935@plan-b.pwste.edu.pl> 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, 13 Sep 2018 21:16:31 -0000 On 9/13/18 4:07 PM, Marek Zarychta wrote: > Dear subscribers, > > stable/12 hasn't been branched yet, so it could be not a bug. Since > r336525 make installworld fails on 11-stable when installing world for > 12-current without ntpd user/group added. Of course, as a workaround > user and group could be added manually. Mergemeaster also fails when it > is run before installworld, what is IMHO predictable and expected > behaviour. So mergemaster will not help with this issue. > > So the question arises, is it a feature or should a PR be submitted? Did you run mergemaster with the -p flag before installworld? Eric From owner-freebsd-current@freebsd.org Thu Sep 13 21:19: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 D237C1099DAB for ; Thu, 13 Sep 2018 21:19:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5940883787 for ; Thu, 13 Sep 2018 21:19:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.203] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 11391b61 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Thu, 13 Sep 2018 14:18:54 -0700 (PDT) Subject: Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current To: Marek Zarychta , freebsd-current@freebsd.org References: <20180913210755.GA23935@plan-b.pwste.edu.pl> From: Pete Wright Message-ID: Date: Thu, 13 Sep 2018 14:18:53 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180913210755.GA23935@plan-b.pwste.edu.pl> 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, 13 Sep 2018 21:19:03 -0000 On 9/13/18 2:07 PM, Marek Zarychta wrote: > Dear subscribers, > > stable/12 hasn't been branched yet, so it could be not a bug. Since > r336525 make installworld fails on 11-stable when installing world for > 12-current without ntpd user/group added. Of course, as a workaround > user and group could be added manually. Mergemeaster also fails when it > is run before installworld, what is IMHO predictable and expected > behaviour. So mergemaster will not help with this issue. > > So the question arises, is it a feature or should a PR be submitted? can you share how you are running mergemaster? i recently upgraded a system from 11.2-RELEASE to 12-CURRENT without issues.  my steps are: make buildkernel make buildworld make installkernel mergemaster -m /path/to/current/checkout -p make installworld mergemaster -m /path/to/current/checkout -a it is critical to run the mergemaster -p before installing the world.  this will prompt you to update your /etc/password and /etc/group tables to add the new ntp user/group.  the same goes for using the mergemaster -a switch after installing the world, as that will ensure that critical configs for rc are updated correctly. cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Thu Sep 13 21:26: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 74CBF109A2BC for ; Thu, 13 Sep 2018 21:26:02 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E132783DE8 for ; Thu, 13 Sep 2018 21:26:01 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id w8DLQ0sV024499 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Sep 2018 23:26:00 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1536873960; bh=0E1wVb9UuuefOAigVl7w2AM16BSv2pIBZe5RX7oSTKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BuMB4eQPETCHPo1lSSigQYI+ButjSfbCl2h8BhhmjyJoGCl0sDGUx+mPHcbZWKM1d E8Qw4tcDca9FBDBi/e6ZrZMzdPbZ5/MTLB9ieuy/KFtnHf3oJwrIbYR0krzQvQ96AI xYEp8VY6RAJv/I8X0Pb2fuycKtRUrafuSLpgiKR2xUG5gUsjoQBupJAcVQVtktCCl/ Hh15QEn6GNXa1ZEG24gwMkI4sXTYP7BMyYoNmMDng9I0RScq6aSzZza/Wq+4pYCg2F OH6eB+2QkyAzSEkDfY9C4fPyBUQGPIzH/qZhjOwPTxzM0pwY9YzhxnAWjC1AXNbilL T07Gv/xV/iF+Q== Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id w8DLQ0Bt024498; Thu, 13 Sep 2018 23:26:00 +0200 (CEST) (envelope-from zarychtam) Date: Thu, 13 Sep 2018 23:26:00 +0200 From: Marek Zarychta To: Eric van Gyzen Cc: freebsd-current@freebsd.org Subject: Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current Message-ID: <20180913212600.GA24368@plan-b.pwste.edu.pl> References: <20180913210755.GA23935@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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, 13 Sep 2018 21:26:02 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 13, 2018 at 04:16:26PM -0500, Eric van Gyzen wrote: > On 9/13/18 4:07 PM, Marek Zarychta wrote: > > Dear subscribers, > >=20 > > stable/12 hasn't been branched yet, so it could be not a bug. Since > > r336525 make installworld fails on 11-stable when installing world for > > 12-current without ntpd user/group added. Of course, as a workaround > > user and group could be added manually. Mergemeaster also fails when it > > is run before installworld, what is IMHO predictable and expected > > behaviour. So mergemaster will not help with this issue. > >=20 > > So the question arises, is it a feature or should a PR be submitted? >=20 > Did you run mergemaster with the -p flag before installworld? >=20 > Eric Thank you for the clue, TBH I didn't use -p flag which was my fault.=20 I am sorry for the needless noise I have made on the list. --=20 Marek Zarychta --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlua1eQACgkQdZ/s//1S jSxJEwgAiWbCNtMXayBoTzD1sBaAM3Jw2POTvXCKKedX5mmRR1rKmHciqNcn+tWT mAGrDZ9aMPkl4HHc/hRRFuqs/hJ9kLYOiM672MuXXqoVcytpZpMi0KC0hwJJtZBC Z3LgOTm7ACyE/LG8Y4zR/JvKwH2sxTmBJWOnoMATW+Bs5MuFDDBVsd9LtFUsil0q kDGQq6/G/r73DnwykRZRQYNlyv6oJcksLzjl0y2184+VeyCsBmd+MfYbKK2LXDR6 jcKhq2GdV+rmxHLqLuBviQobt+W0bRWdqKE4ID9dHxyN7pNH9hAyRLqNwrOBsl10 MGbB3lAlW1mIPMz2Hew50/jxUsLdZw== =Z4DN -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@freebsd.org Thu Sep 13 21:41:56 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 9B7BE109A986 for ; Thu, 13 Sep 2018 21:41:56 +0000 (UTC) (envelope-from billprofane@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 220E1849FF for ; Thu, 13 Sep 2018 21:41:56 +0000 (UTC) (envelope-from billprofane@gmail.com) Received: by mail-pl1-x631.google.com with SMTP id u11-v6so3188530plq.5 for ; Thu, 13 Sep 2018 14:41:56 -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=qOC5pTiO6nklwDfrdLFh+IHlywJQPN7XbFJu3DetnYw=; b=XkmjIUrY/Sj7lGMeEFXD1bpqWTDaRYCvkS+HlZdqgwWyVqZeRUe0NLOW6V5H7h58PF GCHE3qMZ6nNKRieNtqEkroWOEBgNM3Fjl8i719SFEYE+rIVzNZLtQirLEYYAhQapzdWb X02Gz2mRlwlgZVUWRnNwbFMs3ymc6j04Hfn3CJtFl3QuVksDw4BXjftEds10RMBROE5z ov0111QsFTL3zw4CzWW3fvcs+ab/op7ePXAZsGglTGaQgR8EyUH5MOaMwdMUbNoTEsc4 pI1myB21SwCJHtjOo9uj3mGGY1eMcmbUUotNscpvhoc0eXfB3jPyzLeZau48iAnoArvs 4EGA== 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=qOC5pTiO6nklwDfrdLFh+IHlywJQPN7XbFJu3DetnYw=; b=iFitopkn8Jno29IfL8gg29R6K1wAjhTG+6+ymmEBj+Enz+VGU8KWsTC30Z8ZgfuSpG CECd6vfb2P22lh5lxKZdEmbwJ2S0YyF88/azGvFTx//v4l/a13MfRxv1F3IfuADUphBI F+AeZ2h5iTzL08/bASno8r0yTfbisYYlBWfJlTqG0U+xB7a6dLVnKBB/GIiCXjkmYq4i FWOI8pRmrP2kxYB0j+FVWUOjmGEAtEpcmvA9DkUEYFnvdHXfJ12/oiXHGIzfn7mWLaSu RYDaekTkpwr3Fx2bCl1eHBSU6K28kujTCK4QVh9/8NZrAETeU8cakKFoFmtz/QTfavDL c3RQ== X-Gm-Message-State: APzg51BZnNY83WW9WXv2wGeDPLsx+E7Sih1SD6nIyQTXmbF2Zu9QOWfH yDwpb3wiMmW26s+gaPLSMiXZY8Sv/Hl6Eg1vukwzGQ== X-Google-Smtp-Source: ANB0VdYfi0kJxaMufgUKDcTViJ25kDy4qXhpQJgAKCLg8Hr9GsdAfmjQL28+AHqBLiNHuA1wq1XE72LKunf8ksYshrs= X-Received: by 2002:a17:902:4324:: with SMTP id i33-v6mr8787947pld.43.1536874914874; Thu, 13 Sep 2018 14:41:54 -0700 (PDT) MIME-Version: 1.0 From: bill profane Date: Thu, 13 Sep 2018 14:41:43 -0700 Message-ID: Subject: Creating a memory/networking hungry mode in FreeBSD To: freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 13 Sep 2018 22:20:16 +0000 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: Thu, 13 Sep 2018 21:41:56 -0000 Is it possible? Maybe by threading and caching Idealistically I feel desktop FreeBSD should have a mode that uses the resources as much as possible instead of keeping it idle From owner-freebsd-current@freebsd.org Thu Sep 13 22:44: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 74F1B109C9BA for ; Thu, 13 Sep 2018 22:44:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 150D689D9E for ; Thu, 13 Sep 2018 22:44:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CD6A4109C9B9; Thu, 13 Sep 2018 22:44:16 +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 BA4D1109C9B8 for ; Thu, 13 Sep 2018 22:44:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1EC89D9A; Thu, 13 Sep 2018 22:44:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id C1BD910A87D; Thu, 13 Sep 2018 18:44:14 -0400 (EDT) Subject: Re: Speed problems with both system openssl and security/openssl-devel To: Lev Serebryakov , Kevin Oberman References: <43892083.20180913024646@serebryakov.spb.ru> <7316152.20180913112742@serebryakov.spb.ru> Cc: current , brnrd@freebsd.org, Jung-uk Kim From: John Baldwin Message-ID: <73a0934b-136f-785e-57bc-1f5624eea4fa@FreeBSD.org> Date: Thu, 13 Sep 2018 15:44:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7316152.20180913112742@serebryakov.spb.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 13 Sep 2018 18:44:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2018 22:44:17 -0000 On 9/13/18 1:27 AM, Lev Serebryakov wrote: > Hello Kevin, > > Thursday, September 13, 2018, 6:32:30 AM, you wrote: > > >> This is probably not the issue, but aesni is not in the GENERIC kernel.  Are you sure aesni.ko is loaded? >> % kldstat | grep aesni > I'm not using modules, as it is NanoBSD image build for minimal size ant > maximal efficiency. But I have aesni in my kernel config for sure: > > % grep aesni ~/nanobsd/gatevay.v3/J3160 > device aesni >From my understanding of the OpenSSL code, it doesn't use the kernel driver at all (the kernel driver is only needed for in-kernel crypto such as IPSec or GELI). AESNI are just instructions that can be used in userland, and OpenSSL's AESNI acceleration is purely different routines in userland. I would verify if AESNI shows up in the CPU features in dmesg first (if it doesn't I'd check for a BIOS option disabling it). -- John Baldwin                                                                              From owner-freebsd-current@freebsd.org Fri Sep 14 00:11: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 CA9A0109E7F3 for ; Fri, 14 Sep 2018 00:11:36 +0000 (UTC) (envelope-from lev@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 6EB718C5F0 for ; Fri, 14 Sep 2018 00:11:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3393B109E7F2; Fri, 14 Sep 2018 00:11:36 +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 22523109E7F0 for ; Fri, 14 Sep 2018 00:11: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 B9A8F8C5EA; Fri, 14 Sep 2018 00:11:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d89e:94c1:6f19:681d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 4ABF192B; Fri, 14 Sep 2018 03:11:34 +0300 (MSK) Date: Fri, 14 Sep 2018 03:11:33 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <594107633.20180914031133@serebryakov.spb.ru> To: John Baldwin , Kevin Oberman CC: current , brnrd@freebsd.org, Jung-uk Kim Subject: Re: Speed problems with both system openssl and security/openssl-devel In-Reply-To: <73a0934b-136f-785e-57bc-1f5624eea4fa@FreeBSD.org> References: <43892083.20180913024646@serebryakov.spb.ru> <7316152.20180913112742@serebryakov.spb.ru> <73a0934b-136f-785e-57bc-1f5624eea4fa@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2018 00:11:37 -0000 Hello John, Friday, September 14, 2018, 1:44:13 AM, you wrote: >> % grep aesni ~/nanobsd/gatevay.v3/J3160 >> device aesni > From my understanding of the OpenSSL code, it doesn't use the kernel driver > at all (the kernel driver is only needed for in-kernel crypto such as IPSec > or GELI). It is my understanding too. > AESNI are just instructions that can be used in userland, and > OpenSSL's AESNI acceleration is purely different routines in userland. > I would verify if AESNI shows up in the CPU features in dmesg first (if it > doesn't I'd check for a BIOS option disabling it). It is enabled. It is used for sure by openssl 1.1.0 on Linux and bu openssl 1.1.1 on FreeBSD, but not by openssl 1.0.2 and 1.1.0 on FreeBSD. Problem is, openssl 1.1.1 is not used by anything on FreeBSD (yet) and almost everything uses system (1.0.2) and only some other ports could use 1.1.0 from ports. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Fri Sep 14 07:23: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 44B4510A6485; Fri, 14 Sep 2018 07:23:29 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from mail.anongoth.pl (mail.anongoth.pl [46.248.190.61]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anongoth.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D313677513; Fri, 14 Sep 2018 07:23:28 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from anongoth.pl (unknown [10.8.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pkubaj", Issuer "anongoth.pl" (not verified)) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id 281E8C3C6; Fri, 14 Sep 2018 09:23:19 +0200 (CEST) Date: Fri, 14 Sep 2018 09:23:18 +0200 From: Piotr Kubaj To: freebsd-current@freebsd.org, freebsd-ppc@freebsd.org Subject: nvme0: Missing interrupt on powerpc64 Message-ID: <20180914072318.GC85786@smtp.iq.pl> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ppc@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailman-Approved-At: Fri, 14 Sep 2018 10:26:56 +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, 14 Sep 2018 07:23:29 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm running FreeBSD 12.0-ALPHA5 on Talos Lite (Power9). I have / on NVME dr= ive. During boot, I'm getting: nvme0: Missing interrupt It happens when /etc/rc.d/kldxref runs. If I press ^C, booting goes on. --=20 _______________________________________=20 / A committee is a group that keeps the \ | minutes and loses hours. | | | \ -- Milton Berle / ---------------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJkBAABCgBOFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAlubYeYwFIAAAAAAFQAS cGthLWFkZHJlc3NAZ251cGcub3JncGt1YmFqQGFub25nb3RoLnBsAAoJEHpZm4Ug g5ydXTsQAIBuJW3D/LzVd5SQmlla5wPNNE+Cj5gSB8Tyj48j8/HdYDv1mEVyhZo7 9OVyv6zbiz7hNAj2L7IRPghSTfVtLsjwNOgt+cO0ND8EMmTsXJgqxVf54wiSXfRN usLhq1hO73Om8w0IER4l55UOn1XFXZIZeHFRkGBT9ncGRVb5gMSKznD9WhmStDR1 V+r8kkQG8vF1lbHYuonM/HxIpMyv4lOrU5a50Z7OJBXRUpMGY75bg/VrPllDpIcT +9kOWMHGtuTFmDrnmVc2hpiPRW6KhB7bWn6WxhFmS+o6anq0zk8xuPGg8Mgd6sVD TowtbGc/dm5gh1QS0uiEqDsHEEVRwDXB2vOc6elRfgzR+ei89T4Ay1SiVjD8UOke cyQFYSBYZ4lhGmGlgDFgWgGO1p0w/z90bkG6CdISXsoNYPLd6w4ykjUWYAgk2WqY JHAbjt8IgQz8yODJn8lEtih/jCIBqX9YXFDI55iwGvfskMomGtAPLip4PuLIZ/bq APqCxyv/s1p2Riv71YiwO16q5UUZMiplo0QZocWv+oDj1Fqowo/Ok0md2glq/8Vt IXukML5OUYM8IdAx9HmIUihMEX9tOVHjh89JlTG+PDlO8ea47retX5R9oP17tF8K /BKIHbD8g1t4U85OvEFbKr0CHlIYMDyEiQYmX7B2i0mJ0Kee+WzA =2Qgd -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- From owner-freebsd-current@freebsd.org Fri Sep 14 11:39: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 96F311080232 for ; Fri, 14 Sep 2018 11:39:49 +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 E7A2F7E2C2 for ; Fri, 14 Sep 2018 11:39:48 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([141.89.176.208]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LorB9-1fJzph46J9-00gmcV for ; Fri, 14 Sep 2018 13:34:35 +0200 Date: Fri, 14 Sep 2018 13:34:33 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: ppp.linkup: How is the !bg argument expanded and substituted? Message-ID: <20180914133433.26280064@hermann> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:dc9xKkFskooGEldxrEXlTnILbppNHxN6Dhbi3bGiOaPJWhCM0Yq 03beZEEIpkcd0e8nE0cARfRCXRO8Xfbg1zTGDO8Y4Uf0CDTPXG46yGI9DEjno8treugFyLh xIV0d+h81xtzC6im4oTLqEg27LM3fsAAtMt5OJgfcZSaLC9Xrkuw9CyWCa0sBib4ioaBbp0 mns+oM3kfy/2oq0ZvLGIg== X-UI-Out-Filterresults: notjunk:1;V01:K0:K6Ikd8U2ALY=:viHNJOnrWO/CDgOxDYFWpN osclBdluVknz6h+InjB3xng1IyCa2+wPtnBXymiPSFvXy+02ahVAiOWMvdAdLtxnETNDsN6Xz mFIFvwE0Z7bFbNiiwrAULX3DLh7vUASJCNQjVD9zYW8DDw1x2XL7/D2ZJE+4PYU1OP+21R1Rt g4m/tVBDIvr6GyTjPHz+6ePo5d64VIhrsVm7J44mbyURtfFwakomIKEW2dpbg8zN3UEbI0W3O PjBTLWUOSP5BhNPNjTeD7flcsBPttkhZzCo+Uo3DsVZmNCjD3IDAGB6oAhjX+zuLUEB+z/3to 22ThCG8kcBqEZ6ZXkaeYg6PtsJs99Eb/+5/xPX9tkyvzEg7tcFV2ouw4UvOqPLAuzYmG2UCVn 6fiPUOVIRsmjQkf2v1oDSBaWY4/GY4caW3ePzo6Sc7jue43MtrZM9vMZ+xy/cx5iW0O/VmcgF T6VIlUF3orS7KUwBjjYFOx+ylN+FAr30p0QgWzR7dGxuGmfKfI2FbHHyCWFrAgx0G99TZVqI7 d7gcp5kND98UBfb25tCQf7D9Yx7rBIi3V1dCxfovvnYLTN0A/lRFdcxt1zeNCGVq6n4tbvZZW De/k/fY3SOHbP1m9NzQ2Ov0aRbWF7VTJ90oGLFr1nmRKNplas6dxHfMUptF3M2JC2qpC1Z+g+ Bg9kOmNLC3RCpELhzfBIk9XaEpg0Kk+MLe4JEA1a256fe1wGyePKxk5DIbPAyCiu13Wlj916R b0Povdbd9XNpnECyiJhIsNMSXbeopzypvxL2/QNyUGiSjR5MWIAVnv2pvBq1TthSfOtJzdWmI 3LKDYL1c55uhp1de7J+bD41A02IDxah5a0Y2KKL+6joFYOXS0M= 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, 14 Sep 2018 11:39:49 -0000 Hello list, my question may sound blunt but I miss something with the documentation of ppp(8). Background: My homeoffice is running a network and server infrastructure I'd like to access from the internet, therefore, I use a DDNS service. My gateway is a FreeBSD based small, efficient NanoBSD based system acting as firewall, router and performing some gatewaying stuff. Recently the usually used dns/ddclient stopped working on recent CURRENT running on that gateway (FreeBSD 12.0-ALPHA5 #32 r338541: Sun Sep 9 09:27:47 CEST 2018 amd64, NETINET6 enabled, secureretylevel=1, all NICs have only IPv6 linklocal, exterior IF is tun0 with a regular IPv4 assign by my ISP and only linklocal IPv6). dns/ddclient stopped working out of the blue and I need an alternative to update my IP (ipv4) at my DDNS provider. To achiev the requested IPv4 updates as done via ddclient I used /etc/ppp/ppp.linkup with a !bg command this way: !bg /usr/local/bin/curl -v -X PUT -u \ \"email@host.de:SOME_TOKEN_GIVEN_BY_PROVIDER\" \ -d '{\"ip_address\": \"auto\"}' https://api.twodns.de/hosts/all It is ONE ROW, I broke it up for presentation here. Somehow I needed to escape some quotes like \"; I tried to check how ppp would emmit the !bg command via a logger statement with the very same line - the reason is I can't see what ppp is doing and since DDNS updates never were performed so far via ppp.linkup I consider some mistakes here. For the JSON data (after -d '{...}'), quoted tags are requisite. When I issue the command on the gateway without the escaped quotes to achieve the command line: /usr/local/bin/curl -v -X PUT -u \ "email@host.de:SOME_TOKEN_GIVEN_BY_PROVIDER" \ -d '{"ip_address": "auto"}' https://api.twodns.de/hosts/all everythings works perfect: the IP gets updated, the DDNS provider respons with status code "200 OK". So far. But somehow this never happens or is successful with the !bg statement from ppp.linkup when the IP changes on that link and ppp.linkup is triggered. Since I do not see why (it seems that the response from the !bg command is lost), I need to check the substitutions. Can someone enlighted please shed some illumination on that problem? It would really help to hint me to the doc were I can read about the way the command string is parsed/interpreted by ppp (I only found the substitutions for MYADDR, MYADDR6 and so on in man ppp(8)). Thanks in advance, Oliver From owner-freebsd-current@freebsd.org Fri Sep 14 12:30: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 6DD3C1082207 for ; Fri, 14 Sep 2018 12:30: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 C39E0804D4 for ; Fri, 14 Sep 2018 12:30:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([141.89.176.208]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvzF3-1fm7wS3zbh-017pPf for ; Fri, 14 Sep 2018 14:30:02 +0200 Date: Fri, 14 Sep 2018 14:30:00 +0200 From: "Hartmann, O." To: freebsd-current@freebsd.org Subject: WiFi QCA986x/988x 802.11ac Wireless Network Adapter support? Message-ID: <20180914142956.74417882@hermann> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:WF33TBe1pLys7apEppZ2ok1IbbLMhJIsWFM9tpvnSN8+Sfx/ZRm BxFpdYQR8YhKocyCKr/RT+aJmcS/9gx/k8piRKSShlmYh2leUQRogxVpb622eCmS+DVd8qe hONJoSrtjC/puOwvwHD8rp3dgxO1GipJoz9LtaAsA8s6d4Nw0PxnPT9qqGw5r/nnGtEU5Ra kGNn73CFowiq/4nHKT7qA== X-UI-Out-Filterresults: notjunk:1;V01:K0:eZGsc4LKkVs=:nW7PRKmwDOqh3bynYLEbL0 S9IuAlHh3LBvpxfLQ76UDF9dtRvGC0/mfjZQgu03k8NmtPnOcKrS2kDggU9oeNSBPxqs/ofMt KSI8uzLTSPKu4CYWC5R3n/6jbtK++RQxROOgc15kVrvjzzzM/vNowmgLHUD3e5EJ1uNmVeoEG zMwmrmejP7lYnNxnj6JX/X49KeSzq1LBX+Wim7M963ZM78xtAcFVsqr4kVS/22G4pXbLLAMU4 n4b6feA9jPrPu3sSG/iavtoEMiCmC4C2KcH4oZYIAwFwyYFHBkIF2QLO8L6s3BxJtavgrlICS BQQNVBjZGIZn71DBSx0oUxciIvyBY/XJO8Y0aAqBCsm0OqJeuigVIPoW1HnnC9DANB8jOQ4Ob IaxdVM2SsFzbryp4QEijt+9IrcL0wGJwktd9yNmphi+rA/N6euCM6/U31HE6oXFpQ1SBTpUpa WIjgujBXMZjWF+0OY21QJkHbLsNZEtDY3t6c/x0Z0KzdUETyT4Z2SmYX9uOWFtG4nmXgJs2Pz yh5zbd3njEn/pqU86po+ClAILQDaGdS+a4nri44L3XmgEsna0hU1MXqvhjy7mHpWlut5gHKo4 LcrhGEbNMAWEkHA/AiK4Kr1r/kQF/QFlVLa+7ZGypttiR1VEpsu5Fll00Rl70Fw3Tpze2THxb Rk4lLLKPGkQkxygSHtvkc+KZ/iLKbEswNQci483OC2oy15zWg5OxtYZylkjqfoN7Cn4+lYaA8 lLlX4MVo7CI59+sgVArG2rdSEXYEvwdDB64ukzqCeyUYuzWCG+qDj1x2XSuZ3KfMjDrsJBxm4 TjLhPBk6/Ambl9/aGcE6k4XpZj6H/x0yKDP4FJiz1DgHtZ56K0= 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, 14 Sep 2018 12:30:07 -0000 For a while 802.11ac adapters are out and some of them made by Qualcomm/Atheros are considered useful for building accesspoints, like the QCA9882. Running revent 12-ALPHA6 on an APU from PCengines equipted with such an WiFi adaptor (I think this product is named Compex WLE600V) and ath/ath_hal driver loaded still gives me: none1@pci0:1:0:0: class=0x028000 card=0x00000000 chip=0x003c168c rev=0x00 hdr=0x00 vendor = 'Atheros' device = 'QCA986x/988x 802.11ac Wireless Network Adapter' class = network bar [10] = type Memory, range 64, base 0xfe200000, size 2097152, enabled Linux ath10k driver claims to support this specific chipset (never tried Linux on our PCengines APU2!), and I was wondering if there is support for FreeBSD as well? Since this WiFi adaptor seems to have similar reputations for being used as hostapd AP devices for WiFi routers on FreeBSD as several older ath 802.11bg/n devices, I was wondering whether development of a suitable driver is planned or has been started for FreeBSD. Thanks in advance, oh From owner-freebsd-current@freebsd.org Fri Sep 14 12:42: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 914B910826B0 for ; Fri, 14 Sep 2018 12:42:21 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1060580C33 for ; Fri, 14 Sep 2018 12:42:20 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:to:subject:message-id; s=default; bh=VaKJTgO4K0ae5rlwTCQirzHcQA7ooHerApT5D5K0W08=; b=bJx1h4WeJiBTPzRirYdFw3bsCKU6JLsITwENlxkQjeWTik21B0fUabhCiHCBmpwuJHTcMR+Lzjru8lH1wYho8/2AUU2t/q+SUTz6UyjkqwjTPj4qZ/LSCi7V0ToLLV+BjPpP9vooPpPlDvColZs3IuhDN6JoE/QuUc88CqrP3FQ= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 02f9ecfb TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 14 Sep 2018 12:42:07 +0000 (UTC) Received: from localhost (markarth.lan [local]) by markarth.lan (OpenSMTPD) with ESMTPA id d6b564db; Fri, 14 Sep 2018 15:42:29 +0300 (MSK) Date: Fri, 14 Sep 2018 15:42:29 +0300 From: Greg To: "Hartmann, O." Cc: freebsd-current@freebsd.org Subject: Re: WiFi QCA986x/988x 802.11ac Wireless Network Adapter support? Message-ID: <20180914124229.4vrggs7uolujfypx@unrelenting.technology> References: <20180914142956.74417882@hermann> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <20180914142956.74417882@hermann> OpenPGP: url=https://unrelenting.technology/pub/3B011BAF.asc User-Agent: the one that sucks less X-Hashcash: 1:20:180914:freebsd-current@freebsd.org::wz6Nr6DVvH4UVtKC:3+cc X-Hashcash: 1:20:180914:ohartmann@walstatt.org::t2UQvZ7ojAFaajnh:2Col 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, 14 Sep 2018 12:42:21 -0000 On 09/14, Hartmann, O. wrote: >For a while 802.11ac adapters are out and some of them made by >Qualcomm/Atheros are considered useful for building accesspoints, like >the QCA9882. > >Running revent 12-ALPHA6 on an APU from PCengines equipted with such an >WiFi adaptor (I think this product is named Compex WLE600V) and >ath/ath_hal driver loaded still gives me: > [...] >Linux ath10k driver claims to support this specific chipset (never >tried Linux on our PCengines APU2!), and I was wondering if there is >support for FreeBSD as well? Hi, adrian@ has been working on ath10k: https://github.com/erikarn/athp From owner-freebsd-current@freebsd.org Fri Sep 14 13:45: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 8D9FC1083FC7 for ; Fri, 14 Sep 2018 13:45:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2788C8292F for ; Fri, 14 Sep 2018 13:45:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0oPX-000MID-9n; Fri, 14 Sep 2018 14:45:27 +0100 Date: Fri, 14 Sep 2018 14:45:27 +0100 From: Gary Palmer To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: ppp.linkup: How is the !bg argument expanded and substituted? Message-ID: <20180914134527.GB72784@in-addr.com> References: <20180914133433.26280064@hermann> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180914133433.26280064@hermann> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2018 13:45:29 -0000 On Fri, Sep 14, 2018 at 01:34:33PM +0200, Hartmann, O. wrote: > Hello list, > > my question may sound blunt but I miss something with the documentation > of ppp(8). > > Background: My homeoffice is running a network and server > infrastructure I'd like to access from the internet, therefore, I use a > DDNS service. My gateway is a FreeBSD based small, efficient NanoBSD > based system acting as firewall, router and performing some gatewaying > stuff. Recently the usually used dns/ddclient stopped working on > recent CURRENT running on that gateway (FreeBSD 12.0-ALPHA5 #32 > r338541: Sun Sep 9 09:27:47 CEST 2018 amd64, NETINET6 enabled, > secureretylevel=1, all NICs have only IPv6 linklocal, exterior IF is > tun0 with a regular IPv4 assign by my ISP and only linklocal IPv6). > dns/ddclient stopped working out of the blue and I need an alternative > to update my IP (ipv4) at my DDNS provider. > > To achiev the requested IPv4 updates as done via ddclient I > used /etc/ppp/ppp.linkup with a !bg command this way: > > !bg /usr/local/bin/curl -v -X PUT -u \ > \"email@host.de:SOME_TOKEN_GIVEN_BY_PROVIDER\" \ > -d '{\"ip_address\": \"auto\"}' https://api.twodns.de/hosts/all > > It is ONE ROW, I broke it up for presentation here. > > Somehow I needed to escape some quotes like \"; I tried to check how > ppp would emmit the !bg command via a logger statement with the very > same line - the reason is I can't see what ppp is doing and since DDNS > updates never were performed so far via ppp.linkup I consider some > mistakes here. > > For the JSON data (after -d '{...}'), quoted tags are requisite. > > When I issue the command on the gateway without the escaped quotes to > achieve the command line: > > /usr/local/bin/curl -v -X PUT -u \ > "email@host.de:SOME_TOKEN_GIVEN_BY_PROVIDER" \ > -d '{"ip_address": "auto"}' https://api.twodns.de/hosts/all > > everythings works perfect: the IP gets updated, the DDNS provider > respons with status code "200 OK". So far. > > But somehow this never happens or is successful with the !bg statement > from ppp.linkup when the IP changes on that link and ppp.linkup is > triggered. Since I do not see why (it seems that the response from > the !bg command is lost), I need to check the substitutions. > > Can someone enlighted please shed some illumination on that problem? It > would really help to hint me to the doc were I can read about the way > the command string is parsed/interpreted by ppp (I only found the > substitutions for MYADDR, MYADDR6 and so on in man ppp(8)). I'd skip the above and put the CURL command into a small script which is run from the !bg command Regards, Gary From owner-freebsd-current@freebsd.org Fri Sep 14 18:24: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 A10FB109013C for ; Fri, 14 Sep 2018 18:24:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.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 3A4018C9F7 for ; Fri, 14 Sep 2018 18:24:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wv9oV7kVM1n0T.vTn5n.9Mb_AshowmWind_gaPmzwjVb.YBRM8Ag_rVRikFgkQR ziKXpAPrElhQzv.DNrxpQtISLXidDfaIpO2Vmvid0Sj23GupygtX2t.FAoMWqrT5mySDBACFKF9V 0luBgbaBX52AZYrVzXfdnuf5zBCMddno0kCuDnk9HqsfAG64j38dS1Ay8I.IEIv_5s7vErgPaC66 tXpvXTr.d2XI0dd.86Bd.MIsegv87NLIjvGr6MA9q1w2asqIOCKOlFq8N7vg.Dw_8.mfsXdeioCd wpbNH6RHqgGuTB0xV4bGRCcfNAj4O7ncgQHSdoCpfC.nz0CQ6y1sS46G1JuNnmGwzJBlX7XbaHQt 5YIcFnh0T60IQSduThD8S7kUQzaEP0brdQ1q0LgG9k6eM1skcG07Fg26GOZ45UD.0AUbIdjh41GG qs3pmrkvs19JW8jO7EOmCqeMaQtnG_TuJYsT4lUighQAUWAmnDTLyvu6RCYmesoPaBfkLjSBcD8T Bv61yK7Ehbjgq2VAs45MyPFwz.YbsfGTYELdDMWpfIxNY03rrL8QYme49uOrs31cBsd1_pzaITCX 0L_e957xfFn0gJyMqsZUYOMZjescvwXH0VWlQZRc33RcLYLiWJK8sbiYaBg3Xtq.4XpZqOvIUIEz pR.6ieE417TPblVfxub_7oQTu7.uk8R3wveFoXLaW6o97EaKJBEGgrcP9VNseInGWb4ZsfnL0NoT EiCVb4tuZdbUT3331TRn1MlFtb1FvIs3MDvJbeluJoBmf4KPaNLPguMAgI.WSP.pMpUKAEyOfQbN bXfKKmq8ES73l6QbFnk0ZdrfUovf4YNopj57eIlVN5GPTiH7rKWheA4Y828wZ83d6rxZ0h5MQWyT anyrpHAYUQozQR9EtOnwfaNxdowDF_vLd1ozms3TwdIYAH0buVhCzmIdd4i1zIH8xcc6zhdeYsai o7oEFr5UkyC8HWvbUuuTUyHRoIsVLy15I3jHWIm.Y9QIH8pdvU3fqxhJ.0gvdxW_2zLIidPA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 14 Sep 2018 18:24:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f1da5f9dede5893759a0964615ace41c; Fri, 14 Sep 2018 18:24:05 +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: devd on head -r338675 on aarch64 (Pine64+ 2GB example) gets during booting: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found" Message-Id: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Date: Fri, 14 Sep 2018 11:24:03 -0700 To: freebsd-arm , 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, 14 Sep 2018 18:24:13 -0000 =46rom the boot of the Pine64+ 2GB for -r338675: . . . Starting devd. sh: /usr/libexec/hyperv/hyperv_vfattach: not found add host 127.0.0.1: gateway lo0 fib 0: route already in table . . . This seems to result from: # grep -r hyperv_vfattach /etc/ | more /etc/devd/hyperv.conf:# For transparent network VF, hyperv_vfattach does = nothing and /etc/devd/hyperv.conf: action "/usr/libexec/hyperv/hyperv_vfattach = $subsystem 0"; But for the aarch64/pine64+ context there is only: # ls -a /usr/libexec/hyperv/ . .. On amd64 that directory has content, including the file referenced. aarch64/pine64+ is likely not unique in missing the files in /usr/libexec/hyperv/ . Context: uname output: # uname -apKU FreeBSD pine64 12.0-ALPHA6 FreeBSD 12.0-ALPHA6 #6 r338675M: Thu Sep 13 = 18:48:05 PDT 2018 = markmi@pine64:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64= /sys/GENERIC-NODBG arm64 aarch64 1200084 1200084 =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 Sep 14 18:32: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 E6C6E1090683 for ; Fri, 14 Sep 2018 18:32:40 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 448938D093 for ; Fri, 14 Sep 2018 18:32:40 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-lj1-x22d.google.com with SMTP id f1-v6so8282999ljc.9 for ; Fri, 14 Sep 2018 11:32:40 -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=CVGlDSE/EZOJH1vGCtKwgjAF81rSF4A3nBnKf6cfXNc=; b=Ql8/aOlriOoq4cpSaOydulBoHeEl5iq42Sy5gJ+mqSbFpbVpmd/5a4q6Q/5LnapM3C aKQ9T0BiggHIoqoNubBGlzSjXnALb9O2eHZlJeinJ/0U6eYAGdAZw9G3iqaNoof4Qby4 u7AsWlxFrWSRiZrWNGKU0bKDlAZrICXByj0BL5xzJn2rjgLL0ykTxd3IBdlxb9N8ZBzi 0vsZs1EmZlK04QgP15p/TJ/SlT2Dq4KEG02dMhBHOBPQY6X0u2zq6cF5PTJAU/I1Fy5a MuRR8KLqsKdYzWucYwEqhCFePxU+rb2ZbfmeTVsmUmSHGNESUglwclb+ZiSQNRYKJgXI RTZA== 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=CVGlDSE/EZOJH1vGCtKwgjAF81rSF4A3nBnKf6cfXNc=; b=lQjbCOk8YAAd/er1UMKiVF61z32+3ToOLUldEZmcmO5cDlvS01GRkt3NAWfMU9JRnk cVSarb7uLkIsVHF0M0Ws+u6swTuWEhQhqK0h7WTj+uPwL4fRwVN9j1pqFKjnectBSYN0 Tt1jJ1CQ/sXDSb4mdlEadhBjjFwNE90QJGZenqheuNpDNH9tjas3SxMwcGCVeoNkXSwv INQcRAj1sRp7cWnIP5vNmV2CAgEQ/wSpCXooDQbuJaX+Rw1AW/YLFeK3A/gaDLqaCuZU pD9lKt8KnnmCzFwzA5Qjr4LSYDlh7DkZu+3MVcLlQ1yDd12L42qXD79SLLtqTCVpJ0Rh yE4Q== X-Gm-Message-State: APzg51D8FCA5kuLBoNUeOVxiS93kWQus6lJ/sgkClCr0UC04UQUPbIOx d+8OQoBCybbXV6ostPZWmHHRjlt/c2u6nR3EO77f9vo+ X-Google-Smtp-Source: ANB0VdbKFqzk2c+m3CUUIRP/jw/JgklQh3cMW/+rrp4rQDBnKbYG52W/Zmpn67KwELFxP85csQS7rCd4ox7I3/NENro= X-Received: by 2002:a2e:534e:: with SMTP id t14-v6mr2727223ljd.26.1536949958516; Fri, 14 Sep 2018 11:32:38 -0700 (PDT) MIME-Version: 1.0 From: Subbsd Date: Fri, 14 Sep 2018 21:32:53 +0300 Message-ID: Subject: FreeBSD 12 regression: unable to boot in UEFI/bhyve: blank screen after loader To: freebsd-current 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: Fri, 14 Sep 2018 18:32:41 -0000 The problem started before FreeBSD 12 ALPHA1 but still exist in ALPHA6. If you try to run FreeBSD 12 (e.g. FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0/ ) in bhyve UEFI mode with command from handbook (https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/virtualization-host-bhyve.html) in chapter "21.7.5. Graphical UEFI Framebuffer for bhyve Guests" you will see a black screen after loader: https://pasteboard.co/HDSVqEE.png Apparently, this is due to recent changes in the [lua]loader. How to reproduce: 1) fetch -o /tmp/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso 2) truncate -s1g /tmp/guest.img 3) ifconfig tap1 create 4) kldload vmm 5) pkg install -y uefi-edk2-bhyve 6) bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc \ -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,/tmp/guest.img \ -s 4:0,ahci-cd,/tmp/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso -c 4 -m 1024M \ -s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ 7) vncviewer :5900 From owner-freebsd-current@freebsd.org Fri Sep 14 20:25:59 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 2FA791092BD0 for ; Fri, 14 Sep 2018 20:25:59 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 B3DCD703FC; Fri, 14 Sep 2018 20:25:58 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0uf7-0006nA-17; Fri, 14 Sep 2018 22:25:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OTGjyIzZCvZiXvfP4dg6JGrehyVeJX9BptQotdeG6pE=; b=fzYqcIZ8GthNf4oQ8Trv/A1OQW iMgXuzYPzagiiGyrTyF/ajKkwaLOycSZd2duQylvQ3l9Ubg6wGouDlahTRZ5nqU1gozSKSwCzHNYE HnDnst66JY4S72fH1xlf5KEx6S3n2fyMF1ZcIghcDLNRZeUcm8v1y3hx7NFeLWQ5GHN2+9CGR6nS6 pS74uS6LKZ3itYxXm2UoE+p5INQHtAgMGyOVKtmfJwi7j6k6IeM5DP586+C+03/IoEdYxXiEajw+V qsR/dGVYYvvWlhQAceSWpEbCB4BkVyrpRpBVLZfIZ+4k0G6ZMwkHsaZFIhsiqq8mSqT1jLyNcoVgT tHntEcCA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0uf6-000ABo-H6; Fri, 14 Sep 2018 22:25:56 +0200 Subject: Re: SD card reader only works after a suspend/resume From: Jakob Alvermark To: Marius Strobl Cc: FreeBSD Current References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> <20180906224108.GA65506@alchemy.franken.de> <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> <20180912221319.GL21523@alchemy.franken.de> Message-ID: Date: Fri, 14 Sep 2018 22:25:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 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, 14 Sep 2018 20:25:59 -0000 On 9/13/18 6:11 PM, Jakob Alvermark wrote: > On 9/13/18 12:13 AM, Marius Strobl wrote: >> On Fri, Sep 07, 2018 at 04:52:12PM +0200, Jakob Alvermark wrote: >>> On 9/7/18 12:41 AM, Marius Strobl wrote: >>>> On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: >>>>> Hi, >>>>> >>>>> >>>>> I discovered this by chance. >>>>> >>>>> The SD card reader in my laptop has never worked, but now I >>>>> noticed it >>>>> does after suspending and resuming. >>>>> >>>>> The controller is probed and attached on boot: >>>>> >>>>> sdhci_acpi1: iomem >>>>> 0x90a00000-0x90a00fff irq 47 on acpi0 >>>>> >>>>> But nothing happens if I put a card in. Unless I suspend and resume: >>>>> >>>>> mmc1: on sdhci_acpi1 >>>>> mmcsd0: 32GB at mmc1 >>>>> 50.0MHz/4bit/65535-block >>>>> >>>>> Then I can remove and replug cards and it seems to work just fine. >>>> I believe that making SD card insertion/removal with the integrated >>>> SDHCI controlers of newer Intel SoCs work out-of-the-box requires >>>> support for ACPI GPE interrupts and ACPI GPIO events respectively to >>>> be added to FreeBSD. Otherwise insertion/removal interrutps/events >>>> aren't reported and polling the card present state doesn't generally >>>> work as a workaround with these controllers either, unfortunately. >>>> I'm not aware of anyone working on the former, though. >>>> >>>> Polling the card present state happens to work one time after SDHCI >>>> initialization with these controllers which is why a card will be >>>> attached when inserted as part of a suspend/resume cycle (resume of >>>> mmc(4) had some bugs until some months ago, which probably explains >>>> why that procedure hasn't worked as a workaround for you in the past). >>>> Inserting the card before boot, unloading/loading sdhci_acpi.ko or >>>> triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow >>>> to attach a card, too. >>> If a card is inserted before booting it is not detected. >>> >>> Removing and inserting card after boot is not detected unless I suspend >>> and resume. >>> >>> After I have suspended and resumed once, cards are detected. Removals >>> and insertions are detected as they happen. >> Okay, then you are seeing somewhat different behavior than I do. What >> SoC model is this? > > > CPU: Intel(R) Pentium(R) CPU  N3540  @ 2.16GHz (2166.73-MHz K8-class CPU) > > >>   Are you loading a GPIO controller driver such as >> bytgpio(4) or chvgpio(4)? Doing so might be sufficient to kick ACPI >> GPIO events into working but would be missing dependency information >> between drivers (which might explain what you are experiencing if >> sdhci_acpi1 attaches first) and some other bits to do it properly. > > > I have bytgpio_load="YES" in /boot/loader.conf > > But I tried removing it, doesn't change the behavior. > > With or without the bytgpio driver, inserting or removing cards is > only detected after a suspend/resume cycle of the computer. > > >> Also, could you please try whether doing a suspend/resume cycle of >> sdhci_acpi1 via devctl(8) only kicks the card detection into working? >> That test should indicate whether the firmware plays a role in making >> the latter work. > > > Tried that. > > devctl suspend sdhci_acpi1 > > devctl resume sdhci_acpi1 > > Doesn't make any difference. > > Also tried devctl disable/enable. No change. Additional research: After boot, before any suspend/resume: From acpidump -d         Device (SDHC)         {             Name (_ADR, Zero)  // _ADR: Address             Name (_HID, "80860F16")  // _HID: Hardware ID             Name (_CID, "PNP0D40" /* SDA Standard Compliant SD Host Controller */)  // _CID: Compatible ID             Name (_DDN, "Intel(R) SD Card Controller - 80860F16") // _DDN: DOS Device Name             Name (_UID, 0x03)  // _UID: Unique ID             Name (RBUF, ResourceTemplate ()             {                 Memory32Fixed (ReadWrite,                     0x00000000,         // Address Base                     0x00001000,         // Address Length                     _Y04)                 Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )                 {                     0x0000002F,                 }                 GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x2710,                     "\\_SB.GPO0", 0x00, ResourceConsumer, ,                     )                     {   // Pin list                         0x0026                     }                 GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionInputOnly,                     "\\_SB.GPO0", 0x00, ResourceConsumer, ,                     )                     {   // Pin list                         0x0026                     }             }) And indeed card detection is GPIO pin 38 (0x26): No card: gpioctl -l | grep "pin 38" pin 38:    1    GPIO_S0_SC38 Card inserted: gpioctl -l | grep "pin 38" pin 38:    0    GPIO_S0_SC38 After suspend/resume card detection works: mmc1: on sdhci_acpi1 mmcsd0: 32GB at mmc1 50.0MHz/4bit/65535-block But pin 38 is always 1, regardless if a card is inserted or not: gpioctl -l | grep "pin 38" pin 38:    1    GPIO_S0_SC38 And 'acpidump -d' fails: acpidump: RSDT entry 12 is corrupt Any clue on what's going on here? Jakob From owner-freebsd-current@freebsd.org Fri Sep 14 22:59: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 2FA971095DEA; Fri, 14 Sep 2018 22:59:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA80175873; Fri, 14 Sep 2018 22:59:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id E56B010AFCD; Fri, 14 Sep 2018 18:59:27 -0400 (EDT) Subject: Re: devd on head -r338675 on aarch64 (Pine64+ 2GB example) gets during booting: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found" To: Mark Millard , freebsd-arm , FreeBSD Current References: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Cc: dexuan@FreeBSD.org From: John Baldwin Message-ID: Date: Fri, 14 Sep 2018 15:59:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 14 Sep 2018 18:59:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2018 22:59:33 -0000 On 9/14/18 11:24 AM, Mark Millard via freebsd-arm wrote: > From the boot of the Pine64+ 2GB for -r338675: > > . . . > Starting devd. > sh: /usr/libexec/hyperv/hyperv_vfattach: not found > add host 127.0.0.1: gateway lo0 fib 0: route already in table > . . . I got the same error booting FreeBSD/riscv in qemu. -- John Baldwin                                                                              From owner-freebsd-current@freebsd.org Sat Sep 15 01:32: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 239761098D5F; Sat, 15 Sep 2018 01:32:47 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 C6547799FB; Sat, 15 Sep 2018 01:32:46 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 97C875646F; Fri, 14 Sep 2018 20:32:45 -0500 (CDT) To: freebsd-current@freebsd.org, freebsd-net@freebsd.org From: Eric van Gyzen Subject: Bad DHCP Checksums over VLANs Message-ID: <9dd3c7f9-d970-5d30-ebf2-c0f40c76011b@vangyzen.net> Date: Fri, 14 Sep 2018 20:32:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.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: Sat, 15 Sep 2018 01:32:47 -0000 Folks, I'm running head (ALPHA4-ish) on a DHCP server and a client. DHCP works fine on the physical interfaces, but when I run it on a VLAN, I get 5 bad udp checksums in 5 packets from dhclient. Full details here: https://people.freebsd.org/~vangyzen/dhcp_vlan/ This happens for /all/ clients. This is a new setup, so I don't know when it got broken, and I can't bisect. The server NIC is common (I211), so maybe it's easy to reproduce. I'll help as much as I can, of course. Eric From owner-freebsd-current@freebsd.org Sat Sep 15 06:06:18 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 9B33C109D5AC; Sat, 15 Sep 2018 06:06:18 +0000 (UTC) (envelope-from pi@freebsd.org) 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 2EEC680C4F; Sat, 15 Sep 2018 06:06:18 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g13ih-0003v5-QQ; Sat, 15 Sep 2018 08:06:15 +0200 Date: Sat, 15 Sep 2018 08:06:15 +0200 From: Kurt Jaeger To: Eric van Gyzen Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bad DHCP Checksums over VLANs Message-ID: <20180915060615.GF2118@home.opsec.eu> References: <9dd3c7f9-d970-5d30-ebf2-c0f40c76011b@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9dd3c7f9-d970-5d30-ebf2-c0f40c76011b@vangyzen.net> 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, 15 Sep 2018 06:06:18 -0000 Hi! > The server NIC is common (I211), so maybe it's easy to reproduce. I'll > help as much as I can, of course. Can you disable all the options of the NIC ? ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum -vlanhwtso Try to disable everything that can be disabled, e.g. LRO etc. -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sat Sep 15 21:09: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 CFAF3108A226; Sat, 15 Sep 2018 21:09:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D63E70441; Sat, 15 Sep 2018 21:09:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lj1-x231.google.com with SMTP id u83-v6so10116897lje.12; Sat, 15 Sep 2018 14:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WR82q/B7X37Hz9Opn6/PkPMSwDzr2m18/5BZdGAVxrs=; b=nYhLIf2QfLQXC6iKREepJpBHU16r7rqgC8WuKKusR+5lHtM9K28riP3TVAOnxx6DOU Pvor6NGtiJW/KS2vCy98cVvJH7D83+P1JYqlDe5UvhEOlgi7JDj6T6EdjodsN6u/sKr7 4ypXGoNEz3xhd1E6oJUevZtjRYNn+Kwsre7+nyKiRVFSy8exQzkIz9q8o/ec75kwITZB MYnEsabYfmY8jOt/f3KBJm4ttT+j2junzDV7dwq6UQy51GDxcpkzuhGfQTGqFzm6ICla LzAUpoJUzPXROJpRWVxOIYrpJK61SH7C3VYHSf9Td1UdDzqeqv+tUPQ4iOHtoi431ivP OlSQ== 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; bh=WR82q/B7X37Hz9Opn6/PkPMSwDzr2m18/5BZdGAVxrs=; b=sEyQRnzU8lygEXtqGgJd9l6t/GxNKsRgFT1UXa0li7V1PVJIEqei/i5Kmxy2D0+HVr s+DID3pcHMbgNq9A4aiVnnqTP0wpRSNxzrqXciDqeQjz4498MUZm+cz2DwooBGYcaX2w pFF8xTocT5Tq9oSWaEHxFXw5+G+y7Lsfq38CneP+eMyVcI8yL7q3CuBzkRtMAXqvMADQ hhQRWGQoQRJAzCzSiu2kRz2Dpl1OZ5fzFLsWgabQbPcpxmiimFKw8UbXWBJ87iXcgzWJ FTqRGk5UKg7Kb1eLVL8C59WG/Mkoxa9olSfwwm02tMqen1068lAG9OZf9pQ989247NKd g/QA== X-Gm-Message-State: APzg51ChyaqysUF4rOUxKcgCVpV/jFtBv/r98lXpleU2CysEFSWPS+93 0be4un79Pc0gknvWV+vbrtR3W/BudcqgBufke3satg== X-Google-Smtp-Source: ANB0VdYbBhlUMSCj7mf4ajHN+BmrnEzAfeLTk7nefXtVGuAltSZXKHcU6Ha7ckAlaZC4sQEcMgmPHjKmuajDI42SkpU= X-Received: by 2002:a2e:9883:: with SMTP id b3-v6mr11009567ljj.80.1537045771712; Sat, 15 Sep 2018 14:09:31 -0700 (PDT) MIME-Version: 1.0 References: <20180914072318.GC85786@smtp.iq.pl> In-Reply-To: <20180914072318.GC85786@smtp.iq.pl> From: Justin Hibbits Date: Sat, 15 Sep 2018 17:09:17 -0400 Message-ID: Subject: Re: nvme0: Missing interrupt on powerpc64 To: pkubaj@anongoth.pl, FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 15 Sep 2018 23:05:46 +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: Sat, 15 Sep 2018 21:09:34 -0000 Hi Piotr, On Fri, Sep 14, 2018 at 3:23 AM Piotr Kubaj via freebsd-ppc wrote: > > Hello, > > I'm running FreeBSD 12.0-ALPHA5 on Talos Lite (Power9). I have / on NVME drive. > > During boot, I'm getting: > nvme0: Missing interrupt > > It happens when /etc/rc.d/kldxref runs. If I press ^C, booting goes on. This is a relatively known issue. I see it on my Talos II (regular, currently single-CPU). It only affects performance, it doesn't affect system stability, in my case anyway. Some others have reported NVMe crashes, but I haven't reproduced on my hardware. We haven't yet determined the cause of the missing interrupt, but it happens often, and causes things to hang for a bit before continuing. We still have a bit of work to do on the stability and performance sides on POWER, particularly with the interrupt controller (XIVE) and the PCIe controller. - Justin