From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 00:48:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49412C8 for ; Sun, 22 Feb 2015 00:48:18 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 2792FEE9 for ; Sun, 22 Feb 2015 00:48:17 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id A9572192A3B; Sun, 22 Feb 2015 00:48:14 +0000 (UTC) Message-ID: <54E9274C.9010903@ignoranthack.me> Date: Sat, 21 Feb 2015 16:48:12 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on application core dump? References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> In-Reply-To: <20150221211712.GG74514@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 00:48:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/21/15 13:17, Konstantin Belousov wrote: > On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Well, this is new. It looks like current panic'd when trying to >> dump a core from a qemu crash? I can leave this at the debugger >> for now as this is a machine doing mips package builds and is not >> "production". >> >> sean >> >> Thu Feb 19 18:50:59 UTC 2015 >> >> FreeBSD/amd64 (dirty.ysv.freebsd.org) (ttyu0) >> >> login: Feb 20 08:06:05 dirty sshd[51311]: fatal: Read from >> socket failed: Connection reset by peer [preauth] Feb 20 16:47:29 >> dirty su: sbruno to root on /dev/pts/1 Feb 21 02:15:44 dirty >> sshd[95051]: fatal: Read from socket failed: Connection reset by >> peer [preauth] >> >> >> Fatal trap 12: page fault while in kernel mode cpuid = 15; apic >> id = 35 fault virtual address = 0x380 fault code = >> supervisor read data, page not present instruction pointer = >> 0x20:0xffffffff809b2ed1 stack pointer = >> 0x28:0xfffffe046a3a30f0 frame pointer = >> 0x28:0xfffffe046a3a3170 code segment = base 0x0, limit >> 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 42563 (qemu-mips64) [ thread pid 42563 >> tid 100956 ] Stopped at __mtx_lock_sleep+0xb1: movl >> 0x380(%rax),%ecx db> bt Tracing pid 42563 tid 100956 td >> 0xfffff80109a214a0 __mtx_lock_sleep() at >> __mtx_lock_sleep+0xb1/frame 0xfffffe046a3a3170 vref() at >> vref+0x6d/frame 0xfffffe046a3a31a0 vn_fullpath1() at >> vn_fullpath1+0x62/frame 0xfffffe046a3a3200 vn_fullpath_global() >> at vn_fullpath_global+0x6e/frame 0xfffffe046a3a3240 sigexit() at >> sigexit+0xa22/frame 0xfffffe046a3a34f0 sendsig() at >> sendsig+0x65e/frame 0xfffffe046a3a3960 trapsignal() at >> trapsignal+0x2f7/frame 0xfffffe046a3a39e0 trap() at >> trap+0x3ba/frame 0xfffffe046a3a3bf0 calltrap() at >> calltrap+0x8/frame 0xfffffe046a3a3bf0 - --- trap 0xc, rip = >> 0x600334bc, rsp = 0x7ffbffe19990, rbp = 0x7ffffffe4a20 --- db> p >> vref+0x6d ffffffff80a876cd > > Err. Is it easily reproducable in your setup ? The core file vnode > is indeed unreferenced before notification is sent. > Probably not a deterministic crash, but I will get a dump and try out this change directly today. sean > Try this. > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index > 41da3dd..57f66b0 100644 --- a/sys/kern/kern_sig.c +++ > b/sys/kern/kern_sig.c @@ -3310,7 +3310,7 @@ coredump(struct thread > *td) vattr.va_nlink != 1 || (vp->v_vflag & VV_SYSTEM) != 0) { > VOP_UNLOCK(vp, 0); error = EFAULT; - goto close; + goto out; } > > VOP_UNLOCK(vp, 0); @@ -3347,17 +3347,12 @@ coredump(struct thread > *td) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &lf, F_FLOCK); } > vn_rangelock_unlock(vp, rl_cookie); -close: - error1 = vn_close(vp, > FWRITE, cred, td); - if (error == 0) - error = error1; - else - > goto out; + /* * Notify the userland helper that a process > triggered a core dump. * This allows the helper to run an automated > debugging session. */ - if (coredump_devctl == 0) + if (error != 0 > || coredump_devctl == 0) goto out; len = MAXPATHLEN * 2 + > sizeof(comm_name) - 1 + sizeof(' ') + sizeof(core_name) - 1; @@ > -3377,6 +3372,9 @@ close: strlcat(data, fullpath, len); > devctl_notify("kernel", "signal", "coredump", data); out: + error1 > = vn_close(vp, FWRITE, cred, td); + if (error == 0) + error = > error1; #ifdef AUDIT audit_proc_coredump(td, name, error); #endif > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU6SdJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kZlIH/0usK1j2BfzNT95UFE6KAoUv 0+JqmkJyGiR9hEQvvgcSiL9++NXnTLLz1z5SGbwAqL0hebXYckLXhxusObENBnnK ZMz12bsFmAI615eXK6ZJjsnZJWzmU/tjQjcY93Rao0M+AUTaGk5PFoR486hjhSM+ 7lg4KA+BlD5K991Zy9BzR0ZGSkjRnuZSQBsKbHe1RGbS1SAsf4PyfpvXDt0lhfN9 E/C2uvehYbBJi3vJuJx3pVXg5s+uyutnGLjBRY/sqOuiDOuGfHFdKbdgtApIAc0o B0/3I2IbAx3q0zy9c/4nuKjKHbr+di2pbFymUAH8beHcBuo5wsNFvfGTOqiX5ro= =nlAC -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 02:34:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FF55BEC for ; Sun, 22 Feb 2015 02:34:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9DCBA9 for ; Sun, 22 Feb 2015 02:34:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 168A3977 for ; Sun, 22 Feb 2015 02:34:41 +0000 (UTC) Date: Sun, 22 Feb 2015 02:34:40 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1299415964.29.1424572480815.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <216426652.28.1424539953124.JavaMail.jenkins@jenkins-9.freebsd.org> References: <216426652.28.1424539953124.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #741 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 02:34:41 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 09:08:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85DC55A0 for ; Sun, 22 Feb 2015 09:08:49 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 457811F7 for ; Sun, 22 Feb 2015 09:08:49 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9E8671FE022; Sun, 22 Feb 2015 10:08:46 +0100 (CET) Message-ID: <54E99CCE.5030401@selasky.org> Date: Sun, 22 Feb 2015 10:09:34 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Shawn Webb Subject: Re: Pluggable frame buffer devices References: <54E11A57.3030105@selasky.org> <1963872.pLReSBKNjx@shawnwebb-laptop> <54E6F060.2010301@selasky.org> <4020865.FJlWBPXrRZ@shawnwebb-laptop> In-Reply-To: <4020865.FJlWBPXrRZ@shawnwebb-laptop> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 09:08:49 -0000 On 02/21/15 23:59, Shawn Webb wrote: > On Friday, February 20, 2015 09:29:20 AM Hans Petter Selasky wrote: >> On 02/20/15 02:15, Shawn Webb wrote: >>> On Thursday, February 19, 2015 07:04:50 PM Shawn Webb wrote: >>>> On Sunday, February 15, 2015 11:14:47 PM Hans Petter Selasky wrote: >>>>> Hi, >>>>> >>>>> I've added support for USB display link adapters to FreeBSD-11-current, >>>>> but the kernel panics once "vt_fb_attach(info)" is called from >>>>> "fbd_register(struct fb_info* info)" when the USB device is plugged or >>>>> udl.ko is loaded. Is this a known issue? >>>>> >>>>> REF: https://svnweb.freebsd.org/base/head/sys/dev/usb/video/udl.c >>>>> >>>>> --HPS >>>> >>>> I just bought a DisplayLink adapter that's compatible. Compiling a new >> >>>> kernel with device udl brings this error: >> Hi, >> >> You need to also build the "sys/modules/videomode" and install and kldload. >> >> Does your device need a power supply? >> >> Can you plug the device through an external USB HUB after boot? >> >> Also you need some VT patches, before it will attach to VT which I can >> send you. See attachment. >> >> Beware the unplugging the device is not supported. It will crash / panic >> which needs to be resolved. >> >> --HPS > > (FYI: I'm switching email accounts from lattera@gmail.com to > shawn.webb@hardenedbsd.org) > > So I'm a little unsure how to test this. Could you provide some instructions? > > I bought this device: http://www.iogear.com/support/dm/driver/GUC2020DW6 > It's listed in udl.c as supported: > https://svnweb.freebsd.org/base/head/sys/dev/usb/video/udl.c?revision=278852&view=markup#l151 > > What kind of setup should I have in my xorg.conf to tell xorg to use that > instead of the built-in laptop display? Can you provide an example xorg.conf? > Xorg config is here: http://pastebin.com/W9yPBvcR I'll see if I can put the rest of the patches in place this week, so that it will be more easy for you. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 10:05:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D486DC8 for ; Sun, 22 Feb 2015 10:05:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2D368924 for ; Sun, 22 Feb 2015 10:05:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F1BD5A42 for ; Sun, 22 Feb 2015 10:05:53 +0000 (UTC) Date: Sun, 22 Feb 2015 10:05:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1948528528.30.1424599553523.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #743 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 10:05:54 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 11:03:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85DCEB3B for ; Sun, 22 Feb 2015 11:03:02 +0000 (UTC) Received: from nm43-vm5.bullet.mail.gq1.yahoo.com (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42E06E33 for ; Sun, 22 Feb 2015 11:03:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1424602639; bh=DwZG9xOw1EHBiSpPBTv6nkEVHMLafbebgxdOQwtuvvE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=PQaDkq3GJZs6YaEE9Qe9ijWCDZJn1Jxtu63FJ4yDE2hlBPfYSQNSsgbYfhSgkF65ijCunOWZZN4bXLzkJxbMpy2kYLc7Q3NUTfJKjhNahgeELa+JB+CXcl9idBcxdH/IhUhpwcz32YMDmWa0M1K6TaXGUWZTllQuP0xGbgYebN56vP6JgGdtOqPkXhrmRMGGPgsX3QvVgWqVzx+bFU6OF9qYN37dwAMGfexb5L45sRmbOiqieg/JarCEkH2FEhXJ+6P3GMTRk9Mi1Ba9MaUIWCkVJJtId4lrnsi5XY7/MMqwrplVRoKN/QPP2TXf7kKkiNh5+OVBFulphzchHGm4kw== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 22 Feb 2015 10:57:19 -0000 Received: from [98.137.12.189] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 22 Feb 2015 10:54:19 -0000 Received: from [98.137.12.210] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 22 Feb 2015 10:54:19 -0000 Received: from [127.0.0.1] by omp1018.mail.gq1.yahoo.com with NNFMP; 22 Feb 2015 10:54:19 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 634747.26078.bm@omp1018.mail.gq1.yahoo.com X-YMail-OSG: SQqg3MIVM1lAqvZKYe9QevgJDqWDYLdq6HgkabkR8zXplu8SxGrSQku4nSr1wrG omClybkilZ.UdZgbPtOsNZGlVIr1oLMz7umqVEZBY2F8qGxHD2BduZcgd1YctnyvxWUjeEpa6s1p CgIjV02gkIQN1Gt7shAH4TFHIFHwbbl606taWfHvCDyqL1PqSel7TBRbChzvfRIyn9aZr2GK9UPN wUmKlusYMqL65SsVHO6klVJc5SxlNqxLIMRW6UlQEsDoRVFDtDTNf_0I5nrNYT.zghsMMp7EqQ5Z gsT.5JzMKGjtwjjcnKF.w0XT2Eb2ALuLAcNw2ckFkI0CNTmGWmUv7qCtB6P0ihYvZa3dIpobiz25 eV8iDH2oBArRhFffNuw3gXJbsisRFlU48_zHGxGXJyO2MUaWaFcvTa.tUbZQlQ7zShU_pxwB22sp Xv1kcYin3160cF6Ao7AfZv7i.kMl8L0fyD95TZrsctCE.jVdgM1FHAIhwZqmd2RMUH_5StgucuKg w7sZNBt.GwJ3OYQhjAfO2SVlyAsFNnTp0J24AgoNjE2g9N897AdqDAi3I8I43230eHsSWSwEwFkh f4kg6gFkWIOEEgpI8OJmeLGMvHOtlqIbbAxF1LXHoTCWU37elKmX9maZqflqLBduzttxYKOgz0XK gz_Vzj9C1tPMV_uHSdedTBw9G0fsed10tc7.sde4Fzpe40CDshSF8YRbPBGcewEEt5qyRj597ksT GHUlU72RHTjs2HUNPNEjZsiHcTxiOp3bLs0zDrzidchQCreFd34UhiDbh61mPzYcvz2ZSHYAjI65 IzUY- Received: by 217.12.9.14; Sun, 22 Feb 2015 10:54:17 +0000 Date: Sun, 22 Feb 2015 10:54:17 +0000 (UTC) From: dervishe Reply-To: dervishe To: "freebsd-current@FreeBSD.org" Message-ID: <1227462529.6746581.1424602457182.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150220221246.661f2d01@shibato> References: <20150220221246.661f2d01@shibato> Subject: Re: [Call for testers] DRM device-independent code update to Linux 3.8 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-x11@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 11:03:02 -0000 Thanks for your work :)I apply the h version of the patch on r279140 and it= failed on some hunk (Same result as J.R Oldroyd)I will try to apply the pa= tch manually and give you the resultsMy chip is Intel Corei7 4th gen (Haswe= ll) K G+ : https://plus.google.com/u/0/+AlexandreKeledjian/posts Twitter: @dervyshe Blog: https://blogs.fsfe.org/dervishe/ Public key: https://keybase.io/dervishe/key.asc GitHub:=C2=A0https://github= .com/dervishe-/=20 Le Samedi 21 f=C3=A9vrier 2015 4h33, J.R. Oldroyd a = =C3=A9crit : =20 On Fri, 20 Feb 2015 15:49:44 +0100 Anders Bolt-Evensen wrote: >>=20 > I saw that you had updated your patchfile to drm-update-38.h.patch, and= =20 > ... > applied the patch, it seemed to be more successful, but on 22 occations= =20 > the patch still fails (the following list contains all the fails; the=20 > entire output can be seen here:=20 >=20 > Hunk #2 failed at 29. > 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_agpsupport.c.= rej > Hunk #2 failed at 31. > 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_auth.c.rej > Hunk #2 failed at 31. > 1 out of 26 hunks failed--saving rejects to sys/dev/drm2/drm_bufs.c.rej > Hunk #2 failed at 31. > 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_context.c.re= j > Hunk #1 failed at 21. > 1 out of 39 hunks failed--saving rejects to sys/dev/drm2/drm_crtc.h.rej > Hunk #2 failed at 31. > 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_dma.c.rej > Hunk #1 failed at 0. > 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_drawable.c.re= j > Hunk #2 failed at 44. > 1 out of 8 hunks failed--saving rejects to sys/dev/drm2/drm_drv.c.rej > Hunk #1 failed at 19. > 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_edid.h.rej > Hunk #1 failed at 21. > 1 out of 17 hunks failed--saving rejects to=20 > sys/dev/drm2/drm_edid_modes.h.rej > Hunk #1 failed at 26. > 1 out of 7 hunks failed--saving rejects to sys/dev/drm2/drm_fb_helper.h.r= ej > Hunk #2 failed at 32. > 1 out of 9 hunks failed--saving rejects to sys/dev/drm2/drm_fops.c.rej > Hunk #1 failed at 19. > 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_fourcc.h.rej > Hunk #1 failed at 0. > 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_internal.h.re= j > Hunk #2 failed at 31. > 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_ioctl.c.rej > Hunk #2 failed at 27. > 1 out of 50 hunks failed--saving rejects to sys/dev/drm2/drm_irq.c.rej > Hunk #2 failed at 31. > 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_lock.c.rej > Hunk #2 failed at 31. > 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/drm_memory.c.rej > Hunk #1 failed at 25. > 1 out of 10 hunks failed--saving rejects to sys/dev/drm2/drm_mm.h.rej > Hunk #1 failed at 22. > 1 out of 11 hunks failed--saving rejects to sys/dev/drm2/drm_mode.h.rej > Hunk #1 failed at 0. > 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.c.rej > Hunk #1 failed at 0. > 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.h.rej > _______________________________________________ Same errors here.=C2=A0 Applying patch to r279092 from svn master. Did you diff against the github source and is there perhaps some divergence between that and the svn master? I worked through the rejects and applied them manually. But, booting does not go well: Feb 20 21:58:22 xx kernel: panic: mtx_lock() of destroyed mutex @ /usr/src/= sys/modules/drm2/drm2/../../../dev/drm2/drm_irq.c:1036 Feb 20 21:58:22 xx kernel: cpuid =3D 0 Feb 20 21:58:22 xx kernel: KDB: stack backtrace: Feb 20 21:58:22 xx kernel: db_trace_self_wrapper() at db_trace_self_wrapper= +0x2b/frame 0xfffffe00b2966600 Feb 20 21:58:22 xx kernel: vpanic() at vpanic+0x189/frame 0xfffffe00b296668= 0 Feb 20 21:58:22 xx kernel: kassert_panic() at kassert_panic+0x132/frame 0xf= ffffe00b29666f0 Feb 20 21:58:22 xx kernel: __mtx_lock_flags() at __mtx_lock_flags+0x14a/fra= me 0xfffffe00b2966740 Feb 20 21:58:22 xx kernel: drm_vblank_post_modeset() at drm_vblank_post_mod= eset+0x3f/frame 0xfffffe00b2966770 Feb 20 21:58:22 xx kernel: atombios_crtc_dpms() at atombios_crtc_dpms+0x208= /frame 0xfffffe00b29667b0 Feb 20 21:58:22 xx kernel: atombios_crtc_commit() at atombios_crtc_commit+0= x14/frame 0xfffffe00b29667e0 Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_mode() at drm_crtc_helper_se= t_mode+0x480/frame 0xfffffe00b2966a30 Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_config() at drm_crtc_helper_= set_config+0x9c1/frame 0xfffffe00b2966b00 Feb 20 21:58:22 xx kernel: vt_restore_fbdev_mode() at vt_restore_fbdev_mode= +0x4e/frame 0xfffffe00b2966b20 Feb 20 21:58:22 xx kernel: taskqueue_run_locked() at taskqueue_run_locked+0= xf0/frame 0xfffffe00b2966b80 Feb 20 21:58:22 xx kernel: taskqueue_thread_loop() at taskqueue_thread_loop= +0x9b/frame 0xfffffe00b2966bb0 Feb 20 21:58:22 xx kernel: fork_exit() at fork_exit+0x84/frame 0xfffffe00b2= 966bf0 Feb 20 21:58:22 xx kernel: fork_trampoline() at fork_trampoline+0xe/frame 0= xfffffe00b2966bf0 Feb 20 21:58:22 xx kernel: --- trap 0, rip =3D 0, rsp =3D 0xfffffe00b2966cb= 0, rbp =3D 0 --- Feb 20 21:58:22 xx kernel: Uptime: 37s Feb 20 21:58:22 xx kernel: Dumping 236 out of 2915 MB:..7%..14%..21%..34%..= 41%..55%..61%..75%..82%..95% Feb 20 21:58:22 xx kernel: Dump complete Feb 20 21:58:22 xx kernel: Automatic reboot in 15 seconds - press a key on = the console to abort Feb 20 21:58:22 xx kernel: Rebooting... I can also see earlier that the cp still did not init... same old CAFEDEAD in r100_cp_init. Chip is ATI Radeon RS690 X1270 IGP. =C2=A0=C2=A0=C2=A0 -jr _______________________________________________ freebsd-current@freebsd.org mailing list http://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 Feb 22 12:13:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F19F8BA for ; Sun, 22 Feb 2015 12:13:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEDC929 for ; Sun, 22 Feb 2015 12:13:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D3667A8A for ; Sun, 22 Feb 2015 12:13:16 +0000 (UTC) Date: Sun, 22 Feb 2015 12:13:16 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1600200767.31.1424607196115.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1948528528.30.1424599553523.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1948528528.30.1424599553523.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #744 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 12:13:17 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 16:41:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC1D3523 for ; Sun, 22 Feb 2015 16:41:07 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A4A5845 for ; Sun, 22 Feb 2015 16:41:07 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id y19so21432618wgg.13 for ; Sun, 22 Feb 2015 08:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=nQFIHD80TvPxA5nHOMnd9rf3GjsgguFGthgFFPhR+n8=; b=C6uLFZ4wXQmSnJzlG6XAI+sx3nK4maSVlQaDTGsYzWnkxIcqMQgxg0hpjFjLG+37f5 DnNO8+rfXZnLXNsX1cOCtm1N3rbTwCxAY/i55dHPzFF+Jc5Se/Z+fsZdexYfcbd20NjH nmtfOTuDS30PY2ydQ4GnJpyLrq7U/ezcZSSMdFTSz5VnfB80L9wlR0tGZpz0wefuVq5v 6vLIEESP13Yh2EU4rv09TiRhqlOyhU5vN9jO5th7r8qxdwLVY4KhcKof3ppucXS8osth sOXD2Gohp+GUUUphJjEXmadOxGJX0PWywvyvW97ap6TWkAifi4Jr9QSLYTzU/LGhQ10g HbRg== X-Received: by 10.194.95.200 with SMTP id dm8mr14694943wjb.122.1424623265696; Sun, 22 Feb 2015 08:41:05 -0800 (PST) Received: from gumby.homeunix.com (4e5670d9.skybroadband.com. [78.86.112.217]) by mx.google.com with ESMTPSA id qo10sm51781206wjc.38.2015.02.22.08.41.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 08:41:04 -0800 (PST) Date: Sun, 22 Feb 2015 16:41:02 +0000 From: RW To: freebsd-current@freebsd.org Subject: Re: default pager (csh) Message-ID: <20150222164102.65893435@gumby.homeunix.com> In-Reply-To: <54E6AE88.3020302@ShaneWare.Biz> References: <021CBC62-4CC6-4137-897E-FE482139E09B@westryn.net> <201502190116.t1J1GxAw028289@mail.karels.net> <20150219145251.7f6b4fd5@gumby.homeunix.com> <54E6AE88.3020302@ShaneWare.Biz> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 16:41:07 -0000 On Fri, 20 Feb 2015 14:18:24 +1030 Shane Ambler wrote: > On 20/02/2015 01:22, RW wrote: > > On Wed, 18 Feb 2015 19:16:59 -0600 > > Mike Karels wrote: > > > > > >> Trivia: the version of more on BSD systems actually is derived from > >> less, not the original version of more. > > > > Actually, more is less > > > > $ md5 -r `which less ` `which more ` > > 50404f1beaa4e1261407190a88494b59 /usr/bin/less > > 50404f1beaa4e1261407190a88494b59 /usr/bin/more > > Yes more has been less for some time, trouble is it is programmed to > behave differently based on the name used to call it so they aren't > the same. I'm aware of that. > Like everything, if you don't like the way it works you find a setting > to make it work the way you want. Whether you ask on a mailing list or > google it you will find a way to configure it your way. > > As long as it works, the default is of little concern to most. Whatever the choice of default pager, I think the defaults should be set-up so man doesn't exit at the bottom of a page. The fact that it's easy to change make it all the more obtuse have a default that's awkward for new users who want to read the documentation. From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 17:34:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 959A3D86 for ; Sun, 22 Feb 2015 17:34:35 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 73DC1CF3 for ; Sun, 22 Feb 2015 17:34:35 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1649E192A3B; Sun, 22 Feb 2015 17:34:30 +0000 (UTC) Message-ID: <54EA1325.6070009@ignoranthack.me> Date: Sun, 22 Feb 2015 09:34:29 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on application core dump? References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> In-Reply-To: <20150221211712.GG74514@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 17:34:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Err. Is it easily reproducable in your setup ? The core file vnode > is indeed unreferenced before notification is sent. > > Try this. > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index > 41da3dd..57f66b0 100644 Restarted my non-deterministic test case. Three instances of qemu core dumped and the system did *not* panic. However, this appears to be interfering with signal handling and reaping. Applications seems to stall out and become unkillable/unreapable. I have to reboot the system via panic/reset. sean last pid: 41009; load averages: 0.46, 0.29, 0.21 up 0+12:18:57 17:33:37 72 processes: 1 running, 69 sleeping, 2 zombie CPU: 0.9% user, 0.0% nice, 0.2% system, 0.0% interrupt, 98.8% idle Mem: 15M Active, 6675M Inact, 7201M Wired, 244K Cache, 2010M Free ARC: 4678M Total, 910M MFU, 3001M MRU, 6748K Anon, 70M Header, 691M Other Swap: 16G Total, 16G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 718 www 1 20 0 28708K 6636K kqread 12 0:08 0.70% nginx 1430 root 1 52 0 17180K 3448K wait 13 2:28 0.44% sh 1276 sbruno 1 20 0 21548K 8796K select 11 4:37 0.17% tmux 40832 root 1 20 0 22000K 3072K CPU7 7 0:00 0.08% top 1267 sbruno 1 20 0 86528K 7580K select 15 0:04 0.02% sshd 695 root 1 20 0 25496K 4884K select 9 0:03 0.01% ntpd 698 root 1 20 0 14492K 1992K select 7 0:04 0.01% powerd 1288 root 1 20 0 17180K 5336K zfs 14 1:13 0.00% sh 79939 root 1 52 0 17180K 3384K wait 10 0:03 0.00% sh 750 root 1 20 0 24164K 5444K select 2 0:01 0.00% sendmail 444 unbound 1 20 0 34780K 9672K select 7 0:00 0.00% unbound 40727 root 1 20 0 17180K 5276K wait 14 0:00 0.00% sh 68893 root 1 26 0 17180K 5336K wait 3 0:00 0.00% sh 80937 root 1 24 0 17180K 5336K wait 13 0:00 0.00% sh 55102 root 1 24 0 17180K 5336K wait 3 0:00 0.00% sh 35713 root 1 25 0 17180K 5336K wait 10 0:00 0.00% sh 48828 root 1 24 0 17180K 5336K wait 6 0:00 0.00% sh 97473 root 1 26 0 17180K 5336K wait 0 0:00 0.00% sh 64113 root 1 24 0 17180K 5336K wait 5 0:00 0.00% sh 46980 root 1 27 0 17180K 5336K wait 12 0:00 0.00% sh 80439 root 1 24 0 17180K 5336K wait 7 0:00 0.00% sh 44960 root 1 20 0 17180K 5276K wait 3 0:00 0.00% sh 49661 root 1 27 0 17180K 5336K wait 8 0:00 0.00% sh 78496 root 1 52 0 17180K 5336K zfs 0 0:00 0.00% sh 69491 root 1 27 0 17180K 5336K wait 6 0:00 0.00% sh 75907 root 1 52 0 17180K 5336K zfs 8 0:00 0.00% sh 534 root 1 20 0 14524K 2200K select 12 0:00 0.00% syslogd 757 root 1 52 0 16620K 2296K nanslp 13 0:00 0.00% cron 747 root 1 20 0 59148K 6620K select 6 0:00 0.00% sshd 26179 root 1 31 0 23652K 4044K pause 14 0:00 0.00% csh 79371 root 1 20 0 17180K 5336K wait 9 0:00 0.00% sh 1268 sbruno 1 23 0 23652K 3736K pause 5 0:00 0.00% tcsh 1265 root 1 22 0 86528K 7284K select 11 0:00 0.00% sshd 1283 root 1 21 0 23652K 4044K pause 3 0:00 0.00% csh 1277 sbruno 1 23 0 23652K 3748K pause 6 0:00 0.00% tcsh 1282 sbruno 1 21 0 74188K 6348K wait 11 0:00 0.00% su 24565 sbruno 1 20 0 23652K 3740K pause 8 0:00 0.00% tcsh 438 root 1 20 0 13588K 4788K select 11 0:00 0.00% devd 26119 sbruno 1 20 0 74188K 6348K wait 13 0:00 0.00% su 753 smmsp 1 20 0 24164K 5392K pause 1 0:00 0.00% sendmail -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU6hMhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k6sUIALJrfTWiIC2EeAuV/aedWGuM 6XP97oXAp3iFNEyz/4yli6Hoev7AG9lbxh/ruhzKUi1O5tGQye0gIBwdqGrOL5tA mEjS8EAylc2WJsPbOHnctT/JUgaOle5j4HTlV8r7t8XSPjjoktc9uBwQQ7n+XlI3 AK4aOspxZSTk7WaGWM5cBDHV/Ga+6VgFGXi6i2/Y9zpW93vuCCCDfvpyQqGOoAGq LJk9hZmDdJMBO6n0HbPm20xKv0lDQsK9HIx2grD7xz5FPwVOFTMHwQrgnEqlpTPq b1Aex0MPqSTaUlZs8W6jY5C9ze8FEbLG15E0zj1ZMISPVJwrH7XPP8Jq57BqVo0= =JrKS -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 18:04:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02C166DA; Sun, 22 Feb 2015 18:04:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 805C8FA1; Sun, 22 Feb 2015 18:04:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1MI4Qnu047133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2015 20:04:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1MI4Qnu047133 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1MI4PZq047132; Sun, 22 Feb 2015 20:04:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Feb 2015 20:04:25 +0200 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: panic on application core dump? Message-ID: <20150222180425.GJ74514@kib.kiev.ua> References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EA1325.6070009@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 18:04:33 -0000 On Sun, Feb 22, 2015 at 09:34:29AM -0800, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Err. Is it easily reproducable in your setup ? The core file vnode > > is indeed unreferenced before notification is sent. > > > > Try this. > > > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index > > 41da3dd..57f66b0 100644 > > Restarted my non-deterministic test case. Three instances of qemu > core dumped and the system did *not* panic. > > However, this appears to be interfering with signal handling and > reaping. Applications seems to stall out and become > unkillable/unreapable. I have to reboot the system via panic/reset. > What applications ? What is the (kernel) backtrace for the ? > sean > > last pid: 41009; load averages: 0.46, 0.29, 0.21 > > > up 0+12:18:57 17:33:37 > 72 processes: 1 running, 69 sleeping, 2 zombie > CPU: 0.9% user, 0.0% nice, 0.2% system, 0.0% interrupt, 98.8% idle > Mem: 15M Active, 6675M Inact, 7201M Wired, 244K Cache, 2010M Free > ARC: 4678M Total, 910M MFU, 3001M MRU, 6748K Anon, 70M Header, 691M Other > Swap: 16G Total, 16G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 718 www 1 20 0 28708K 6636K kqread 12 0:08 0.70% > nginx > 1430 root 1 52 0 17180K 3448K wait 13 2:28 0.44% sh > 1276 sbruno 1 20 0 21548K 8796K select 11 4:37 0.17% tmux > 40832 root 1 20 0 22000K 3072K CPU7 7 0:00 0.08% top > 1267 sbruno 1 20 0 86528K 7580K select 15 0:04 0.02% sshd > 695 root 1 20 0 25496K 4884K select 9 0:03 0.01% ntpd > 698 root 1 20 0 14492K 1992K select 7 0:04 0.01% > powerd > 1288 root 1 20 0 17180K 5336K zfs 14 1:13 0.00% sh Is this the problem ^^^^ ? If yes, do you have ddb compiled in ? Show the output of 'show lockedvnods' and 'show alllocks'. > 79939 root 1 52 0 17180K 3384K wait 10 0:03 0.00% sh > 750 root 1 20 0 24164K 5444K select 2 0:01 0.00% > sendmail > 444 unbound 1 20 0 34780K 9672K select 7 0:00 0.00% > unbound > 40727 root 1 20 0 17180K 5276K wait 14 0:00 0.00% sh > 68893 root 1 26 0 17180K 5336K wait 3 0:00 0.00% sh > 80937 root 1 24 0 17180K 5336K wait 13 0:00 0.00% sh > 55102 root 1 24 0 17180K 5336K wait 3 0:00 0.00% sh > 35713 root 1 25 0 17180K 5336K wait 10 0:00 0.00% sh > 48828 root 1 24 0 17180K 5336K wait 6 0:00 0.00% sh > 97473 root 1 26 0 17180K 5336K wait 0 0:00 0.00% sh > 64113 root 1 24 0 17180K 5336K wait 5 0:00 0.00% sh > 46980 root 1 27 0 17180K 5336K wait 12 0:00 0.00% sh > 80439 root 1 24 0 17180K 5336K wait 7 0:00 0.00% sh > 44960 root 1 20 0 17180K 5276K wait 3 0:00 0.00% sh > 49661 root 1 27 0 17180K 5336K wait 8 0:00 0.00% sh > 78496 root 1 52 0 17180K 5336K zfs 0 0:00 0.00% sh > 69491 root 1 27 0 17180K 5336K wait 6 0:00 0.00% sh > 75907 root 1 52 0 17180K 5336K zfs 8 0:00 0.00% sh > 534 root 1 20 0 14524K 2200K select 12 0:00 0.00% > syslogd > 757 root 1 52 0 16620K 2296K nanslp 13 0:00 0.00% cron > 747 root 1 20 0 59148K 6620K select 6 0:00 0.00% sshd > 26179 root 1 31 0 23652K 4044K pause 14 0:00 0.00% csh > 79371 root 1 20 0 17180K 5336K wait 9 0:00 0.00% sh > 1268 sbruno 1 23 0 23652K 3736K pause 5 0:00 0.00% tcsh > 1265 root 1 22 0 86528K 7284K select 11 0:00 0.00% sshd > 1283 root 1 21 0 23652K 4044K pause 3 0:00 0.00% csh > 1277 sbruno 1 23 0 23652K 3748K pause 6 0:00 0.00% tcsh > 1282 sbruno 1 21 0 74188K 6348K wait 11 0:00 0.00% su > 24565 sbruno 1 20 0 23652K 3740K pause 8 0:00 0.00% tcsh > 438 root 1 20 0 13588K 4788K select 11 0:00 0.00% devd > 26119 sbruno 1 20 0 74188K 6348K wait 13 0:00 0.00% su > 753 smmsp 1 20 0 24164K 5392K pause 1 0:00 0.00% > sendmail From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 18:20:49 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0D8A3B for ; Sun, 22 Feb 2015 18:20:49 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53FE51BF for ; Sun, 22 Feb 2015 18:20:49 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 1FDE21CC22 for ; Sun, 22 Feb 2015 13:20:47 -0500 (EST) Message-ID: <54EA1DFC.1050304@protected-networks.net> Date: Sun, 22 Feb 2015 13:20:44 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Fwd: SVN r379206 breaks www/webkit-gtk3 References: <54E5E171.90003@protected-networks.net> In-Reply-To: <54E5E171.90003@protected-networks.net> OpenPGP: id=0442D492 X-Forwarded-Message-Id: <54E5E171.90003@protected-networks.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XGlm53FBBtIDtxQSkQKnUWUGiUUu2AIxc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 18:20:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XGlm53FBBtIDtxQSkQKnUWUGiUUu2AIxc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Any ideas on this would be helpful: -------- Forwarded Message -------- Subject: SVN r379206 breaks www/webkit-gtk3 Date: Thu, 19 Feb 2015 08:13:21 -0500 From: Michael Butler To: kwm@freebsd.org The most recent update to webkit-gtk3 breaks on -CURRENT as follows: CXX Source/WTF/wtf/text/libWTF_la-WTFString.lo CXX Source/WTF/wtf/threads/libWTF_la-BinarySemaphore.lo CXX Source/WTF/wtf/unicode/libWTF_la-CollatorDefault.lo CXX Source/WTF/wtf/unicode/libWTF_la-UTF8.lo CXX Source/WTF/wtf/unicode/icu/libWTF_la-CollatorICU.lo GEN DerivedSources/WebCore/InspectorWebBackendDispatchers.cpp CXXLD libWTF.la CXXLD Programs/LLIntOffsetsExtractor /usr/bin/ld:./.libs/libWTF.a: file format not recognized; treating as linker script /usr/bin/ld:./.libs/libWTF.a:1: syntax error c++: error: linker command failed with exit code 1 (use -v to see invocation) GNUmakefile:40539: recipe for target 'Programs/LLIntOffsetsExtractor' fai= led gmake[2]: *** [Programs/LLIntOffsetsExtractor] Error 1 gmake[2]: Leaving directory '/usr/ports/www/webkit-gtk3/work/webkitgtk-2.4.8' =3D=3D=3D> Compilation failed unexpectedly. imb --XGlm53FBBtIDtxQSkQKnUWUGiUUu2AIxc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTqHfwACgkQQv9rrgRC1JLvXQCfWAAhDNmxA5au3lxzy9mU0eai X7sAoKnX5gw/KbIZJXuN+OtCp380qI/y =oBYW -----END PGP SIGNATURE----- --XGlm53FBBtIDtxQSkQKnUWUGiUUu2AIxc-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 18:46:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9E92B9 for ; Sun, 22 Feb 2015 18:46:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 979E25E4 for ; Sun, 22 Feb 2015 18:46:57 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 171CE192A3B; Sun, 22 Feb 2015 18:46:54 +0000 (UTC) Message-ID: <54EA241D.6020606@ignoranthack.me> Date: Sun, 22 Feb 2015 10:46:53 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on application core dump? References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> In-Reply-To: <20150222180425.GJ74514@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 18:46:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/22/15 10:04, Konstantin Belousov wrote: > On Sun, Feb 22, 2015 at 09:34:29AM -0800, Sean Bruno wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >>> Err. Is it easily reproducable in your setup ? The core file >>> vnode is indeed unreferenced before notification is sent. >>> >>> Try this. >>> >>> diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index >>> 41da3dd..57f66b0 100644 >> >> Restarted my non-deterministic test case. Three instances of >> qemu core dumped and the system did *not* panic. >> >> However, this appears to be interfering with signal handling and >> reaping. Applications seems to stall out and become >> unkillable/unreapable. I have to reboot the system via >> panic/reset. >> > What applications ? What is the (kernel) backtrace for the ? > Most of the waiting applications are shells scripts: root 40727 0.0 0.0 17180 5276 1 I+ 9:20AM 0:00.18 /bin/sh /usr/local/share/poudriere/bulk.sh -j 11mips64 -p 11mips32 -ac db> trace 47027 Tracing pid 47027 tid 100835 td 0xfffff80018cae4a0 sched_switch() at sched_switch+0x326/frame 0xfffffe046a1446f0 mi_switch() at mi_switch+0xde/frame 0xfffffe046a144730 sleepq_catch_signals() at sleepq_catch_signals+0xab/frame 0xfffffe046a1447b0 sleepq_wait_sig() at sleepq_wait_sig+0xf/frame 0xfffffe046a1447e0 _cv_wait_sig() at _cv_wait_sig+0x1b0/frame 0xfffffe046a144830 seltdwait() at seltdwait+0x104/frame 0xfffffe046a144880 kern_select() at kern_select+0x963/frame 0xfffffe046a144a90 sys_select() at sys_select+0x54/frame 0xfffffe046a144ad0 amd64_syscall() at amd64_syscall+0x3e7/frame 0xfffffe046a144bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046a144bf0 >> 1288 root 1 20 0 17180K 5336K zfs 14 1:13 >> 0.00% sh > Is this the problem ^^^^ ? > > If yes, do you have ddb compiled in ? Show the output of 'show > lockedvnods' and 'show alllocks'. Hmm ... looks unrelated to signals (maybe). This looks like a common ZFS deadlock that is yet undiagnosed. I do not have a show alllocks command available in db> . I will show each lock information below: db> show lockedvnods Locked vnodes 0xfffff801141a6588: tag zfs, type VDIR usecount 19, writecount 0, refcount 20 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) v_object 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, sh, tid 101262) with exclusive waiters pending 0xfffff800184c8b10: tag zfs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xfffff80355409300 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffff8001863d000 (pid 94699, rm, tid 100930) with exclusive waiters pending 0xfffff80404d47b10: tag zfs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags (VI_ACTIVE) lock type zfs: EXCL by thread 0xfffff80013b29000 (pid 94698, rm, tid 100772) with exclusive waiters pending 0xfffff802ec2b5000: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags (VI_ACTIVE) lock type zfs: EXCL by thread 0xfffff801ca106940 (pid 94700, mv, tid 101021) with exclusive waiters pending db> show lock 0xfffff801141a6588 class: sleep mutex name: zfs flags: {DEF, DUPOK} state: {OWNED} KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0456b0e050 kdb_reenter() at kdb_reenter+0x33/frame 0xfffffe0456b0e060 trap() at trap+0x54/frame 0xfffffe0456b0e270 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e270 - --- trap 0xc, rip = 0xffffffff809b2c37, rsp = 0xfffffe0456b0e330, rbp = 0xfffffe0456b0e350 --- db_show_mtx() at db_show_mtx+0x127/frame 0xfffffe0456b0e350 db_command() at db_command+0x27c/frame 0xfffffe0456b0e410 db_command_loop() at db_command_loop+0x64/frame 0xfffffe0456b0e420 db_trap() at db_trap+0xe0/frame 0xfffffe0456b0e4b0 kdb_trap() at kdb_trap+0x18e/frame 0xfffffe0456b0e540 trap() at trap+0x447/frame 0xfffffe0456b0e750 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e750 - --- trap 0x3, rip = 0xffffffff80a0ee87, rsp = 0xfffffe0456b0e810, rbp = 0xfffffe0456b0e840 --- kdb_alt_break_internal() at kdb_alt_break_internal+0x197/frame 0xfffffe0456b0e840 kdb_alt_break() at kdb_alt_break+0xb/frame 0xfffffe0456b0e850 uart_intr_rxready() at uart_intr_rxready+0x99/frame 0xfffffe0456b0e880 uart_intr() at uart_intr+0x111/frame 0xfffffe0456b0e8c0 intr_event_handle() at intr_event_handle+0x9b/frame 0xfffffe0456b0e910 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0456b0e940 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe0456b0e960 Xapic_isr1() at Xapic_isr1+0xba/frame 0xfffffe0456b0e960 - --- interrupt, rip = 0xffffffff80384913, rsp = 0xfffffe0456b0ea20, rbp = 0xfffffe0456b0ea70 --- acpi_cpu_idle() at acpi_cpu_idle+0x2b3/frame 0xfffffe0456b0ea70 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0456b0ea90 cpu_idle() at cpu_idle+0x90/frame 0xfffffe0456b0eab0 sched_idletd() at sched_idletd+0x40b/frame 0xfffffe0456b0ebb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0456b0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0456b0ebf0 - --- trap 0, rip = 0, rsp = 0xfffffe0456b0ecb0, rbp = 0 --- db> show lock 0xfffff800184c8b10 class: sleep mutex name: zfs flags: {DEF, DUPOK} state: {OWNED} KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0456b0e050 kdb_reenter() at kdb_reenter+0x33/frame 0xfffffe0456b0e060 trap() at trap+0x54/frame 0xfffffe0456b0e270 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e270 - --- trap 0xc, rip = 0xffffffff809b2c37, rsp = 0xfffffe0456b0e330, rbp = 0xfffffe0456b0e350 --- db_show_mtx() at db_show_mtx+0x127/frame 0xfffffe0456b0e350 db_command() at db_command+0x27c/frame 0xfffffe0456b0e410 db_command_loop() at db_command_loop+0x64/frame 0xfffffe0456b0e420 db_trap() at db_trap+0xe0/frame 0xfffffe0456b0e4b0 kdb_trap() at kdb_trap+0x18e/frame 0xfffffe0456b0e540 trap() at trap+0x447/frame 0xfffffe0456b0e750 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e750 - --- trap 0x3, rip = 0xffffffff80a0ee87, rsp = 0xfffffe0456b0e810, rbp = 0xfffffe0456b0e840 --- kdb_alt_break_internal() at kdb_alt_break_internal+0x197/frame 0xfffffe0456b0e840 kdb_alt_break() at kdb_alt_break+0xb/frame 0xfffffe0456b0e850 uart_intr_rxready() at uart_intr_rxready+0x99/frame 0xfffffe0456b0e880 uart_intr() at uart_intr+0x111/frame 0xfffffe0456b0e8c0 intr_event_handle() at intr_event_handle+0x9b/frame 0xfffffe0456b0e910 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0456b0e940 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe0456b0e960 Xapic_isr1() at Xapic_isr1+0xba/frame 0xfffffe0456b0e960 - --- interrupt, rip = 0xffffffff80384913, rsp = 0xfffffe0456b0ea20, rbp = 0xfffffe0456b0ea70 --- acpi_cpu_idle() at acpi_cpu_idle+0x2b3/frame 0xfffffe0456b0ea70 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0456b0ea90 cpu_idle() at cpu_idle+0x90/frame 0xfffffe0456b0eab0 sched_idletd() at sched_idletd+0x40b/frame 0xfffffe0456b0ebb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0456b0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0456b0ebf0 - --- trap 0, rip = 0, rsp = 0xfffffe0456b0ecb0, rbp = 0 --- db> show lock 0xfffff80404d47b10 class: sleep mutex name: zfs flags: {DEF, DUPOK} state: {OWNED} KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0456b0e050 kdb_reenter() at kdb_reenter+0x33/frame 0xfffffe0456b0e060 trap() at trap+0x54/frame 0xfffffe0456b0e270 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e270 - --- trap 0xc, rip = 0xffffffff809b2c37, rsp = 0xfffffe0456b0e330, rbp = 0xfffffe0456b0e350 --- db_show_mtx() at db_show_mtx+0x127/frame 0xfffffe0456b0e350 db_command() at db_command+0x27c/frame 0xfffffe0456b0e410 db_command_loop() at db_command_loop+0x64/frame 0xfffffe0456b0e420 db_trap() at db_trap+0xe0/frame 0xfffffe0456b0e4b0 kdb_trap() at kdb_trap+0x18e/frame 0xfffffe0456b0e540 trap() at trap+0x447/frame 0xfffffe0456b0e750 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e750 - --- trap 0x3, rip = 0xffffffff80a0ee87, rsp = 0xfffffe0456b0e810, rbp = 0xfffffe0456b0e840 --- kdb_alt_break_internal() at kdb_alt_break_internal+0x197/frame 0xfffffe0456b0e840 kdb_alt_break() at kdb_alt_break+0xb/frame 0xfffffe0456b0e850 uart_intr_rxready() at uart_intr_rxready+0x99/frame 0xfffffe0456b0e880 uart_intr() at uart_intr+0x111/frame 0xfffffe0456b0e8c0 intr_event_handle() at intr_event_handle+0x9b/frame 0xfffffe0456b0e910 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0456b0e940 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe0456b0e960 Xapic_isr1() at Xapic_isr1+0xba/frame 0xfffffe0456b0e960 - --- interrupt, rip = 0xffffffff80384913, rsp = 0xfffffe0456b0ea20, rbp = 0xfffffe0456b0ea70 --- acpi_cpu_idle() at acpi_cpu_idle+0x2b3/frame 0xfffffe0456b0ea70 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0456b0ea90 cpu_idle() at cpu_idle+0x90/frame 0xfffffe0456b0eab0 sched_idletd() at sched_idletd+0x40b/frame 0xfffffe0456b0ebb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0456b0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0456b0ebf0 - --- trap 0, rip = 0, rsp = 0xfffffe0456b0ecb0, rbp = 0 --- db> show lock 0xfffff802ec2b5000 class: sleep mutex name: zfs flags: {DEF, DUPOK} state: {OWNED} KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0456b0e050 kdb_reenter() at kdb_reenter+0x33/frame 0xfffffe0456b0e060 trap() at trap+0x54/frame 0xfffffe0456b0e270 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e270 - --- trap 0xc, rip = 0xffffffff809b2c37, rsp = 0xfffffe0456b0e330, rbp = 0xfffffe0456b0e350 --- db_show_mtx() at db_show_mtx+0x127/frame 0xfffffe0456b0e350 db_command() at db_command+0x27c/frame 0xfffffe0456b0e410 db_command_loop() at db_command_loop+0x64/frame 0xfffffe0456b0e420 db_trap() at db_trap+0xe0/frame 0xfffffe0456b0e4b0 kdb_trap() at kdb_trap+0x18e/frame 0xfffffe0456b0e540 trap() at trap+0x447/frame 0xfffffe0456b0e750 calltrap() at calltrap+0x8/frame 0xfffffe0456b0e750 - --- trap 0x3, rip = 0xffffffff80a0ee87, rsp = 0xfffffe0456b0e810, rbp = 0xfffffe0456b0e840 --- kdb_alt_break_internal() at kdb_alt_break_internal+0x197/frame 0xfffffe0456b0e840 kdb_alt_break() at kdb_alt_break+0xb/frame 0xfffffe0456b0e850 uart_intr_rxready() at uart_intr_rxready+0x99/frame 0xfffffe0456b0e880 uart_intr() at uart_intr+0x111/frame 0xfffffe0456b0e8c0 intr_event_handle() at intr_event_handle+0x9b/frame 0xfffffe0456b0e910 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0456b0e940 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe0456b0e960 Xapic_isr1() at Xapic_isr1+0xba/frame 0xfffffe0456b0e960 - --- interrupt, rip = 0xffffffff80384913, rsp = 0xfffffe0456b0ea20, rbp = 0xfffffe0456b0ea70 --- acpi_cpu_idle() at acpi_cpu_idle+0x2b3/frame 0xfffffe0456b0ea70 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0456b0ea90 cpu_idle() at cpu_idle+0x90/frame 0xfffffe0456b0eab0 sched_idletd() at sched_idletd+0x40b/frame 0xfffffe0456b0ebb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0456b0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0456b0ebf0 - --- trap 0, rip = 0, rsp = 0xfffffe0456b0ecb0, rbp = 0 --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU6iQYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k/FoH/RmoZu8qhcXYbGgsrWhVerdb 5yuEwokj83FsP/JJU3ABa5cC+xkI06/BAkgn4jQjCJOfLR/1kwh1eRWSSBTcL3qj kDF3thQN6GP/p2l3UNUCOY3YFMsxMfa5tguAvgPFVBjEKa8rnqOlvYUbMXbo5UoB 2xBP+FOV808fV7a3UuATOn1w6FFg0e9n44BWnj9blGA6d0wKkdwmAd6KgDckyH6R LPPx9atnm/7xtQ4ZM2NMR4IbPUw8h38Yzb/RQhCPvUR+lbrSzPD3tlD57ATKWBAA p70JVaMa/tZW9Faad2mDQCCmlxQYQ8oGdDqkuh8qtBCLHTKUiE5N6Tu+wXePR3g= =gk/L -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 18:53:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 510859CA; Sun, 22 Feb 2015 18:53:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 CF76D6D9; Sun, 22 Feb 2015 18:53:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1MIrqkm058376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2015 20:53:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1MIrqkm058376 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1MIrqkJ058375; Sun, 22 Feb 2015 20:53:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Feb 2015 20:53:52 +0200 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: panic on application core dump? Message-ID: <20150222185352.GL74514@kib.kiev.ua> References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> <54EA241D.6020606@ignoranthack.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EA241D.6020606@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 18:53:57 -0000 On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: > Hmm ... looks unrelated to signals (maybe). This looks like a common > ZFS deadlock that is yet undiagnosed. I do not have a show alllocks > command available in db> . I will show each lock information below: Add witness. > > db> show lockedvnods > Locked vnodes > > 0xfffff801141a6588: tag zfs, type VDIR > usecount 19, writecount 0, refcount 20 mountedhere 0 > flags (VV_ROOT|VI_ACTIVE) > v_object 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > lock type zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, sh, > tid 101262) > with exclusive waiters pending Without backtraces of the acquisition, it is not useful. You need DEBUG_VFS_LOCKS for this. From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 18:54:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2AB0C5A for ; Sun, 22 Feb 2015 18:54:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 AFDE675A for ; Sun, 22 Feb 2015 18:54:57 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 3E1DB192A3B; Sun, 22 Feb 2015 18:54:55 +0000 (UTC) Message-ID: <54EA25FE.60401@ignoranthack.me> Date: Sun, 22 Feb 2015 10:54:54 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on application core dump? References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> <54EA241D.6020606@ignoranthack.me> <20150222185352.GL74514@kib.kiev.ua> In-Reply-To: <20150222185352.GL74514@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 18:54:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/22/15 10:53, Konstantin Belousov wrote: > On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: >> Hmm ... looks unrelated to signals (maybe). This looks like a >> common ZFS deadlock that is yet undiagnosed. I do not have a >> show alllocks command available in db> . I will show each lock >> information below: > Add witness. > >> >> db> show lockedvnods Locked vnodes >> >> 0xfffff801141a6588: tag zfs, type VDIR usecount 19, writecount 0, >> refcount 20 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) v_object >> 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type >> zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, sh, tid >> 101262) with exclusive waiters pending > Without backtraces of the acquisition, it is not useful. You need > DEBUG_VFS_LOCKS for this. > > Thank you. I will do so and restart my non-determinstic test and see what I can find. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU6iX7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kw+wH/3lcy7AJOvOu3cIQilxmfovt rplhxp/t5lYVRS76FyBM9FekYtLZhK3uFyL2ZdEYNh11hjuitFXfaoADrZgyXvzI SxJhjKy3Zhqt8reeLvKM9MhhdyNWNrbufhB4mqsmamtCDKh7jQ7EDIRsES9EzBon brzZObtFTCNZgulQiTAWZZKNz0NH9hyJoPw9yHfXNTgVyLCkOBDDfCLLthiMd6l0 0RITV3CZ3W3RJvFWAnYU7iWaLWATEzOzPLhegRLG5G2P1khCxsYOH7+1BbOpF86N PCg49DuEsjhlhJrbX+CqRDb1oGI0/Gt+HE/RGkoCj77Ow98jyIH3Jg5vmhBJYN0= =2Fjt -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 21:14:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B52875A3 for ; Sun, 22 Feb 2015 21:14:06 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A05CD7A0 for ; Sun, 22 Feb 2015 21:14:06 +0000 (UTC) Received: from [10.0.1.100] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 3E795341F916; Sun, 22 Feb 2015 13:14:00 -0800 (PST) Subject: Re: default pager (csh) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alfred Perlstein In-Reply-To: <20150222164102.65893435@gumby.homeunix.com> Date: Sun, 22 Feb 2015 13:17:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <021CBC62-4CC6-4137-897E-FE482139E09B@westryn.net> <201502190116.t1J1GxAw028289@mail.karels.net> <20150219145251.7f6b4fd5@gumby.homeunix.com> <54E6AE88.3020302@ShaneWare.Biz> <20150222164102.65893435@gumby.homeunix.com> To: RW X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 21:14:06 -0000 On Feb 22, 2015, at 8:41 AM, RW wrote: > On Fri, 20 Feb 2015 14:18:24 +1030 > Shane Ambler wrote: >=20 >> On 20/02/2015 01:22, RW wrote: =20 >>> On Wed, 18 Feb 2015 19:16:59 -0600 >>> Mike Karels wrote: >>>=20 >>>=20 >>>> Trivia: the version of more on BSD systems actually is derived from >>>> less, not the original version of more. =20 >>>=20 >>> Actually, more is less >>>=20 >>> $ md5 -r `which less ` `which more ` >>> 50404f1beaa4e1261407190a88494b59 /usr/bin/less >>> 50404f1beaa4e1261407190a88494b59 /usr/bin/more =20 >>=20 >> Yes more has been less for some time, trouble is it is programmed to >> behave differently based on the name used to call it so they aren't >> the same. =20 >=20 > I'm aware of that. >=20 >=20 >> Like everything, if you don't like the way it works you find a = setting >> to make it work the way you want. Whether you ask on a mailing list = or >> google it you will find a way to configure it your way. >>=20 >> As long as it works, the default is of little concern to most. =20 >=20 > Whatever the choice of default pager, I think the defaults should be > set-up so man doesn't exit at the bottom of a page. The fact that it's > easy to change make it all the more obtuse have a default that's = awkward > for new users who want to read the documentation. +1 It's funny, our less doesn't bother telling people to hit 'q' to quit, = so it's poisoned on both sides unfortunately. -Alfred= From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 21:25:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D0C88D for ; Sun, 22 Feb 2015 21:25:54 +0000 (UTC) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBD78AA for ; Sun, 22 Feb 2015 21:25:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 365496003D0 for ; Sun, 22 Feb 2015 22:25:51 +0100 (CET) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaBLFNQFfGtX for ; Sun, 22 Feb 2015 22:25:50 +0100 (CET) Received: from elch.exwg.net (dslb-088-066-045-018.088.066.pools.vodafone-ip.de [88.66.45.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS for ; Sun, 22 Feb 2015 22:25:50 +0100 (CET) Received: by elch.exwg.net (Postfix, from userid 1000) id 5243C5E; Sun, 22 Feb 2015 22:25:50 +0100 (CET) Date: Sun, 22 Feb 2015 22:25:50 +0100 From: Christoph Moench-Tegeder To: freebsd-current@freebsd.org Subject: Re: Fwd: SVN r379206 breaks www/webkit-gtk3 Message-ID: <20150222212549.GA41448@elch.exwg.net> References: <54EA1DFC.1050304@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EA1DFC.1050304@protected-networks.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 21:25:54 -0000 ## Michael Butler (imb@protected-networks.net): > Subject: Fwd: SVN r379206 breaks www/webkit-gtk3 > CXXLD libWTF.la > CXXLD Programs/LLIntOffsetsExtractor > /usr/bin/ld:./.libs/libWTF.a: file format not recognized; treating as > linker script > /usr/bin/ld:./.libs/libWTF.a:1: syntax error > c++: error: linker command failed with exit code 1 (use -v to see > invocation) That's not new. This issue in webkit-gtk2 and webkit-gtk3 has been discussed before: https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/thread.html#97533 Regards, Christoph -- Spare Space From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 22:05:43 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E46E33FF for ; Sun, 22 Feb 2015 22:05:43 +0000 (UTC) Received: from bitmail.cc (bitmail.cc [84.201.3.213]) (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 AB70DCA5 for ; Sun, 22 Feb 2015 22:05:43 +0000 (UTC) Message-ID: <54EA5142.6040602@bitmail.cc> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitmail.cc; s=mail; t=1424642371; bh=9svXO6TbSdqKcJk/iGW9b/m96eNu0WAi/qLONh4TkwU=; h=Date:From:To:Subject:From; b=JPqOr64qLBFfciYnhjFPpFMn0yQLj9dR2YP90yVHJeNqRlwhuvcbr6GMpNQsH/2f4 2EV/AZgAfuwWuuhJOKlFREu0gjjCsRtkgstgMFP10qRtdZX8o3b48KGhE3W9Y2mQ6W J4camNkVqCvUP98dRauZ0XAp2mYvyv9S94zF/Rvc= Date: Sun, 22 Feb 2015 22:59:30 +0100 From: David S MIME-Version: 1.0 To: FreeBSD Current Subject: switching to vt causes a freeze Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 22:05:44 -0000 dear list, recently, when i'm compiling my -current box to the latest sources, i am greeting with this sight: https://i.imgur.com/QUG4AMr.jpg it happens after i type in "shutdown now". in preperation to do a "make installworld". this can be migitated by shuting down X prior to the operation (for example "service gdm stop"). no idea what is causing this, i'm running the propietary nvidia blob driver. greetings, david s From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 22:23:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1965A713 for ; Sun, 22 Feb 2015 22:23:54 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CFBD9E41 for ; Sun, 22 Feb 2015 22:23:53 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 6C7A41CC22; Sun, 22 Feb 2015 17:23:51 -0500 (EST) Message-ID: <54EA56F5.40504@protected-networks.net> Date: Sun, 22 Feb 2015 17:23:49 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christoph Moench-Tegeder , freebsd-current@freebsd.org Subject: Re: Fwd: SVN r379206 breaks www/webkit-gtk3 References: <54EA1DFC.1050304@protected-networks.net> <20150222212549.GA41448@elch.exwg.net> In-Reply-To: <20150222212549.GA41448@elch.exwg.net> OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jC6wa4HVxEfLNS2dOx0FXqFFUa7G2UNIr" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 22:23:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jC6wa4HVxEfLNS2dOx0FXqFFUa7G2UNIr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/22/15 16:25, Christoph Moench-Tegeder wrote: > That's not new. This issue in webkit-gtk2 and webkit-gtk3 has been > discussed before: > https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/thread.h= tml#97533 Ah - I'm not on that list - resolved, thanks! imb --jC6wa4HVxEfLNS2dOx0FXqFFUa7G2UNIr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTqVvYACgkQQv9rrgRC1JKonwCeJe1g93ZzMhbPk+xWiefpogX5 M4sAn3jHWbdcEAObIWpaJrAZOa4F3PtE =Smpv -----END PGP SIGNATURE----- --jC6wa4HVxEfLNS2dOx0FXqFFUa7G2UNIr-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 22 23:00:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1A09E63 for ; Sun, 22 Feb 2015 23:00:30 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 9CB07157 for ; Sun, 22 Feb 2015 23:00:29 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id E889D192A3B for ; Sun, 22 Feb 2015 23:00:27 +0000 (UTC) Message-ID: <54EA5F89.1010102@ignoranthack.me> Date: Sun, 22 Feb 2015 15:00:25 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: panic on application core dump? References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> <54EA241D.6020606@ignoranthack.me> <20150222185352.GL74514@kib.kiev.ua> <54EA25FE.60401@ignoranthack.me> In-Reply-To: <54EA25FE.60401@ignoranthack.me> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Feb 2015 23:00:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/22/15 10:54, Sean Bruno wrote: > On 02/22/15 10:53, Konstantin Belousov wrote: >> On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: >>> Hmm ... looks unrelated to signals (maybe). This looks like a >>> common ZFS deadlock that is yet undiagnosed. I do not have a >>> show alllocks command available in db> . I will show each >>> lock information below: >> Add witness. > >>> >>> db> show lockedvnods Locked vnodes >>> >>> 0xfffff801141a6588: tag zfs, type VDIR usecount 19, writecount >>> 0, refcount 20 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) >>> v_object 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >>> lock type zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, >>> sh, tid 101262) with exclusive waiters pending >> Without backtraces of the acquisition, it is not useful. You >> need DEBUG_VFS_LOCKS for this. > > > > Thank you. I will do so and restart my non-determinstic test and > see what I can find. > > sean _______________________ Well, that was certainly enlightening. I was able to get a WITNESS panic in imgact_binmisc.c in an hour or two. I need to *not* hold the mtx protecting the list of activators over the bcopy in imgact_binmisc_exec(). Jiles proposes that we switch to an sx lock here for simplicity of change of the code. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex imgact_binmisc (imgact_binmisc) r = 0 (0xffffffff82012418) locked @ /usr/src/sys/modules/imgact_binmisc/../../kern/imgact_binmisc.c:596 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046a236280 witness_warn() at witness_warn+0x4ae/frame 0xfffffe046a236350 trap_pfault() at trap_pfault+0x59/frame 0xfffffe046a2363f0 trap() at trap+0x45e/frame 0xfffffe046a236600 calltrap() at calltrap+0x8/frame 0xfffffe046a236600 - --- trap 0xc, rip = 0xffffffff80d21279, rsp = 0xfffffe046a2366c0, rbp = 0xfffffe046a2366d0 --- bcopy() at bcopy+0x39/frame 0xfffffe046a2366d0 imgact_binmisc_exec() at imgact_binmisc_exec+0x23d/frame 0xfffffe046a236720 kern_execve() at kern_execve+0x4c6/frame 0xfffffe046a236a80 sys_execve() at sys_execve+0x37/frame 0xfffffe046a236ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe046a236bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046a236bf0 - --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4297ba, rsp = 0x7fffffffdaf8, rbp = 0x7fffffffdb00 --- Fatal trap 12: page fault while in kernel mode cpuid = 13; apic id = 33 fault virtual address = 0xfffffe0456c01007 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80d21279 stack pointer = 0x28:0xfffffe046a2366c0 frame pointer = 0x28:0xfffffe046a2366d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27028 (cc) [ thread pid 27028 tid 100872 ] Stopped at bcopy+0x39: repe movsb (%rsi),%es:(%rdi) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU6l+GXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kG8kH/j6+UD8cf8rrLyd369eQQQmo ZTORZ9pAC6bMS9Dnu7VFpWGuelqFF9IXnjVml4QY4ieOBieavZYbfJ0nR3q+Htgh CRhvradu2yIBSbmW2sBPzIXsMn/XZCc6DAy21k5ieS29ksCL7wi9tDMVtcRZR2i5 rLowPix4M7MFoNASdPZepuLSnHyxHF00okeYFxaOzQ8sfyAA+zXYQjh5F8Xh0hRM M0HOF0J9nDxIZtueJSHDYSO94M0IxF+sMn/rmHznOFJZyNFfMY/zd9l9w+dx/8wW ve0WzZzGGfvYG9J80C6d1iEqIEDIS5tf7/VEwSWuR2cQFtsz3GUJJXI2+lzCl3s= =MwoX -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 01:23:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECF07C13; Mon, 23 Feb 2015 01:23:07 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 5E2B4250; Mon, 23 Feb 2015 01:23:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1N1Mwep045386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 03:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1N1Mwep045386 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1N1Mwni045385; Mon, 23 Feb 2015 03:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Feb 2015 03:22:58 +0200 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: panic on application core dump? Message-ID: <20150223012257.GO74514@kib.kiev.ua> References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> <54EA241D.6020606@ignoranthack.me> <20150222185352.GL74514@kib.kiev.ua> <54EA25FE.60401@ignoranthack.me> <54EA5F89.1010102@ignoranthack.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EA5F89.1010102@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 01:23:08 -0000 On Sun, Feb 22, 2015 at 03:00:25PM -0800, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/22/15 10:54, Sean Bruno wrote: > > On 02/22/15 10:53, Konstantin Belousov wrote: > >> On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: > >>> Hmm ... looks unrelated to signals (maybe). This looks like a > >>> common ZFS deadlock that is yet undiagnosed. I do not have a > >>> show alllocks command available in db> . I will show each > >>> lock information below: > >> Add witness. > > > >>> > >>> db> show lockedvnods Locked vnodes > >>> > >>> 0xfffff801141a6588: tag zfs, type VDIR usecount 19, writecount > >>> 0, refcount 20 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) > >>> v_object 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > >>> lock type zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, > >>> sh, tid 101262) with exclusive waiters pending > >> Without backtraces of the acquisition, it is not useful. You > >> need DEBUG_VFS_LOCKS for this. > > > > > > > > Thank you. I will do so and restart my non-determinstic test and > > see what I can find. > > > > sean _______________________ > > Well, that was certainly enlightening. I was able to get a WITNESS > panic in imgact_binmisc.c in an hour or two. I need to *not* hold the > mtx protecting the list of activators over the bcopy in > imgact_binmisc_exec(). > > Jiles proposes that we switch to an sx lock here for simplicity of > change of the code. > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex imgact_binmisc (imgact_binmisc) r = 0 > (0xffffffff82012418) locked @ > /usr/src/sys/modules/imgact_binmisc/../../kern/imgact_binmisc.c:596 So was it the reason for your troubles after the patch for handling core file' vnode refcount properly ? Or is there something more left ? From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 06:31:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC183647; Mon, 23 Feb 2015 06:31:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C844F1CC; Mon, 23 Feb 2015 06:31:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D9B69C3D; Mon, 23 Feb 2015 06:31:58 +0000 (UTC) Date: Mon, 23 Feb 2015 06:31:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ngie@FreeBSD.org Message-ID: <59685286.32.1424673118320.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2434 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 06:31:59 -0000 See Changes: [ngie] Parallelize building bootstrap-tools Differential Revision: https://reviews.freebsd.org/D1901 MFC after: 2 weeks Reviewed by: ian No serious objections from: imp ------------------------------------------ [...truncated 726 lines...] cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_loclist.o --- _bootstrap-tools-cddl/lib/libctf --- --- libctf.a --- building static ctf library ranlib -D libctf.a --- _bootstrap-tools-lib/libdwarf --- --- dwarf_macinfo.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_macinfo.o --- _bootstrap-tools-cddl/lib/libctf --- --- _libinstall --- sh -C -o= root -g wheel -m 444 libctf.a --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- =3D=3D=3D> cddl/usr.bin/ctfconvert (obj,depend,all,install) --- obj --- created for --- _bootstrap-tools-lib/libdwarf --- --- dwarf_pro_arange.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_arange.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- --- .depend --- rm -f .depend mkdep -f .depend -a -I -I -I -I -I -I -I -I -DNEED_= SOLARIS_BOOLEAN -I -std=3Dgnu99 = = = --- _bootstrap-tools-lib/libdwarf --- --- dwarf_pro_attr.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_attr.o --- dwarf_pro_die.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_die.o --- dwarf_pro_expr.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_expr.o --- dwarf_pro_finish.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_finish.o --- dwarf_pro_frame.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_frame.o --- dwarf_pro_init.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_init.o --- dwarf_pro_lineno.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_lineno.o --- dwarf_pro_macinfo.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_macinfo.o --- dwarf_pro_reloc.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_reloc.o --- dwarf_pro_sections.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_pro_sections.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- echo ctfconvert: /usr/lib/libc.a /usr/lib/libctf.a /usr/lib/libdwarf.a /usr= /lib/libelf.a /usr/lib/libz.a /usr/lib/libpthread.a >> .depend --- _bootstrap-tools-lib/libdwarf --- --- dwarf_ranges.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_ranges.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- --- alist.o --- cc -O2 -pipe -I -I -I -I -I -I -I -I -DNEED_SO= LARIS_BOOLEAN -g -std=3Dgnu99 -Qunused-arguments -I -= c --- _bootstrap-tools-lib/libdwarf --- --- dwarf_reloc.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_reloc.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- --- ctf.o --- cc -O2 -pipe -I -I -I -I -I -I -I -I -DNEED_SO= LARIS_BOOLEAN -g -std=3Dgnu99 -Qunused-arguments -I -= c --- _bootstrap-tools-lib/libdwarf --- --- dwarf_sections.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_sections.o --- dwarf_seterror.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_seterror.o --- dwarf_str.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o dwarf_str.o --- libdwarf.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o libdwarf.o --- libdwarf_abbrev.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o libdwarf_abbrev.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- --- ctfconvert.o --- cc -O2 -pipe -I -I -I -I -I -I -I -I -DNEED_SO= LARIS_BOOLEAN -g -std=3Dgnu99 -Qunused-arguments -I -= c --- _bootstrap-tools-lib/libdwarf --- --- libdwarf_arange.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o libdwarf_arange.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- --- dwarf.o --- cc -O2 -pipe -I -I -I -I -I -I -I -I -DNEED_SO= LARIS_BOOLEAN -g -std=3Dgnu99 -Qunused-arguments -I -= c --- _bootstrap-tools-lib/libdwarf --- --- libdwarf_attr.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -Qunused-arguments -I = -c -o libdwarf_attr.o --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- :271:19: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :289:37: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :306:37: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :320:37: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :343:37: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & --- _bootstrap-tools-lib/clang/libllvmtablegen --- --- libllvmtablegen.a --- --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :356:39: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :371:39: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :386:39: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :402:39: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ --- _bootstrap-tools-lib/clang/libllvmtablegen --- building static llvmtablegen library --- _bootstrap-tools-cddl/usr.bin/ctfconvert --- :417:40: warning: pas= sing 'Dwarf_Off *' (aka 'long *') to parameter of type 'Dwarf_Unsigned *' (= aka 'unsigned long *') converts between pointers to integer types with diff= erent sign [-Wpointer-sign] if (dwarf_attrval_unsigned(die, name, &off, &dw->dw_err) !=3D DW_DL= V_OK) { ^~~~ /usr/include/libdwarf.h:135:66: note: passing argument to parameter here int dwarf_attrval_unsigned(Dwarf_Die, uint64_t, Dwarf_Unsigned = *, Dwarf_Error *); = ^ :419:38: error: passi= ng 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible t= ype 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & die_off(dw, die), dwarf_errmsg(dw->dw_err)); ^~~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :505:7: error: use of= undeclared identifier 'DW_FORM_sec_offset' case DW_FORM_sec_offset: ^ :516:7: warning: impl= icit declaration of function 'dwarf_loclist' is invalid in C99 [-Wimplicit-= function-declaration] if (dwarf_loclist(at, &loc, &locnum, &dw->dw_err) !=3D DW_D= LV_OK) ^ :525:40: error: use o= f undeclared identifier 'DW_DLA_LOC_BLOCK' dwarf_dealloc(dw->dw_dw, loc->ld_s, DW_DLA_LOC_BLOC= K); ^ :526:34: error: use o= f undeclared identifier 'DW_DLA_LOCDESC' dwarf_dealloc(dw->dw_dw, loc, DW_DLA_LOCDESC); ^ :1950:57: error: too = many arguments to function call, expected 4, have 6 if ((rc =3D dwarf_elf_init(elf, DW_DLC_READ, NULL, NULL, &dw.dw_dw, ~~~~~~~~~~~~~~ ^~~~~~~~~~ /usr/include/libdwarf.h:139:1: note: 'dwarf_elf_init' declared here int dwarf_elf_init(Elf *, int, Dwarf_Debug *, Dwarf_Error *); ^ :1959:19: error: pass= ing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible = type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & if (dwarf_errno(dw.dw_err) =3D=3D DW_DLE_DEBUG_INFO_NULL) { ^~~~~~~~~ & /usr/include/libdwarf.h:140:31: note: passing argument to parameter here int dwarf_errno(Dwarf_Error *); ^ :1968:20: error: pass= ing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible = type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & dwarf_errmsg(dw.dw_err)); ^~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :1971:12: warning: im= plicit declaration of function 'dwarf_next_cu_header_b' is invalid in C99 [= -Wimplicit-function-declaration] if ((rc =3D dwarf_next_cu_header_b(dw.dw_dw, &hdrlen, &vers, &abbof= f, ^ :1973:46: error: pass= ing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to parameter of incompatible = type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); take the address with & terminate("rc =3D %d %s\n", rc, dwarf_errmsg(dw.dw_err)); ^~~~~~~~~ & /usr/include/libdwarf.h:122:39: note: passing argument to parameter here const char *dwarf_errmsg(Dwarf_Error *); ^ :2015:22: warning: in= compatible pointer types passing 'Dwarf_Debug' (aka 'struct _Dwarf_Debug *'= ) to parameter of type 'Dwarf_Debug *' (aka 'struct _Dwarf_Debug **'); take= the address with & [-Wincompatible-pointer-types] (void) dwarf_finish(dw.dw_dw, &dw.dw_err); ^~~~~~~~ & /usr/include/libdwarf.h:141:32: note: passing argument to parameter here int dwarf_finish(Dwarf_Debug *, Dwarf_Error *); ^ 4 warnings and 17 errors generated. *** [dwarf.o] Error code 1 make[3]: stopped in 1 error make[3]: stopped in --- _bootstrap-tools-lib/clang/libllvmtablegen --- ranlib -D libllvmtablegen.a --- _bootstrap-tools-lib/libdwarf --- A failure has been detected in another branch of the parallel make make[3]: stopped in --- _bootstrap-tools-lib/clang/libllvmtablegen --- A failure has been detected in another branch of the parallel make make[3]: stopped in --- _bootstrap-tools-lib/clang/libllvmsupport --- A failure has been detected in another branch of the parallel make make[3]: stopped in A failure has been detected in another branch of the parallel make make[2]: stopped in *** [_bootstrap-tools] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 08:00:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11509914 for ; Mon, 23 Feb 2015 08:00:29 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A73EB98 for ; Mon, 23 Feb 2015 08:00:28 +0000 (UTC) Received: by wesq59 with SMTP id q59so16378617wes.1 for ; Mon, 23 Feb 2015 00:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EvMEEoFOKZcI4Pi8mMZ8UC3IFSF2RywY3sgnmaDRnJQ=; b=hiEG3Ai+NquYHFWZ3icAueFTF3pai3XTHxT7Um8tq9V8ApwhOgiIICe9lZp+hEO2Eq ZOrIX6coHEWruuS1xMGvDxUehjlYXevJuBjlF0LmsxGMq8pqdg+9WAHCFEp+tP5p5sT/ OUzNNd7fCnJIQXoEvgNHglU8dMgOP068U9Q+xEFGTlOG94TV9x5t0qhqqFPIfsgNzCLk aZtuysCRDaLPSTvJf5R/RWgo8OxReVUZwcth7QpTN0b+bmYPp1Ivz635nCbJva5PwtdI S6SlGQFT8z15NkgQRUH8g3RHP1nAEgFcbZPC/iK4ziYd7Q/Sx6gN5lXiB0x1BeGQOlAE RzLg== X-Received: by 10.180.8.98 with SMTP id q2mr17614675wia.80.1424678426607; Mon, 23 Feb 2015 00:00:26 -0800 (PST) Received: from [192.168.1.46] (LAubervilliers-656-1-269-112.w193-248.abo.wanadoo.fr. [193.248.44.112]) by mx.google.com with ESMTPSA id fo9sm14678633wib.16.2015.02.23.00.00.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 00:00:25 -0800 (PST) Message-ID: <54EADE18.3030804@gmail.com> Date: Mon, 23 Feb 2015 09:00:24 +0100 From: David Demelier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: msk0 watchdog timeout Marvel 88E8071 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 08:00:29 -0000 Le 21/02/2015 23:46, Roosevelt Littleton a écrit : > My msk0 is not even functional and my wifi is my only usable connection to > the internet. > I have this in my loader.conf: hw.msk.msi_disable=1 hw.pci.enable_msix=0 > and this in my sysctl.conf net.inet.tcp.tso=0 > > vmstat -i > interrupt total rate > irq1: atkbd0 552 1 > irq9: acpi0 2561 3 > irq12: psm0 2322 3 > irq16: mskc0 2104711 2572 > irq20: hpet0 uhci0* 133497 163 > irq256: vgapci0 970 1 > irq257: hdac0 7680 9 > irq259: ahci0:ch0 526 1 > irq260: ahci0:ch1 100128 122 > irq264: ahci0:ch5 1739 2 > Total 2354686 2878 > > > > dmesg > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r279013: Thu Feb 19 22:30:02 EST 2015 > root@Mizraim:/usr/obj/usr/src/sys/ZENNLA amd64 > FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 > VT: running with driver "vga". > module_register: module pci/mskc already exists! > Module pci/mskc failed to register: 17 > module_register: module mskc/msk already exists! > Module mskc/msk failed to register: 17 > module_register: module msk/miibus already exists! > Module msk/miibus failed to register: 17 > CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 > > Features=0xbfebfbff > > Features2=0x8e3fd > AMD Features=0x20100800 > AMD Features2=0x1 > VT-x: HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > avail memory = 4076457984 (3887 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > module_register_init: MOD_LOAD (vesa, 0xffffffff80e77bc0, 0) error 19 > netmap: loaded module > random: SOFT: yarrow init() > random: selecting highest priority adaptor > vtvga0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x207f mem > 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff,0xf0000000-0xf1ffffff irq 16 at > device 0.0 on pci1 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: Boot video device > uhci0: port 0x1800-0x181f irq 20 at > device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x1820-0x183f irq 20 at > device 26.1 on pci0 > usbus1 on uhci1 > uhci2: port 0x1840-0x185f irq 20 at > device 26.2 on pci0 > usbus2 on uhci2 > ehci0: mem 0xf3504800-0xf3504bff > irq 20 at device 26.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > hdac0: mem 0xf3500000-0xf3503fff irq 21 at > device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > mskc0: port 0x3000-0x30ff mem > 0xf3000000-0xf3003fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Using defaults for TSO: 65518/35/2048 > msk0: Ethernet address: 00:1d:72:ed:56:80 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > pcib4: irq 18 at device 28.2 on pci0 > pci4: on pcib4 > iwn0: mem 0xf3100000-0xf3101fff irq 18 at device 0.0 > on pci4 > pcib5: irq 16 at device 28.4 on pci0 > pci5: on pcib5 > uhci3: port 0x1860-0x187f irq 23 at > device 29.0 on pci0 > usbus4 on uhci3 > uhci4: port 0x1880-0x189f irq 17 at > device 29.1 on pci0 > usbus5 on uhci4 > uhci5: port 0x18a0-0x18bf irq 18 at > device 29.2 on pci0 > usbus6 on uhci5 > ehci1: mem 0xf3504c00-0xf3504fff > irq 23 at device 29.7 on pci0 > usbus7: EHCI version 1.0 > usbus7 on ehci1 > pcib6: at device 30.0 on pci0 > pci13: on pcib6 > pci13: at device 6.0 (no driver attached) > sdhci_pci0: mem 0xf3202800-0xf32028ff irq 22 at device 6.2 > on pci13 > sdhci_pci0: 1 slot(s) allocated > pci13: at device 6.3 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem > 0xf3504000-0xf35047ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_acad0: on acpi0 > orm0: at iomem 0xce000-0xcf7ff on isa0 > ppc0: cannot reserve I/O port range > coretemp0: on cpu0 > est0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > Timecounters tick every 1.000 msec > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 26 and 23,29 on hdaa0 > pcm1: at nid 22 on > hdaa0 > pcm2: at nid 28 on hdaa0 > hdacc1: at cad 1 on hdac0 > unknown: at nid 2 on > hdacc1 (no driver attached) > hdacc2: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc2 > pcm3: at nid 5 on hdaa1 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0: on usbus0 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > ugen3.1: at usbus3 > ugen4.1: at usbus4 > uhub3: on usbus3 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number 5WS0F7XC > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: Serial Number 5WS0FD86 > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad6 > random: unblocking device. > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1130523621 Hz quality 1000 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number K00893F1713 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > Root mount waiting for: usbus3 > ugen3.2: at usbus3 > Trying to mount root from ufs:/dev/ada1p2 [rw]... > pid 1034 (cinnamon), uid 1001: exited on signal 11 (core dumped) > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > ifa_del_loopback_route: deletion failed: 48 > ifa_del_loopback_route: deletion failed: 3 > wlan0: Ethernet address: 00:21:6b:71:7d:36 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > ifa_del_loopback_route: deletion failed: 48 > wlan0: Ethernet address: 00:21:6b:71:7d:36 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > ifa_del_loopback_route: deletion failed: 48 > wlan0: Ethernet address: 00:21:6b:71:7d:36 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...16 5 5 3 2 2 0 0 done > All buffers synced. > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r279013: Thu Feb 19 22:30:02 EST 2015 > root@Mizraim:/usr/obj/usr/src/sys/ZENNLA amd64 > FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 > VT: running with driver "vga". > module_register: module pci/mskc already exists! > Module pci/mskc failed to register: 17 > module_register: module mskc/msk already exists! > Module mskc/msk failed to register: 17 > module_register: module msk/miibus already exists! > Module msk/miibus failed to register: 17 > CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 > > Features=0xbfebfbff > > Features2=0x8e3fd > AMD Features=0x20100800 > AMD Features2=0x1 > VT-x: HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > avail memory = 4076457984 (3887 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > module_register_init: MOD_LOAD (vesa, 0xffffffff80e77bc0, 0) error 19 > netmap: loaded module > random: SOFT: yarrow init() > random: selecting highest priority adaptor > vtvga0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x207f mem > 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff,0xf0000000-0xf1ffffff irq 16 at > device 0.0 on pci1 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: Boot video device > uhci0: port 0x1800-0x181f irq 20 at > device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x1820-0x183f irq 20 at > device 26.1 on pci0 > usbus1 on uhci1 > uhci2: port 0x1840-0x185f irq 20 at > device 26.2 on pci0 > usbus2 on uhci2 > ehci0: mem 0xf3504800-0xf3504bff > irq 20 at device 26.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > hdac0: mem 0xf3500000-0xf3503fff irq 21 at > device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > mskc0: port 0x3000-0x30ff mem > 0xf3000000-0xf3003fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Using defaults for TSO: 65518/35/2048 > msk0: Ethernet address: 00:1d:72:ed:56:80 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > pcib4: irq 18 at device 28.2 on pci0 > pci4: on pcib4 > iwn0: mem 0xf3100000-0xf3101fff irq 18 at device 0.0 > on pci4 > pcib5: irq 16 at device 28.4 on pci0 > pci5: on pcib5 > uhci3: port 0x1860-0x187f irq 23 at > device 29.0 on pci0 > usbus4 on uhci3 > uhci4: port 0x1880-0x189f irq 17 at > device 29.1 on pci0 > usbus5 on uhci4 > uhci5: port 0x18a0-0x18bf irq 18 at > device 29.2 on pci0 > usbus6 on uhci5 > ehci1: mem 0xf3504c00-0xf3504fff > irq 23 at device 29.7 on pci0 > usbus7: EHCI version 1.0 > usbus7 on ehci1 > pcib6: at device 30.0 on pci0 > pci13: on pcib6 > pci13: at device 6.0 (no driver attached) > sdhci_pci0: mem 0xf3202800-0xf32028ff irq 22 at device 6.2 > on pci13 > sdhci_pci0: 1 slot(s) allocated > pci13: at device 6.3 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem > 0xf3504000-0xf35047ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_acad0: on acpi0 > orm0: at iomem 0xce000-0xcf7ff on isa0 > ppc0: cannot reserve I/O port range > coretemp0: on cpu0 > est0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > usbus0: 12Mbps Full Speed USB v1.0 > Timecounters tick every 1.000 msec > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 26 and 23,29 on hdaa0 > pcm1: at nid 22 on > hdaa0 > pcm2: at nid 28 on hdaa0 > hdacc1: at cad 1 on hdac0 > unknown: at nid 2 on > hdacc1 (no driver attached) > hdacc2: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc2 > pcm3: at nid 5 on hdaa1 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0: on usbus0 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > ugen3.1: at usbus3 > ugen4.1: at usbus4 > uhub3: on usbus3 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number 5WS0F7XC > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: Serial Number 5WS0FD86 > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad6 > random: unblocking device. > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1130525891 Hz quality 1000 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number K00893F1713 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > Root mount waiting for: usbus3 > ugen3.2: at usbus3 > Trying to mount root from ufs:/dev/ada1p2 [rw]... > wlan0: Ethernet address: 00:21:6b:71:7d:36 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > iwn0: iwn_read_firmware: ucode rev=0x08530501 > pid 1061 (cinnamon), uid 1001: exited on signal 6 (core dumped) > pid 1085 (cinnamon), uid 1001: exited on signal 10 (core dumped) > pid 1090 (cinnamon), uid 1001: exited on signal 11 (core dumped) > pid 1101 (cinnamon), uid 1001: exited on signal 11 (core dumped) > wlan0: link state changed to DOWN > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...18 6 5 3 3 0 1 0 0 done > All buffers synced. > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r279013: Thu Feb 19 22:30:02 EST 2015 > root@Mizraim:/usr/obj/usr/src/sys/ZENNLA amd64 > FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 > VT: running with driver "vga". > module_register: module pci/mskc already exists! > Module pci/mskc failed to register: 17 > module_register: module mskc/msk already exists! > Module mskc/msk failed to register: 17 > module_register: module msk/miibus already exists! > Module msk/miibus failed to register: 17 > CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 > > Features=0xbfebfbff > > Features2=0x8e3fd > AMD Features=0x20100800 > AMD Features2=0x1 > VT-x: HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > avail memory = 4076457984 (3887 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > module_register_init: MOD_LOAD (vesa, 0xffffffff80e77bc0, 0) error 19 > netmap: loaded module > random: SOFT: yarrow init() > random: selecting highest priority adaptor > vtvga0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x207f mem > 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff,0xf0000000-0xf1ffffff irq 16 at > device 0.0 on pci1 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: Boot video device > uhci0: port 0x1800-0x181f irq 20 at > device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x1820-0x183f irq 20 at > device 26.1 on pci0 > usbus1 on uhci1 > uhci2: port 0x1840-0x185f irq 20 at > device 26.2 on pci0 > usbus2 on uhci2 > ehci0: mem 0xf3504800-0xf3504bff > irq 20 at device 26.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > hdac0: mem 0xf3500000-0xf3503fff irq 21 at > device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > mskc0: port 0x3000-0x30ff mem > 0xf3000000-0xf3003fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Using defaults for TSO: 65518/35/2048 > msk0: Ethernet address: 00:1d:72:ed:56:80 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > pcib4: irq 18 at device 28.2 on pci0 > pci4: on pcib4 > iwn0: mem 0xf3100000-0xf3101fff irq 18 at device 0.0 > on pci4 > pcib5: irq 16 at device 28.4 on pci0 > pci5: on pcib5 > uhci3: port 0x1860-0x187f irq 23 at > device 29.0 on pci0 > usbus4 on uhci3 > uhci4: port 0x1880-0x189f irq 17 at > device 29.1 on pci0 > usbus5 on uhci4 > uhci5: port 0x18a0-0x18bf irq 18 at > device 29.2 on pci0 > usbus6 on uhci5 > ehci1: mem 0xf3504c00-0xf3504fff > irq 23 at device 29.7 on pci0 > usbus7: EHCI version 1.0 > usbus7 on ehci1 > pcib6: at device 30.0 on pci0 > pci13: on pcib6 > pci13: at device 6.0 (no driver attached) > sdhci_pci0: mem 0xf3202800-0xf32028ff irq 22 at device 6.2 > on pci13 > sdhci_pci0: 1 slot(s) allocated > pci13: at device 6.3 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem > 0xf3504000-0xf35047ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_acad0: on acpi0 > orm0: at iomem 0xce000-0xcf7ff on isa0 > ppc0: cannot reserve I/O port range > coretemp0: on cpu0 > est0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > usbus0: 12Mbps Full Speed USB v1.0 > Timecounters tick every 1.000 msec > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 26 and 23,29 on hdaa0 > pcm1: at nid 22 on > hdaa0 > pcm2: at nid 28 on hdaa0 > hdacc1: at cad 1 on hdac0 > unknown: at nid 2 on > hdacc1 (no driver attached) > hdacc2: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc2 > pcm3: at nid 5 on hdaa1 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0: on usbus0 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > ugen3.1: at usbus3 > ugen4.1: at usbus4 > uhub3: on usbus3 > ugen5.1: at usbus5 > uhub4: on usbus4 > uhub5: on usbus5 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number 5WS0F7XC > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: Serial Number 5WS0FD86 > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad6 > random: unblocking device. > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1130523230 Hz quality 1000 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number K00893F1713 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > uhub3: 6 ports with 6 removable, self powered > Root mount waiting for: usbus7 usbus3 > uhub7: 6 ports with 6 removable, self powered > ugen3.2: at usbus3 > Trying to mount root from ufs:/dev/ada1p2 [rw]... > pid 1028 (cinnamon), uid 1001: exited on signal 11 (core dumped) > pid 1058 (cinnamon), uid 1001: exited on signal 11 (core dumped) > pid 1062 (cinnamon), uid 1001: exited on signal 10 (core dumped) > pid 1112 (cinnamon), uid 1001: exited on signal 11 (core dumped) > pid 1136 (cinnamon), uid 1001: exited on signal 11 (core dumped) > pid 1141 (cinnamon), uid 1001: exited on signal 6 (core dumped) > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > > > ifconfig > > msk0: flags=8843 metric 0 mtu 1500 > > options=c009b > ether 00:1d:72:ed:56:80 > inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT > ) > status: active > iwn0: flags=8802 metric 0 mtu 2290 > ether 00:21:6b:71:7d:36 > nd6 options=21 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > groups: lo > > > pciconf > > > mskc0@pci0:2:0:0: class=0x020000 card=0x0696107b chip=0x436b11ab > rev=0x16 hdr=0x00 > vendor = 'Marvell Technology Group Ltd.' > device = '88E8071 PCI-E Gigabit Ethernet Controller' > class = network > subclass = ethernet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I have the same problem with my Marvell Yukon 2. Working fine in 10.0, now broken in 10.1. Regards, David. From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 12:02:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FCD564C; Mon, 23 Feb 2015 12:02:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE92A4C; Mon, 23 Feb 2015 12:02:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4E552CBE; Mon, 23 Feb 2015 12:02:49 +0000 (UTC) Date: Mon, 23 Feb 2015 12:02:47 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, luigi@FreeBSD.org, ngie@FreeBSD.org Message-ID: <2103693137.33.1424692969234.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <59685286.32.1424673118320.JavaMail.jenkins@jenkins-9.freebsd.org> References: <59685286.32.1424673118320.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2435 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 12:02:51 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 18:43:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E781CBD0 for ; Mon, 23 Feb 2015 18:43:56 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE75FC71 for ; Mon, 23 Feb 2015 18:43:56 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id a13so20572294igq.0 for ; Mon, 23 Feb 2015 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=LGF3gAcpVxG3DXyjYD9RZxsr87S6Bp8XqJ+/p+RgvX0=; b=pBfur0hZMBbQ0Fpi28cn97eKsCBkZ8PkJvcWpB0ymgcFFoXyNtYkgtEaSJa69DEM9h WRaF8Tsvgpoz56rOoSR153QPR+6yHZ115sIgikMl6aIcSffnozL1SnBsd0v3kBJHQlSI e6OTtqYKNLzasPhrE8IC6rQa8MmayFpBgcyqX3TKkmlAd25viBMmTl69oodrbBOD3RUM nOOu65sE3pYrol+toyjdK1I2u26fgLpB01ByANgsyYzbqXAdqQw7Ot/SwbhnGoQQHCjP j37jZspHhNe+RNapzqwvqsMXqL/M+0bD8NyIkni1Mx6GPrQqFx12tw0A3IsdRgCOv7oM JTkA== X-Received: by 10.43.126.196 with SMTP id gx4mr2388447icc.40.1424717035987; Mon, 23 Feb 2015 10:43:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Mon, 23 Feb 2015 10:43:35 -0800 (PST) From: Miguel Clara Date: Mon, 23 Feb 2015 18:43:35 +0000 Message-ID: Subject: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 18:43:57 -0000 I don't think this is a 11-Current issue per say but probalby bad config, but since I'm using CURRENT I dicided to post to the list. When my system boots dnscrypt fails to start with: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" But manual start works without issue, I've resinstalled libsodium and dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present in the Makefile for libsodium, Running dmesg -a I see this relvant part: % dmesg -a | grep dns -A20 Starting dnscrypt_proxy. Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" /etc/rc: WARNING: failed to start dnscrypt_proxy Starting local_unbound. Starting pflogd: Starting pflog. pflog0: promiscuous mode enabled Enabling pfNo ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled . add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net default: gateway fe80::62a4:4cff:fe28:13c0%wlan0 Waiting 30s for the default route interface: .....(no carrier) ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc47 /usr/local/lib/libxul /usr/local/lib/nss /usr/local/llvm35/lib 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat So it seems that the issue is that ldconfig runs after the service is started and so when it starts I doens't know about the shared lib (or where to look for it) How can I fix this behaviour? Thanks From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 21:53:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 711A54F3 for ; Mon, 23 Feb 2015 21:53:00 +0000 (UTC) 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 4091F652 for ; Mon, 23 Feb 2015 21:52:59 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 63C482094E for ; Mon, 23 Feb 2015 16:44:25 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 23 Feb 2015 16:44:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=gpc+wVZl2SSobIf9soIruMXl qqA=; b=KoK8OC8gM3/hr47YhwX1rGTFK2nfX1id+WOe4uU+iWQMMhHNLe4mRP7H daBehX64EQANPtscthcQxFijuVacyXPWBH/UzWhZ1Is6yZtdGLxVEjHgUjm+Y1Bi 3zPMN0NEhq99APBx8yDMz77EvZFGMy2rJ+YRgYeYPW7UZPcrJeg= Received: by web3.nyi.internal (Postfix, from userid 99) id 044F710F910; Mon, 23 Feb 2015 16:44:25 -0500 (EST) Message-Id: <1424727865.2482688.231426709.1C3F0A3A@webmail.messagingengine.com> X-Sasl-Enc: r1aH/ZUFmvdwYXJb12KhzPCGB+gIcfsVzqeFSAYHMm9q 1424727865 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ba7306c In-Reply-To: References: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Date: Mon, 23 Feb 2015 15:44:25 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 21:53:00 -0000 On Mon, Feb 23, 2015, at 12:43, Miguel Clara wrote: > I don't think this is a 11-Current issue per say but probalby bad config, > but since I'm using CURRENT I dicided to post to the list. > > When my system boots dnscrypt fails to start with: > > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > > But manual start works without issue, I've resinstalled libsodium and > dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present in the > Makefile for libsodium, > > Running dmesg -a I see this relvant part: > % dmesg -a | grep dns -A20 > Starting dnscrypt_proxy. > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > /etc/rc: WARNING: failed to start dnscrypt_proxy > Starting local_unbound. > Starting pflogd: > Starting pflog. > pflog0: promiscuous mode enabled > Enabling pfNo ALTQ support in kernel > ALTQ related functions disabled > No ALTQ support in kernel > ALTQ related functions disabled > . > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net default: gateway fe80::62a4:4cff:fe28:13c0%wlan0 > Waiting 30s for the default route interface: .....(no carrier) > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat /usr/local/lib/gcc47 /usr/local/lib/libxul > /usr/local/lib/nss /usr/local/llvm35/lib > 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat > > So it seems that the issue is that ldconfig runs after the service is > started and so when it starts I doens't know about the shared lib (or > where > to look for it) > > How can I fix this behaviour? > If you edit the dnscrypt-proxy rc script to say: # REQUIRE: SERVERS cleanvar ldconfig Does that help? From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 22:04:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BA3D933; Mon, 23 Feb 2015 22:04:41 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A7AF7C2; Mon, 23 Feb 2015 22:04:41 +0000 (UTC) Received: by iecat20 with SMTP id at20so27221583iec.12; Mon, 23 Feb 2015 14:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PsqgvoFwDVcGYvayAmJNrusKxTW9N7+zC/xToBT8yGg=; b=dRvQGSJ3pVtYgv7L0qVBRYiQ/aGb0nrzbl6AkRs0Q4s7kfsPCGqlIDcZEXafXmTApb XcINj6Zgr17vE81DT6lwhjW7fXtQm0wrX8ZkwnNV4w09INzpOUz0AvWk91uzlGMyRRFg hFw7yHgDDxeioVgM4FsBMtPLrjILmDZnZmmYHrorEUqjS8nGplR6kETZFTidaamjzENy 7nGCVJfeKZhsHg3ejKQxtVeVWVJikEvZ2QHfbP+1lGzGpq74LFdzAGJiLWOF/D7mQDhX IdvQz957nm8dnstVh3Nw7srLJtTFQaEwCqoUTUUlz7icrGgoBbnJFQx4QVfJApOqLFj8 jfUw== X-Received: by 10.42.104.68 with SMTP id q4mr13927670ico.35.1424729080602; Mon, 23 Feb 2015 14:04:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Mon, 23 Feb 2015 14:04:19 -0800 (PST) In-Reply-To: <1424727865.2482688.231426709.1C3F0A3A@webmail.messagingengine.com> References: <1424727865.2482688.231426709.1C3F0A3A@webmail.messagingengine.com> From: Miguel Clara Date: Mon, 23 Feb 2015 22:04:19 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 22:04:41 -0000 Probably does... I'll reboot to make sure, but that will surely do it :) I wasn't aware we could set ldconfig in the rc.d scripts... thanks for sharing. Melhores Cumprimentos // Best Regards ----------------------------------------------- *Miguel Clara* *IT - Sys Admin & Developer* *E-mail: *miguelmclara@gmail.com www.linkedin.com/in/miguelmclara/ On Mon, Feb 23, 2015 at 9:44 PM, Mark Felder wrote: > > > On Mon, Feb 23, 2015, at 12:43, Miguel Clara wrote: > > I don't think this is a 11-Current issue per say but probalby bad config, > > but since I'm using CURRENT I dicided to post to the list. > > > > When my system boots dnscrypt fails to start with: > > > > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > > > > But manual start works without issue, I've resinstalled libsodium and > > dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present in the > > Makefile for libsodium, > > > > Running dmesg -a I see this relvant part: > > % dmesg -a | grep dns -A20 > > Starting dnscrypt_proxy. > > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > > /etc/rc: WARNING: failed to start dnscrypt_proxy > > Starting local_unbound. > > Starting pflogd: > > Starting pflog. > > pflog0: promiscuous mode enabled > > Enabling pfNo ALTQ support in kernel > > ALTQ related functions disabled > > No ALTQ support in kernel > > ALTQ related functions disabled > > . > > add net fe80::: gateway ::1 > > add net ff02::: gateway ::1 > > add net ::ffff:0.0.0.0: gateway ::1 > > add net ::0.0.0.0: gateway ::1 > > add net default: gateway fe80::62a4:4cff:fe28:13c0%wlan0 > > Waiting 30s for the default route interface: .....(no carrier) > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > > /usr/local/lib/compat /usr/local/lib/gcc47 /usr/local/lib/libxul > > /usr/local/lib/nss /usr/local/llvm35/lib > > 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat > > > > So it seems that the issue is that ldconfig runs after the service is > > started and so when it starts I doens't know about the shared lib (or > > where > > to look for it) > > > > How can I fix this behaviour? > > > > If you edit the dnscrypt-proxy rc script to say: > > # REQUIRE: SERVERS cleanvar ldconfig > > Does that help? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Feb 23 22:12:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9218C26; Mon, 23 Feb 2015 22:12:00 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6471F8B4; Mon, 23 Feb 2015 22:12:00 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id uz6so39511503obc.9; Mon, 23 Feb 2015 14:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=m2UhP+gfbJKj2Nl95xONq7WXIWNsHDw7eSyQDFfDbyw=; b=mhr1niGi7bgBHDIVcToRu5gSV6HTm0bCawmN+vpFDAhl93p56U1NQMJODsy0Vs5g6G uKAKHKdwNCsyfoLkuIrkEh+jiD6owqGMl4uralVx86UDDbSxmM8oBNX1PkVOqW4J/UbF Gko/Jvb8gNqNjcQQFsSHyot3Yt7RvkI/wGrOO5ntlgjBMeQ8t6gfSlWagAf/aEfhJUAi fu93x2vmXYdrurMK6xBoy9oAez6BvT3pAfsvjj9ezhiVt7EB7M2umsAwvGkJsESsiTU4 lBseuWweel7arCF45vS5VYfVEoMmq/CI8DW6VlbvXE0aKdSgb5AADU8gcwEjS+2LHFZl CASQ== X-Received: by 10.202.226.198 with SMTP id z189mr8676842oig.64.1424729519665; Mon, 23 Feb 2015 14:11:59 -0800 (PST) Received: from android-Mike.geek.local (232.125.136.95.rev.vodafone.pt. [95.136.125.232]) by mx.google.com with ESMTPSA id ur1sm22413673obc.3.2015.02.23.14.11.56 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Feb 2015 14:11:58 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: <1424727865.2482688.231426709.1C3F0A3A@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Miguel Clara Date: Mon, 23 Feb 2015 22:11:52 +0000 To: Mark Felder Message-ID: Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Feb 2015 22:12:00 -0000 On February 23, 2015 10:04:19 PM WET, Miguel Clara wrote: >Probably does... I'll reboot to make sure, but that will surely do it >:) > >I wasn't aware we could set ldconfig in the rc.d scripts... thanks for >sharing. > > > Hum just tested and its still starting before ldconfig runs and so the issue remains. :/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 01:17:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3559A3CF for ; Tue, 24 Feb 2015 01:17:06 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD9CDE5 for ; Tue, 24 Feb 2015 01:17:05 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 992BA940C5 for ; Tue, 24 Feb 2015 01:17:04 +0000 (UTC) Message-ID: <54EBD112.8050705@freebsd.org> Date: Mon, 23 Feb 2015 20:17:06 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: pf crash on -current Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdiccLpG0tprffvxw7PB0WaIClDfU4u74" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 01:17:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sdiccLpG0tprffvxw7PB0WaIClDfU4u74 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Upgraded my router today, because it was approaching the 24 uptime days of doom Now, it likes to die on me, a lot FreeBSD Nexus.HML3.ScaleEngine.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279218: Mon Feb 23 22:16:24 UTC 2015 root@Nexus.HML3.ScaleEngine.net:/usr/obj/usr/src/sys/GENERIC amd64 panic: double fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault rip =3D 0xffffffff820457a4 rsp =3D 0xfffffe01ee1f6ed0 rbp =3D 0xfffffe01ee1f73b0 cpuid =3D 0; apic id =3D 00 panic: double fault cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff817d0cc0 vpanic() at vpanic+0x189/frame 0xffffffff817d0d40 panic() at panic+0x43/frame 0xffffffff817d0da0 dblfault_handler() at dblfault_handler+0xa2/frame 0xffffffff817d0dc0 Xdblfault() at Xdblfault+0xac/frame 0xffffffff817d0dc0 --- trap 0x17, rip =3D 0xffffffff820457a4, rsp =3D 0xffffffff817d0e80, rb= p =3D 0xfffffe01ee1f73b0 --- pf_test_rule() at pf_test_rule+0x14/frame 0xfffffe01ee1f73b0 pf_test6() at pf_test6+0x1074/frame 0xfffffe01ee1f7570 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f75a0 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f7630 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f7780 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f7840 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f7a00 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f7a30 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f7ac0 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f7c10 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f7cd0 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f7e90 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f7ec0 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f7f50 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f80a0 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f8160 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f8320 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f8350 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f83e0 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f8530 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f85f0 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f87b0 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f87e0 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f8870 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f89c0 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f8a80 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f8c40 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f8c70 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f8d00 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f8e50 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f8f10 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f90d0 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f9100 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f9190 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f92e0 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f93a0 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f9560 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f9590 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f9620 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f9770 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f9830 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f99f0 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f9a20 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f9ab0 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1f9c00 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1f9cc0 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1f9e80 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1f9eb0 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1f9f40 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1fa090 pf_refragment6() at pf_refragment6+0x17a/frame 0xfffffe01ee1fa150 pf_test6() at pf_test6+0x98a/frame 0xfffffe01ee1fa310 pf_check6_out() at pf_check6_out+0x4d/frame 0xfffffe01ee1fa340 pfil_run_hooks() at pfil_run_hooks+0xa3/frame 0xfffffe01ee1fa3d0 ip6_forward() at ip6_forward+0x44e/frame 0xfffffe01ee1fa520 ip6_input() at ip6_input+0x2ed/frame 0xfffffe01ee1fa600 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe01ee1fa67= 0 ether_demux() at ether_demux+0x17b/frame 0xfffffe01ee1fa6a0 ether_nh_input() at ether_nh_input+0x336/frame 0xfffffe01ee1fa6e0 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe01ee1fa75= 0 ether_input() at ether_input+0x4f/frame 0xfffffe01ee1fa780 vlan_input() at vlan_input+0x186/frame 0xfffffe01ee1fa800 ether_demux() at ether_demux+0xb2/frame 0xfffffe01ee1fa830 ether_nh_input() at ether_nh_input+0x336/frame 0xfffffe01ee1fa870 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe01ee1fa8e= 0 ether_input() at ether_input+0x4f/frame 0xfffffe01ee1fa910 igb_rxeof() at igb_rxeof+0x5b7/frame 0xfffffe01ee1fa9a0 igb_msix_que() at igb_msix_que+0xec/frame 0xfffffe01ee1fa9f0 intr_event_execute_handlers() at intr_event_execute_handlers+0xe1/frame 0xfffffe01ee1faa30 ithread_loop() at ithread_loop+0xac/frame 0xfffffe01ee1faa70 fork_exit() at fork_exit+0x84/frame 0xfffffe01ee1faab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ee1faab0 --- trap 0, rip =3D 0, rsp =3D 0xfffffe01ee1fab70, rbp =3D 0 --- KDB: enter: panic Uptime: 56m11s Loaded symbols for /boot/kernel/pf.ko.symbols #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 ) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0xffffffff80951957 in kern_reboot (howto=3DUnhandled dwarf expression= opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80951f48 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:747 ) at pcpu.h:219 #1 0xffffffff80951957 in kern_reboot (howto=3DUnhandled dwarf expression= opcode 0 x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80951f48 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff80951f93 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:676 #4 0xffffffff80d71372 in dblfault_handler (frame=3D= ) at /usr/src/sys/amd64/amd64/trap.c:888 #5 0xffffffff80d4f45c in Xdblfault () at /usr/src/sys/amd64/amd64/exception.S:291 #6 0xffffffff820457a4 in pf_test_rule (rm=3D0xfffffe01ee1f74f0, sm=3D0xfffffe01ee1f74e8, direction=3DUnhandled dwarf expression opcod= e 0x93 ) at /usr/src/sys/modules/pf/../../netpfil/pf/pf.c:3027 Previous frame inner to this frame (corrupt stack?) --=20 Allan Jude --sdiccLpG0tprffvxw7PB0WaIClDfU4u74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJU69ESAAoJEJrBFpNRJZKfR0YP/jb7NtRP4XRBPBigwvEWDhKP dxJLcqAhf43YEMsq2v8ltPhpW6p9nTJZVgf5wDcA9JkGCIyYiij8F5wmStJ3FMHp onYaqLSrizI5qFwRQ9Eiob6PxUf6RbbOUEVgLEQEmShH7sAPKq7Sp9PHBjCNIdMl wMTMHGULGDskFjaiiKGrmbxU1CxnbOlAqjW/1Tlyat1pIIHvloJI2df0i/++nl/m Hk4jywvBMsICDBwjqc9S3GkEWWV+JM3mwshLeG8Ig2a4V+L3Iq45YspcTAxFnZL5 K1ETyPreN2hK6dyejHw+7PMeAOgUcM5+i6ID/O80+GDPrMkrM5X+4/P8SeAwTQ/J ZpM+45U0LcQY1wTaGFI6Sgd2PdYssEfS2jv7OUjiJMbn8kL7BSwZaYVvMdJ0BDQN uQHMNOXg+ji1KsC4bTmVphRar+HsE/8T+B52oabWVaq2uetzcnW3+CRIZ+qhudyq nsU8Z/TJZSLGtkr6ly+APlB71dK3k+hTXPbQ5T/aSfdtRGv/3f0HS1YHI4pGIfTt UT2mhTvBRv+r80QzsLhRIa05KTabr3kLlEFh1vkr174tsgZqnGVi73JUCcD4eb3V DaH8C50pMsxrikaih+6F04TvNbdAMqjiwY3Pdh0QMp9buP9TyvOicic6YwlOEXR3 rAPqb8sB+fN1PiqYB4Na =PBI0 -----END PGP SIGNATURE----- --sdiccLpG0tprffvxw7PB0WaIClDfU4u74-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 01:18:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DA224E2 for ; Tue, 24 Feb 2015 01:18:52 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32EECDF9 for ; Tue, 24 Feb 2015 01:18:52 +0000 (UTC) Received: by iebtr6 with SMTP id tr6so28229220ieb.7 for ; Mon, 23 Feb 2015 17:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=II3SyisGwMKaQPS5BRCIaIwSD0Wi9PUuptDXNmHILnc=; b=p8Y7ME+DosskLl1NUDHXBvvtn9IKI4BW+f6zqnvWkd5mguF+YOlu8LAclwvkkgLaZo MNiHRwvhXMeTV72mLSy5tCecFVJzq0ztI3hNqss5rx94jpPGVB4LZpuzL4IILvIPv8Cp ShwVRN35l+L5TeSuhKhLrbkFsvuuAic7qH5fpQIEuTU0Z6XTGFs0e5e4O3SyO/Vmi13W xZS1CldK4syLph6BJeSDbm2Beg3qvuwgAs2ZLLhye4sSJV+dKPLSiMoItwIjc/p8SeVz AM86mgUzPFfYOpcPHdZQ8PckbnV7kS964mC/9wBUYeQ/Wdj0zPh0y9tZwDR60NqFa6do oG/Q== MIME-Version: 1.0 X-Received: by 10.107.19.202 with SMTP id 71mr17537168iot.83.1424740731653; Mon, 23 Feb 2015 17:18:51 -0800 (PST) Received: by 10.50.104.202 with HTTP; Mon, 23 Feb 2015 17:18:51 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2015 17:18:51 -0800 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: NGie Cooper To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 01:18:52 -0000 On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara wrote: > I don't think this is a 11-Current issue per say but probalby bad config, > but since I'm using CURRENT I dicided to post to the list. > > When my system boots dnscrypt fails to start with: > > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > > But manual start works without issue, I've resinstalled libsodium and > dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present in the > Makefile for libsodium, ... What does dnscrypt-proxy REQUIRE? From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 01:23:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE242748; Tue, 24 Feb 2015 01:23:57 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F27AEC5; Tue, 24 Feb 2015 01:23:57 +0000 (UTC) Received: by lbvp9 with SMTP id p9so22010457lbv.3; Mon, 23 Feb 2015 17:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IZZxWG2leZwz0PfHf2HtQqMXfJgjxpAXXMKFtt3IIvk=; b=I2FygQc6evF6U2lOWMLgbQvpuEBQ9Yswe8nQYlI/23jTt9c1faAmoJERZjiGP5bTVU K+xsVf16kt9n41DcBzug8rs/41jIguTEl7k9zqFfnT9QZe+2iClTbuXbYfkxB/0uqUwz RdZmNubPN5PGMclpoA6dCcq0lXT/teNnxUhLihMWxJOV8E+MEr5VS7tEkmwW8ZnZUj/D Z7k/4ANKYq0b9ETSTtYl7XrgAFgKbbUcySVyX0fDO2cKHEKfxI7t+lHjsb2cmb2kSwRS uTYCaHGc45U3SOvy6M3F5j989Mqhl4miPKr7aNsJV8/oAyrmOkF6ncQgkdMtGn8crIQ0 rijA== MIME-Version: 1.0 X-Received: by 10.152.10.66 with SMTP id g2mr2970851lab.44.1424741035140; Mon, 23 Feb 2015 17:23:55 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.25.217.8 with HTTP; Mon, 23 Feb 2015 17:23:55 -0800 (PST) In-Reply-To: <54EBD112.8050705@freebsd.org> References: <54EBD112.8050705@freebsd.org> Date: Mon, 23 Feb 2015 17:23:55 -0800 X-Google-Sender-Auth: zpKSHx_DnP4xc1Jx_6UFy7PENs4 Message-ID: Subject: Re: pf crash on -current From: Davide Italiano To: Allan Jude Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 01:23:58 -0000 On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude wrote: > Upgraded my router today, because it was approaching the 24 uptime days > of doom > > Now, it likes to die on me, a lot > > The bt you posted suggest this could be stack overflow, probably due to infinite recursion. Also, as a wild guess, just looking at the stacktrace, I think this might be related to the recent ipv6 fragment changes. Try to back them out, and see if things gets more stable ( r278831 and r278843). -- Davide From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 01:44:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE327AB0; Tue, 24 Feb 2015 01:44:03 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 86CE7124; Tue, 24 Feb 2015 01:44:03 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1O1iYLK059485; Mon, 23 Feb 2015 17:44:34 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: freebsd-current@freebsd.org, Allan Jude In-Reply-To: <54EBD112.8050705@freebsd.org> References: <54EBD112.8050705@freebsd.org> From: "Chris H" Subject: Re: pf crash on -current Date: Mon, 23 Feb 2015 17:44:34 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5df58ef23e20d76ace021f3a25601f67@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 01:44:03 -0000 On Mon, 23 Feb 2015 20:17:06 -0500 Allan Jude wrote > Upgraded my router today, because it was approaching the 24 uptime days > of doom As to the "uptime days of doom"... I inquired about this a week ago, and was informed the matter had been resolved about a week earlier. I can't find the message at the moment, or I'd share the revision I was provided. But thought you like to know. --Chris > > Now, it likes to die on me, a lot > > > FreeBSD Nexus.HML3.ScaleEngine.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > r279218: > Mon Feb 23 22:16:24 UTC 2015 > root@Nexus.HML3.ScaleEngine.net:/usr/obj/usr/src/sys/GENERIC amd64 > > panic: double fault > > GNU gdb 6.1.1 [FreeBSD] .. ----8<----- .. > Previous frame inner to this frame (corrupt stack?) > > > -- > Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 01:49:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F7B7D16 for ; Tue, 24 Feb 2015 01:49:05 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7802615A for ; Tue, 24 Feb 2015 01:49:05 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 79D8794165 for ; Tue, 24 Feb 2015 01:49:04 +0000 (UTC) Message-ID: <54EBD88E.3030608@freebsd.org> Date: Mon, 23 Feb 2015 20:49:02 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pf crash on -current References: <54EBD112.8050705@freebsd.org> <5df58ef23e20d76ace021f3a25601f67@ultimatedns.net> In-Reply-To: <5df58ef23e20d76ace021f3a25601f67@ultimatedns.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g4va2N0A7sdp4leXssM3EPgelA8f0Ltd4" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 01:49:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g4va2N0A7sdp4leXssM3EPgelA8f0Ltd4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-02-23 20:44, Chris H wrote: > On Mon, 23 Feb 2015 20:17:06 -0500 Allan Jude w= rote >=20 >> Upgraded my router today, because it was approaching the 24 uptime day= s >> of doom > As to the "uptime days of doom"... > I inquired about this a week ago, and was informed the matter > had been resolved about a week earlier. I can't find the message > at the moment, or I'd share the revision I was provided. But > thought you like to know. >=20 > --Chris Yes, I was installing the latest to get that fix, I know it is fixed. --=20 Allan Jude --g4va2N0A7sdp4leXssM3EPgelA8f0Ltd4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJU69iSAAoJEJrBFpNRJZKfkfwP/0BmoFzIlfjF1PAAOi/UA2xY VFYrlOr/sA5cNC5WMpQs0cXN8W3vzjlK1GB5dr0ji4O1fyMuG30fBS/G9rrZLVFR Cs+Gh5eW8NViVX+ec5zCvQFROPF2G/2zoJWBGxCJOSrt0iXTBEYqhioHkKvOxsih 1izSvz+Yuh3lzxILpOShA7qnaMUnGhwGE+usC6r5vdtro/y+e3b7CEkk8PQNV2JT 1hO3a/Q/eGFrdcal50/rkXb/9wy3Xt4bXVhpI8lqMcaxAkjRXCczW/96wZmizSTA +D49Zo8UMMVZmLJhAjjPZC1tHaSD5TsJgKfuKXzcCorLzzM7O4m1oZhLHqHQ5Pzs gZDFh4vRfVx768/km3LyDM2WZKQOFpTL1SakN/lzf37SL9LxxP3+8dvB0ZJz4Nph xk2WPL+IS9PpXPWKq9RN6nO29aV43p0YBNGi6OwER7m6ahshUXhTSBDxd1NhpqUn mAyY8iE7DbB7CnYSx//up0EK+/L9UbaEvu0cHGe4SqMadHmfFJLXHwAkURD1jXzT R2w84oDAZQ7xWwy2edZFOUcnbNTLCfX1SIIpN4OeQEov3QhgcEWfn3HUFT6x/e/W OUSnNepCsRsuKW1yd0hilG8oKfOyv8FFbApLPeBZ4rJIf9P3OHU49ayIO9EIfwVf FpQQ5SXjw1Zf4fX11MeY =semP -----END PGP SIGNATURE----- --g4va2N0A7sdp4leXssM3EPgelA8f0Ltd4-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 02:17:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3808F993 for ; Tue, 24 Feb 2015 02:17:35 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 C7CA0685 for ; Tue, 24 Feb 2015 02:17:34 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1O2I6bQ077947 for ; Mon, 23 Feb 2015 18:18:06 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <54EBD88E.3030608@freebsd.org> References: <54EBD112.8050705@freebsd.org> <5df58ef23e20d76ace021f3a25601f67@ultimatedns.net>, <54EBD88E.3030608@freebsd.org> From: "Chris H" Subject: Re: pf crash on -current Date: Mon, 23 Feb 2015 18:18:06 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 02:17:35 -0000 On Mon, 23 Feb 2015 20:49:02 -0500 Allan Jude wrote > On 2015-02-23 20:44, Chris H wrote: > > On Mon, 23 Feb 2015 20:17:06 -0500 Allan Jude wrote > > > >> Upgraded my router today, because it was approaching the 24 uptime days > >> of doom > > As to the "uptime days of doom"... > > I inquired about this a week ago, and was informed the matter > > had been resolved about a week earlier. I can't find the message > > at the moment, or I'd share the revision I was provided. But > > thought you like to know. > > > > --Chris > > Yes, I was installing the latest to get that fix, I know it is fixed. Sure, of course. I just thought the time frame might help walking back revisions, till whatever cased the panic stopped. But still be ahead of the "uptime days of doom". FWIW the revision that fixed it was: r278229 > > -- > Allan Jude --Chris From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 04:08:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1F92A90 for ; Tue, 24 Feb 2015 04:08:02 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84A5E2E1 for ; Tue, 24 Feb 2015 04:08:02 +0000 (UTC) Received: by iecar1 with SMTP id ar1so29072587iec.11 for ; Mon, 23 Feb 2015 20:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cejujaah6z1YlczeOoO7Cf1FnBVo6oBKASU5pfsA1P4=; b=QPIZxD7iokTbBqxL6zIqd/j1C4oR6EpnK07474ar+Tjz0FHtvjIZZmO4xT6lztmgEv +W6LmjIvfAxwlui4K6VaPp2Nci4HcapiwDfDOPOOpbP6PWF9HZTEO3rXuLMrqeZUvka5 qb8VumNOsYvvtTkxNYZIaU5womuKER7w8sCNnhK8PoDy0lAkQ3LYjUqK6MK4I6Ignn4M eKTzhJbcyMXzJYKZ3gGSoeTIFcLUHLhOeByn3NjONEkIcXLOF4LZ23RqJg5JoB9Ichr6 pmnxxZFcXm75WInN15Y2yQO2WEWwYZM6x/fTZaWkon+ydk1RLMjmDBQ28v/P+Oiw6Odw DIKg== X-Received: by 10.50.73.99 with SMTP id k3mr17342428igv.21.1424750881979; Mon, 23 Feb 2015 20:08:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Mon, 23 Feb 2015 20:07:41 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Tue, 24 Feb 2015 04:07:41 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: NGie Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 04:08:02 -0000 On Tue, Feb 24, 2015 at 1:18 AM, NGie Cooper wrote: > On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara > wrote: > > I don't think this is a 11-Current issue per say but probalby bad config, > > but since I'm using CURRENT I dicided to post to the list. > > > > When my system boots dnscrypt fails to start with: > > > > Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" > > > > But manual start works without issue, I've resinstalled libsodium and > > dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present in the > > Makefile for libsodium, > > ... > > What does dnscrypt-proxy REQUIRE? > Fro the rc.d instead by the port cat /usr/ports/dns/dnscrypt-proxy/files/dnscrypt-proxy.in |grep REQUIR # REQUIRE: SERVERS cleanvar And this is what I've tried but no luck cat /usr/local/etc/rc.d/dnscrypt-proxy |grep REQUIRE # REQUIRE: SERVERS cleanvar ldconfig From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 05:10:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C17A52EF for ; Tue, 24 Feb 2015 05:10:38 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F04A53 for ; Tue, 24 Feb 2015 05:10:38 +0000 (UTC) Received: by padfb1 with SMTP id fb1so33211873pad.8 for ; Mon, 23 Feb 2015 21:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=y/+0SZmuiJjOoRqQmDbkqfy4KzwQrlt4BCAJWA+C3/Q=; b=ncFd5lvOz9GxIJM5l1vwBg9/faVukKcJ7ZZmNUCCfQPHduAFzWdzeM8V21x3mOszdM iMRqRNCsxtJL8dhMAP/Clor16dOFCgbNyO57Zf+WP5ekWAo0H4tnT5JsK4fv/PKX2YXO vgTEm+gCAQSwjqJ1ULk7uQ4YEajZGkK/0Zc23DwmTZveN5R2LOhUUe3pU9SQlqqHDN2e oqNQnBDJPXjJFk0/6vyCLrX4+AcEfagH0s9gkODsTfE5hHb97LBjPUnxNeLj72IVyb9t pLHYQrsT2YQqpCu9X4tCe7kdOguxfv2tAKufv37qZpkuYd9sBoHk9iz84g8SY7FoWP/H JVNg== X-Received: by 10.68.191.2 with SMTP id gu2mr743148pbc.149.1424754638097; Mon, 23 Feb 2015 21:10:38 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:b9e0:cf97:4935:77b4? ([2601:8:ab80:7d6:b9e0:cf97:4935:77b4]) by mx.google.com with ESMTPSA id pm2sm36664486pbb.81.2015.02.23.21.10.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Feb 2015 21:10:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_791A4CA9-AFC0-4984-8574-D520556DCD33"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Garrett Cooper In-Reply-To: Date: Mon, 23 Feb 2015 21:10:35 -0800 Message-Id: References: To: Miguel Clara X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 05:10:38 -0000 --Apple-Mail=_791A4CA9-AFC0-4984-8574-D520556DCD33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 23, 2015, at 20:07, Miguel Clara wrote: > On Tue, Feb 24, 2015 at 1:18 AM, NGie Cooper = wrote: > On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara = wrote: > > I don't think this is a 11-Current issue per say but probalby bad = config, > > but since I'm using CURRENT I dicided to post to the list. > > > > When my system boots dnscrypt fails to start with: > > > > Shared object "libsodium.so.13" not found, required by = "dnscrypt-proxy" > > > > But manual start works without issue, I've resinstalled libsodium = and > > dnscrypt from ports and I noticed "USE_LDCONFIG=3D yes" is present = in the > > Makefile for libsodium, >=20 > ... >=20 > What does dnscrypt-proxy REQUIRE? >=20 >=20 > Fro the rc.d instead by the port > cat /usr/ports/dns/dnscrypt-proxy/files/dnscrypt-proxy.in |grep REQUIR > # REQUIRE: SERVERS cleanvar >=20 >=20 > And this is what I've tried but no luck > cat /usr/local/etc/rc.d/dnscrypt-proxy |grep REQUIRE > # REQUIRE: SERVERS cleanvar ldconfig Yeah, SERVERS comes waaaay after ldconfig. What does `ldconfig -rv | grep libsodium` say? Cheers! --Apple-Mail=_791A4CA9-AFC0-4984-8574-D520556DCD33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7AfLAAoJEMZr5QU6S73e7xkH/1Yp5Y/K/ActXzC242ZxlPX0 l/kui65XrKTJdxC/AjROA+TFSp3Wm9xNKE8D5GfnAlN+8ehiZi2d9EzdW7gWUnxI EnaOejuoSyA/58NumEkc/GOtnUPqqBqqCiLgKiqKMwFC2Wb54ma8rfPMM7oyOF/P LkLGk0nS9PQbB7uI8PmaBqaGeNgDbQoVyNK8glGLhVDll6OZDVXB/2T7QMN9k83s L25GLjziIsT1uoOPHqCyppfDvvycgesW9HjlDMfvjSGm/FyhkoKYphBe59IZhVcr 9Oq5WHVRhFFLq7tv3Rspc5uIRm/KP6/v49Y3+M9sBjEDI7WtfXMnT8Xd+WQTFlk= =q9e0 -----END PGP SIGNATURE----- --Apple-Mail=_791A4CA9-AFC0-4984-8574-D520556DCD33-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 05:29:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C188A5EB for ; Tue, 24 Feb 2015 05:29:20 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B879C24 for ; Tue, 24 Feb 2015 05:29:20 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id nt9so41328647obb.3 for ; Mon, 23 Feb 2015 21:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=sE5GRYHTIo9iX89Rc1XxnnLYXzu8PrK5m/fdJeR+wug=; b=hU3qn9zrtdy99n2L6jXw6Kzhf3Cl4hNM6o0uouHx/BvsglDK7KMOdkT20Xnlor1eX0 UnE6Hcs02NRtQDEqVjPSBCckazOm6tWVk5OkCvvoFgVrVHGcBzd3yEtpcnGg5S+3qXpT Vzpvcb50mXQW1CDeSfSSeO0A4sdxEvi+oby59+QuN/jwagOOvltgyAc5skVUHboBXbCw lqrYmk9hCLG3Xq+J9hWgGDjSitgaufk5mR/9wsWsFxDWAF6Jqzw+viDxBceBKuGo/x/Y HBRD+VYDFIy+bv37GDm5Ctk9jvPNbqnGM4jSIUbiyGcYV7kgvcU4Jw3e5lC93yAWVK1n QNmg== X-Received: by 10.202.182.7 with SMTP id g7mr9324308oif.13.1424755759838; Mon, 23 Feb 2015 21:29:19 -0800 (PST) Received: from android-Mike.geek.local (232.125.136.95.rev.vodafone.pt. [95.136.125.232]) by mx.google.com with ESMTPSA id h8sm17533412obe.2.2015.02.23.21.29.18 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Feb 2015 21:29:19 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Miguel Clara Date: Tue, 24 Feb 2015 05:29:14 +0000 To: Garrett Cooper Message-ID: Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 05:29:20 -0000 On February 24, 2015 5:10:35 AM WET, Garrett Cooper wrote: >On Feb 23, 2015, at 20:07, Miguel Clara wrote: > >> On Tue, Feb 24, 2015 at 1:18 AM, NGie Cooper >wrote: >> On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara > wrote: >> > I don't think this is a 11-Current issue per say but probalby bad >config, >> > but since I'm using CURRENT I dicided to post to the list. >> > >> > When my system boots dnscrypt fails to start with: >> > >> > Shared object "libsodium.so.13" not found, required by >"dnscrypt-proxy" >> > >> > But manual start works without issue, I've resinstalled libsodium >and >> > dnscrypt from ports and I noticed "USE_LDCONFIG= yes" is present >in the >> > Makefile for libsodium, >> >> ... >> >> What does dnscrypt-proxy REQUIRE? >> >> >> Fro the rc.d instead by the port >> cat /usr/ports/dns/dnscrypt-proxy/files/dnscrypt-proxy.in |grep >REQUIR >> # REQUIRE: SERVERS cleanvar >> >> >> And this is what I've tried but no luck >> cat /usr/local/etc/rc.d/dnscrypt-proxy |grep REQUIRE >> # REQUIRE: SERVERS cleanvar ldconfig > >Yeah, SERVERS comes waaaay after ldconfig. > >What does `ldconfig -rv | grep libsodium` say? 488:-lsodium.13 => /usr/local/lib/libsodium.so.13 and after boot I can star the service fine.. ldconfig seems to kick in just before dbus which REQUIRES it. > >Cheers! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 05:31:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D356874C for ; Tue, 24 Feb 2015 05:31:50 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94390CC5 for ; Tue, 24 Feb 2015 05:31:50 +0000 (UTC) Received: by pabkq14 with SMTP id kq14so33376345pab.3 for ; Mon, 23 Feb 2015 21:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fYg1nTM7GIEksH3CSjKGIVAgqfuOhMdbQVCdG5MwQUw=; b=PCYwGh/czhqUjzybdMdBEGml4OHn+9Vs3FJ3GZbTHSkwu/arDRuJBpqq+VghfzgJau +dVfsnFCG1SOhipAIDskqp/EZKUuFtsuQaVPB0Ct/jwcIeBVr+4Hwo2rRsLXmsTXWg/U 4zt+XF4vkyxx5oVDfxREEXm87pjZvVoO78RQ+yTSXz+prF5MJPIZNNKuuogPwCvo3mzU O/MzYya8JaRqrdsAntSGNMbGM8IBTgF4FFVy5O+MmNFN0M/3opd3ZdOMFuoVHHIEXCrf 4iK3Mbv3leDPKN/UzRFubF3IlozXfJxI5zB8QnosvPh71r4d6WqzWZyLMemvNcVO/SLz jsAA== X-Received: by 10.68.233.232 with SMTP id tz8mr861482pbc.166.1424755910178; Mon, 23 Feb 2015 21:31:50 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:b9e0:cf97:4935:77b4? ([2601:8:ab80:7d6:b9e0:cf97:4935:77b4]) by mx.google.com with ESMTPSA id om9sm36794921pbb.34.2015.02.23.21.31.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Feb 2015 21:31:49 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E33A2735-4ED9-43B2-A66C-B4A6D469C437"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Garrett Cooper In-Reply-To: Date: Mon, 23 Feb 2015 21:31:47 -0800 Message-Id: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> References: To: Miguel Clara X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 05:31:51 -0000 --Apple-Mail=_E33A2735-4ED9-43B2-A66C-B4A6D469C437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 23, 2015, at 21:29, Miguel Clara wrote: > On February 24, 2015 5:10:35 AM WET, Garrett Cooper = wrote: >> On Feb 23, 2015, at 20:07, Miguel Clara = wrote: >>=20 >>> On Tue, Feb 24, 2015 at 1:18 AM, NGie Cooper >> wrote: >>> On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara >> wrote: >>>> I don't think this is a 11-Current issue per say but probalby bad >> config, >>>> but since I'm using CURRENT I dicided to post to the list. >>>>=20 >>>> When my system boots dnscrypt fails to start with: >>>>=20 >>>> Shared object "libsodium.so.13" not found, required by >> "dnscrypt-proxy" >>>>=20 >>>> But manual start works without issue, I've resinstalled libsodium >> and >>>> dnscrypt from ports and I noticed "USE_LDCONFIG=3D yes" is = present >> in the >>>> Makefile for libsodium, >>>=20 >>> ... >>>=20 >>> What does dnscrypt-proxy REQUIRE? >>>=20 >>>=20 >>> Fro the rc.d instead by the port >>> cat /usr/ports/dns/dnscrypt-proxy/files/dnscrypt-proxy.in |grep >> REQUIR >>> # REQUIRE: SERVERS cleanvar >>>=20 >>>=20 >>> And this is what I've tried but no luck >>> cat /usr/local/etc/rc.d/dnscrypt-proxy |grep REQUIRE >>> # REQUIRE: SERVERS cleanvar ldconfig >>=20 >> Yeah, SERVERS comes waaaay after ldconfig. >>=20 >> What does `ldconfig -rv | grep libsodium` say? >=20 > 488:-lsodium.13 =3D> /usr/local/lib/libsodium.so.13 >=20 > and after boot I can star the service fine.. ldconfig seems to kick = in just before dbus which REQUIRES it.=20 What do the following commands say? rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk = =91/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=92 --Apple-Mail=_E33A2735-4ED9-43B2-A66C-B4A6D469C437 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7AzEAAoJEMZr5QU6S73exq8H+wbjy89uECC7m+5v2utX/TOh pZWS2TKrMu02iM0mSC4KLjtihxw8olsLHP7ZPaUm2c9WKXoJaVRciu8pY6s5YebE XiBzGP0ZxLEHO31U0nPyY9qgbnjobxkXsDVb9XaVac2ev4zr6IgembybWJssk9qZ LCB/w3W++p8Oz91vO2idPKid02DRfnuOFQHOz+LRh0JddXfWS9DnScNMFdFFnYmx bkkncyeGRW7EkzppJUibSmQybn4plg6m6PdFWgzHdOSSk/sBYMacZEN3FA1i5kiO RY/AHQGSFi1RfNtNZ5WmbONJont4hjLdGMFisLB0VEyDtJZCl+Pp17YNyGexi5U= =Aqgz -----END PGP SIGNATURE----- --Apple-Mail=_E33A2735-4ED9-43B2-A66C-B4A6D469C437-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 06:37:10 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C41575E7; Tue, 24 Feb 2015 06:37:10 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 889A6381; Tue, 24 Feb 2015 06:37:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0C3787300A; Tue, 24 Feb 2015 07:36:00 +0100 (CET) Date: Tue, 24 Feb 2015 07:36:00 +0100 From: Luigi Rizzo To: net@freebsd.org, current@freebsd.org Subject: netmap support for the Intel 40G card in head Message-ID: <20150224063600.GA72100@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 06:37:10 -0000 Thanks to Jack Vogel who made available some hardware, I have been able to implement native netmap support for the Intel "ixl" driver, aka xl710, the 40G card. I have committed the code to 'head', and the same works in stable/10 where it will land soon. Testers welcome. I have seen 32 Mpps on tx, 24 Mpps on rx with two ports on the same card connected to each other. This is our second 40G device for which we have native netmap support, which makes FreeBSD quite unique. cheers luigi Date: Tue, 24 Feb 2015 06:20:51 +0000 (UTC) From: Luigi Rizzo Subject: svn commit: r279232 - in head/sys/dev: ixl netmap To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: luigi Date: Tue Feb 24 06:20:50 2015 New Revision: 279232 URL: https://svnweb.freebsd.org/changeset/base/279232 Log: Add native netmap support to ixl. Preliminary tests indicate 32 Mpps on tx, 24 Mpps on rx with source and receiver on two different ports of the same 40G card. Optimizations are likely possible. The code follows closely the one for ixgbe so i do not expect stability issues. Hardware kindly supplied by Intel. Reviewed by: Jack Vogel MFC after: 1 week Added: head/sys/dev/netmap/if_ixl_netmap.h (contents, props changed) Modified: head/sys/dev/ixl/if_ixl.c head/sys/dev/ixl/ixl_txrx.c From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 07:05:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BAAF991; Tue, 24 Feb 2015 07:05:52 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BD6C844; Tue, 24 Feb 2015 07:05:51 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 94B54BE48; Tue, 24 Feb 2015 08:05:47 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 8EA3BBB10; Tue, 24 Feb 2015 08:05:47 +0100 (CET) Date: Tue, 24 Feb 2015 08:05:47 +0100 From: Kristof Provost To: Davide Italiano Subject: Re: pf crash on -current Message-ID: <20150224070547.GH2181@vega.codepro.be> References: <54EBD112.8050705@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 07:05:52 -0000 On 2015-02-23 17:23:55 (-0800), Davide Italiano wrote: > On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude wrote: > > Upgraded my router today, because it was approaching the 24 uptime days > > of doom > > > > Now, it likes to die on me, a lot > > > > > > The bt you posted suggest this could be stack overflow, probably due > to infinite recursion. > Also, as a wild guess, just looking at the stacktrace, I think this > might be related to the recent ipv6 fragment changes. Try to back them > out, and see if things gets more stable ( r278831 and r278843). > That's almost certainly what it is. Allan, can you give me a bit more information about your setup? Specifically the pf rules, the network interfaces, the IP(v6) addresses and the routes? Thanks, Kristof From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 14:35:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F41D94D8 for ; Tue, 24 Feb 2015 14:35:47 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD586179 for ; Tue, 24 Feb 2015 14:35:47 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so32323079iec.9 for ; Tue, 24 Feb 2015 06:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tl6GJCf6cIgKUrHkA03MC1TqZ2Eb5gqAWquD9Ka4p9M=; b=yXQx5oO57g5mCg6FEqCf1GtzSgxcNUx9605rgVS5UCqiF5LYlDEucMxrtuduAAUWRj Jg6J4ov4KUrHsEUfCdzuQmF8nXqIOZ9ZzgVulnArdHRFfFmrgcHAvrztUJ8JUKAhYocu tXLYjMtpVXDPhNGy8GY5O+Owv7JhOBPunDHl7gMnGtNjUNwCkUgbSjUOLdDvxrWYKD7S i3HRMIjfCroV+A1aCx+5QCSqY6B34s1L8oZbEmNE7HJPXZOOfF9urL8Q7nfPPUv8LpDv yfFsMYptjh8VRHGH2EdsEo82tOAYdAeHAVhcIiyjUdG9ZuPLty9FN3rIE33gaeW0mzrv bVzw== X-Received: by 10.107.5.212 with SMTP id 203mr6535774iof.4.1424788547029; Tue, 24 Feb 2015 06:35:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 06:35:26 -0800 (PST) In-Reply-To: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> From: Miguel Clara Date: Tue, 24 Feb 2015 14:35:26 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 14:35:48 -0000 ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `kerberos' rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `named= ' rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown provision `unbound' rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on provision `dbus' in file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on provision `ldconfig' in file `/usr/local/etc/rc.d/dnscrypt-proxy'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/devfs'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/mdconfig2'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/newsyslog'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/syslogd'. rcorder: Circular dependency on provision `NETWORKING' in file `/etc/rc.d/kdc'. rcorder: Circular dependency on provision `ldconfig' in file `/etc/rc.d/SERVERS'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/archdep'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/SERVERS'. rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no providers. rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no providers. # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `kerberos' rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `named= ' rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown provision `unbound' rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on provision `dbus' in file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on provision `ldconfig' in file `/usr/local/etc/rc.d/dnscrypt-proxy'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/devfs'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/mdconfig2'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/newsyslog'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/syslogd'. rcorder: Circular dependency on provision `NETWORKING' in file `/etc/rc.d/kdc'. rcorder: Circular dependency on provision `ldconfig' in file `/etc/rc.d/SERVERS'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/archdep'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/SERVERS'. rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no providers. rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no providers. cleanvar: Command not found. dbus/: Command not found. Note that this is still with the change to dnscrypt-ptoxy REQUIRE (adding ldconfig) Melhores Cumprimentos // Best Regards ----------------------------------------------- *Miguel Clara* *IT - Sys Admin & Developer* *E-mail: *miguelmclara@gmail.com www.linkedin.com/in/miguelmclara/ On Tue, Feb 24, 2015 at 5:31 AM, Garrett Cooper wrote: > On Feb 23, 2015, at 21:29, Miguel Clara wrote: > > > On February 24, 2015 5:10:35 AM WET, Garrett Cooper < > yaneurabeya@gmail.com> wrote: > >> On Feb 23, 2015, at 20:07, Miguel Clara wrote= : > >> > >>> On Tue, Feb 24, 2015 at 1:18 AM, NGie Cooper > >> wrote: > >>> On Mon, Feb 23, 2015 at 10:43 AM, Miguel Clara > >> wrote: > >>>> I don't think this is a 11-Current issue per say but probalby bad > >> config, > >>>> but since I'm using CURRENT I dicided to post to the list. > >>>> > >>>> When my system boots dnscrypt fails to start with: > >>>> > >>>> Shared object "libsodium.so.13" not found, required by > >> "dnscrypt-proxy" > >>>> > >>>> But manual start works without issue, I've resinstalled libsodium > >> and > >>>> dnscrypt from ports and I noticed "USE_LDCONFIG=3D yes" is present > >> in the > >>>> Makefile for libsodium, > >>> > >>> ... > >>> > >>> What does dnscrypt-proxy REQUIRE? > >>> > >>> > >>> Fro the rc.d instead by the port > >>> cat /usr/ports/dns/dnscrypt-proxy/files/dnscrypt-proxy.in |grep > >> REQUIR > >>> # REQUIRE: SERVERS cleanvar > >>> > >>> > >>> And this is what I've tried but no luck > >>> cat /usr/local/etc/rc.d/dnscrypt-proxy |grep REQUIRE > >>> # REQUIRE: SERVERS cleanvar ldconfig > >> > >> Yeah, SERVERS comes waaaay after ldconfig. > >> > >> What does `ldconfig -rv | grep libsodium` say? > > > > 488:-lsodium.13 =3D> /usr/local/lib/libsodium.so.13 > > > > and after boot I can star the service fine.. ldconfig seems to kick in > just before dbus which REQUIRES it. > > What do the following commands say? > > rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 > From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 15:33:39 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 699E0DB1; Tue, 24 Feb 2015 15:33:39 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2E1AA7A; Tue, 24 Feb 2015 15:33:38 +0000 (UTC) Received: by lbdu14 with SMTP id u14so25567756lbd.1; Tue, 24 Feb 2015 07:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gfr+RjB7coMGABUqwcAlPOZ/rKUV7JcjbZn/5/sHmME=; b=laVthSMA+o6e/1XefBucKGt8ugLfW0sgU/kyLE69DJ6GaKpv0FskSJjGomCdJCRZhd Wd5k7ogbl2s8tHn+Cugc0F2VgDqNlz+AMeDNmEsgmfe4cFS3lOTmu441fMiP+/aQntX8 7cFYKbyXcJhli4YgiiPpsSoJ6t5EilkeBHBD5ucs8SYi89f3uzcT+NE10gJYOwtIb9r9 LmKTyGgis8xA6nqhMjCjm+ZoEMjBB0JvWgWf1RIpHzDyokhhaKM3Cb/jolkQsfVKSESM 34uejHAwbnrQlIf+iJxavTCk8+E4XidPPnlMBSu0+hneF6Woduk5YetsjO4AlmamN9YS +3qg== MIME-Version: 1.0 X-Received: by 10.152.115.169 with SMTP id jp9mr14884366lab.121.1424792016674; Tue, 24 Feb 2015 07:33:36 -0800 (PST) Received: by 10.114.78.131 with HTTP; Tue, 24 Feb 2015 07:33:36 -0800 (PST) In-Reply-To: <20150224063600.GA72100@onelab2.iet.unipi.it> References: <20150224063600.GA72100@onelab2.iet.unipi.it> Date: Tue, 24 Feb 2015 10:33:36 -0500 Message-ID: Subject: Re: netmap support for the Intel 40G card in head From: Ryan Stone To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , FreeBSD Net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 15:33:39 -0000 This is great! Thanks to both you and Intel. I'm planning on getting SR-IOV support into head this week, which would allow you to create ixlv instances (on the same hardware). Any chance that you'd have the time to look into supporting SR-IOV for that driver too? From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 18:13:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCED6963 for ; Tue, 24 Feb 2015 18:13:58 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C9A5FC4 for ; Tue, 24 Feb 2015 18:13:58 +0000 (UTC) Received: by pdjz10 with SMTP id z10so34997186pdj.12 for ; Tue, 24 Feb 2015 10:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nTBgnbe0nqiUpj4K+sdX4A5bEtNiFuf96uLcNfzT8Kk=; b=XUvv0pM9SbaanBa0FdxzEtJghyD0MI5f3ADADXZe/jEEs+mbhGsHr6YinUMu+2OjMC h0Xeu2Vd2k5JTv7TdeJiAF1DE+COAo70yhQHMEc16rXbwBfjQyNC2Mz/OenJ4C/y/h7V VzVSvyro/VsmHu4ruhF1Exd7ONROPMwofUR1ue3unAJYS0M9p5yxM8YB4AiUXmNwO0cZ tU3hQx5R+1n6WvMCNM6YksrZ1gQteA+bBZ2VAFb2Cxq9P7EoWt9YjTtIvuz3ESvKnFCt 4xnPBYVaUACYyYbpdbCIbCtPiqV0cBodKB/89YjaXdXHbhx40WWLtVyrm/Y6ThMHeN6f lNTw== X-Received: by 10.70.53.65 with SMTP id z1mr31210850pdo.38.1424801637954; Tue, 24 Feb 2015 10:13:57 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:b9e0:cf97:4935:77b4? ([2601:8:ab80:7d6:b9e0:cf97:4935:77b4]) by mx.google.com with ESMTPSA id qv9sm39980587pab.27.2015.02.24.10.13.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 10:13:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_85A013EC-E7EC-4565-96E4-AF7DFFBB8254"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Garrett Cooper In-Reply-To: Date: Tue, 24 Feb 2015 10:13:56 -0800 Message-Id: <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> To: Miguel Clara X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 18:13:58 -0000 --Apple-Mail=_85A013EC-E7EC-4565-96E4-AF7DFFBB8254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 24, 2015, at 6:35, Miguel Clara wrote: > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `kerberos' > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `named' > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown = provision `unbound' > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on provision `dbus' in file = `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on provision `ldconfig' in file = `/usr/local/etc/rc.d/dnscrypt-proxy'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/devfs'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/mdconfig2'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/newsyslog'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/syslogd'. > rcorder: Circular dependency on provision `NETWORKING' in file = `/etc/rc.d/kdc'. > rcorder: Circular dependency on provision `ldconfig' in file = `/etc/rc.d/SERVERS'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/archdep'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/SERVERS'. > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no = providers. > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no = providers. >=20 > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk = =91/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=92 > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `kerberos' > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `named' > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown = provision `unbound' > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on provision `dbus' in file = `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on provision `ldconfig' in file = `/usr/local/etc/rc.d/dnscrypt-proxy'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/devfs'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/mdconfig2'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/newsyslog'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/syslogd'. > rcorder: Circular dependency on provision `NETWORKING' in file = `/etc/rc.d/kdc'. > rcorder: Circular dependency on provision `ldconfig' in file = `/etc/rc.d/SERVERS'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/archdep'. > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/SERVERS'. > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no = providers. > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no = providers. > cleanvar: Command not found. > dbus/: Command not found. >=20 > Note that this is still with the change to dnscrypt-ptoxy REQUIRE = (adding ldconfig) Your rcorder is 50 shades of broken :(. Please remove all local = modifications to scripts, then repost the output of the rcorder commands = again. I suspect what=92s going wrong is the result of some of my = changes to remove etc/rc.d based on build knobs=85 Cheers, --Apple-Mail=_85A013EC-E7EC-4565-96E4-AF7DFFBB8254 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7L9kAAoJEMZr5QU6S73eMaUH/1GdG/f9zM2j/QEEIdhnEBZD WscI1863qbemHPzhjmdzGwex63dyvoJ6uV+PJ6nKLemk47rHaYDakGeA+q0cy6BL 72kNh/L/MYlvdwoHyAwOcTWx3rI43sVtMcDka7iqMw7yVEOTJHn25WhMxwWyGwzd NcZBItiNwA95Ig2GsDR9fjkQe8jgt+lWa7Z34s04AdNqT+ECt7mtjdy4Dnkb4MGF +WvEYMEZ4Jwss50sCl8wypw1B1Wgq89RbVlENReUkq0Q95tWNgspfHe1zIFKjUjj /6/JZ/i84j+qMleHUVGjqMS/1mII3oAothPrkkE1ccV2lnJjYdV+BoP/3nlCwWs= =oGhy -----END PGP SIGNATURE----- --Apple-Mail=_85A013EC-E7EC-4565-96E4-AF7DFFBB8254-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 18:53:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0FEB853 for ; Tue, 24 Feb 2015 18:53:52 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE16C6AB for ; Tue, 24 Feb 2015 18:53:52 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so34709809iec.1 for ; Tue, 24 Feb 2015 10:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QMW/uvMrKWDamnw63PlTI25i+3DVOPHlD6lhqB0taDU=; b=TZg/R3WmVc/yjRxOWYbyZwxuLdCOO+OGwSlQ0O0VIGrhFG1OfWEvXQjRdylY5TpPP5 pg9MAhccyvNVzWKLTBtw/NIC4+1hhoyUtjMiGMy4mH/BbR9h3Dgu1uYfEGt2i+eTt9bp xQ08Vx5BhAda4sK+V05WcI/vaBnJ6tXuk16Ow4TDt7dyA1cPylCKLiDA0wuQd9ckG15h crbteI44jMOEALRUI36OYi7HJOU1bt3bf3eheoCm4XRnEN1zrCf8PF/kNYPnuEDZus4U K7aB1XEU/7o/HrFssyYFF3feRA5MbhvQQPXzmdrIgTXMR8DtSy9TERKGEvOuE29gQzQQ TkGw== X-Received: by 10.107.33.11 with SMTP id h11mr22599838ioh.53.1424804032164; Tue, 24 Feb 2015 10:53:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 10:53:31 -0800 (PST) In-Reply-To: <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> From: Miguel Clara Date: Tue, 24 Feb 2015 18:53:31 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 18:53:53 -0000 On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper wrote: > On Feb 24, 2015, at 6:35, Miguel Clara wrote: > > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `kerberos' > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `named' > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > provision `unbound' > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `dbus' in file > `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `ldconfig' in file > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/devfs'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/mdconfig2'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/newsyslog'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/syslogd'. > > rcorder: Circular dependency on provision `NETWORKING' in file > `/etc/rc.d/kdc'. > > rcorder: Circular dependency on provision `ldconfig' in file > `/etc/rc.d/SERVERS'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/archdep'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/SERVERS'. > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > providers. > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > providers. > > > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `kerberos' > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `named' > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > provision `unbound' > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `dbus' in file > `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `ldconfig' in file > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/devfs'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/mdconfig2'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/newsyslog'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/syslogd'. > > rcorder: Circular dependency on provision `NETWORKING' in file > `/etc/rc.d/kdc'. > > rcorder: Circular dependency on provision `ldconfig' in file > `/etc/rc.d/SERVERS'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/archdep'. > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/SERVERS'. > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > providers. > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > providers. > > cleanvar: Command not found. > > dbus/: Command not found. > > > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE > (adding ldconfig) > > Your rcorder is 50 shades of broken :(. Please remove all local > modifications to scripts, then repost the output of the rcorder commands > again. I suspect what=E2=80=99s going wrong is the result of some of my c= hanges to > remove etc/rc.d based on build knobs=E2=80=A6 > Cheers, > So much like the movies them... damn.... :X I don't recall any changes to the rc.d scripts except the one to dnscrypt-proxy (adding the ldconfig REQUIRE) I also don't really know what to make of the output... expect this part: "Circular dependency on provision", but the man says: A set of files has a circular dependency which was detected while processing the stated condition. So it should mean that 'A' requires 'B' but 'B' requires 'A'... but this does not seem to be the case... I guess I'll have to go one by one and see if I can identify issue. But first I'll make sure the ports that use those rc.d scripts are up to date. From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 18:58:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EBC79F3 for ; Tue, 24 Feb 2015 18:58:40 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFF8C752 for ; Tue, 24 Feb 2015 18:58:39 +0000 (UTC) Received: by paceu11 with SMTP id eu11so38117386pac.7 for ; Tue, 24 Feb 2015 10:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8xvXcTKVVJ7QkBnu2nOLCgAEGgsH9V7Fm9FVQ2szETo=; b=hYegkMtregKKAaMNumzbqvJkKLTPN6vE2vills3CERFqckOehPqPtcJVyOpmMsGYEy E99P1hgSUVY0ZTAflsuK9PdZBjs1SzfFm7sI+dsqD3Yj3kR59Kk8IOnSmcd5W8e0vAuQ rMnK3ZNbPOrMZi8T+q0EpuAVF9hbqnqETNZm2LqMLU93zD+71g9VUfiVNJdCGfn1sA4k EL8rdUUGaH7zqbhbkTcmZwN5NAVWo0Bbvz9yX3tq6Xq4+Tv2p6DXc6miwVuItpyIPeT7 8g0cju94EZlgk6+boE3RdMuQVXMsz7vvpHT1PFVOjgMHFara5sTOb9iaz5HEkTMQCS3Y XM5A== X-Received: by 10.66.190.163 with SMTP id gr3mr31630529pac.117.1424804318949; Tue, 24 Feb 2015 10:58:38 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id go1sm38836070pbd.75.2015.02.24.10.58.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 10:58:38 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8A2CB008-7D8A-4946-9F6B-C07C2E0C6DC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: rc.d provides and recent changes to rc.d scripts in base (was Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy") From: Garrett Cooper In-Reply-To: Date: Tue, 24 Feb 2015 10:58:36 -0800 Message-Id: <6CFFAB58-D5E9-4355-9F0F-1A28CDCD68FF@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> To: Miguel Clara X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 18:58:40 -0000 --Apple-Mail=_8A2CB008-7D8A-4946-9F6B-C07C2E0C6DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 24, 2015, at 10:53, Miguel Clara wrote: >=20 > On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper = wrote: > On Feb 24, 2015, at 6:35, Miguel Clara wrote: >=20 > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `kerberos' > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `named' > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown = provision `unbound' > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `dbus' in file = `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `ldconfig' in file = `/usr/local/etc/rc.d/dnscrypt-proxy'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/devfs'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/mdconfig2'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/newsyslog'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/syslogd'. > > rcorder: Circular dependency on provision `NETWORKING' in file = `/etc/rc.d/kdc'. > > rcorder: Circular dependency on provision `ldconfig' in file = `/etc/rc.d/SERVERS'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/archdep'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/SERVERS'. > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has = no providers. > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has = no providers. > > > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk = =91/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=92 > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `kerberos' > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision = `named' > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown = provision `unbound' > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `dbus' in file = `/usr/local/etc/rc.d/webcamd'. > > rcorder: Circular dependency on provision `ldconfig' in file = `/usr/local/etc/rc.d/dnscrypt-proxy'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/devfs'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/mdconfig2'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/newsyslog'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/syslogd'. > > rcorder: Circular dependency on provision `NETWORKING' in file = `/etc/rc.d/kdc'. > > rcorder: Circular dependency on provision `ldconfig' in file = `/etc/rc.d/SERVERS'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/archdep'. > > rcorder: Circular dependency on provision `mountcritremote' in file = `/etc/rc.d/SERVERS'. > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has = no providers. > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has = no providers. > > cleanvar: Command not found. > > dbus/: Command not found. > > > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE = (adding ldconfig) >=20 > Your rcorder is 50 shades of broken :(. Please remove all local = modifications to scripts, then repost the output of the rcorder commands = again. I suspect what=92s going wrong is the result of some of my = changes to remove etc/rc.d based on build knobs=85 > Cheers, >=20 > So much like the movies them... damn.... :X >=20 > I don't recall any changes to the rc.d scripts except the one to = dnscrypt-proxy (adding the ldconfig REQUIRE) Adding ldconfig can screw everything up, depending on what the ordering = is. Dependency loops can be longer than you think. > I also don't really know what to make of the output... expect this = part: >=20 > "Circular dependency on provision", but the man says: > A set of files has a circular dependency which was detected while = processing the stated condition. >=20 > So it should mean that 'A' requires 'B' but 'B' requires 'A'... but = this does not seem to be the case=85 Not directly, but indirectly, maybe. > I guess I'll have to go one by one and see if I can identify issue. = But first I'll make sure the ports that use those rc.d scripts are up to = date. Some of your ports are depending on named (which is no longer in base), = and unbound (which isn=92t installed if MK_UNBOUND=3Dno). It looks like you=92re installing world with MK_KERBEROS=3Dno. I was going to create a dummy provider called =93DNS=94 for all scripts = to depend on (and named/unbound would PROVIDE: DNS), but it would = require backporting that script everywhere (and I haven=92t done that = quite yet=85). Please also run `make delete-old` and delete any stale rc.d scripts if = prompted by mergemaster/etcupdate. HTH, --Apple-Mail=_8A2CB008-7D8A-4946-9F6B-C07C2E0C6DC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7MncAAoJEMZr5QU6S73enu8IAKOJIdqYwwzGiuo5/UznZQn8 oWuXvBteuBFri1YzkowX3HzjWmxtG53NGV/6GwUPvdaiArUBlbyOjv4tH4lFD6K1 wj9ft9p8J8SDvmElZ2TX1NRPXtBQ8208ifjYa7jy+9vpcS53NAcukmPg+dgq7+3d KewIbD/7Ep1fv8dRArUpfr0GBEDUlqfWqFUFaQviDwb5looVpaeVJvApJwZMRdEl +IXFr7bblmAz1+RvneUKKoSCyrtQsfIvoa28XKjqpNEE9HV3e2rAtoTQ0sEIzM1P KPdC29awrDpP1s3yXJGf2s1IDR3V2qKtV/7htCSEhjIlKbj1zgrx9/46r/eqXhQ= =x+1b -----END PGP SIGNATURE----- --Apple-Mail=_8A2CB008-7D8A-4946-9F6B-C07C2E0C6DC6-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 19:19:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A74F14B for ; Tue, 24 Feb 2015 19:19:05 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24E879BC for ; Tue, 24 Feb 2015 19:19:05 +0000 (UTC) Received: by ierx19 with SMTP id x19so34856769ier.3 for ; Tue, 24 Feb 2015 11:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ukL81O6CIR7/d1WjTX7CMsCJusbl3M34KBVzgicMc2U=; b=QokwwGrCboXUBGbC/wbOZ+2+sWOP8a7zmOeR8wCeqk0CbpC3KckzUCQhxhZQU995Gx BqK8shd17YgiD+GAMFEIfHPE+QIkJFLKVnsXYc3dXY7XhajTeip7fiGAcudP2QqxUc0e KOciMmDzXy6lpVW7j9KzzpfeSMuwpepL1Itg1Rhs+s7Rc3+PjCjNeN+cch90Qsc6bDUp +DBZNUv+ZhP5GIjfglxnjVu5a1KYSYEhiUVg58oUH7aXr5P1kZlGbm1iIzPV+pVbIDoE 7cgYObIbqsHZP57ZzDUa6qWmXwNOGkjHbBSgi5X0V55Hri/rCSWD7rdupOxsUhWp9zXz alMw== X-Received: by 10.50.234.194 with SMTP id ug2mr22397684igc.39.1424805544413; Tue, 24 Feb 2015 11:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 11:18:43 -0800 (PST) In-Reply-To: <6CFFAB58-D5E9-4355-9F0F-1A28CDCD68FF@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <6CFFAB58-D5E9-4355-9F0F-1A28CDCD68FF@gmail.com> From: Miguel Clara Date: Tue, 24 Feb 2015 19:18:43 +0000 Message-ID: Subject: Re: rc.d provides and recent changes to rc.d scripts in base (was Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy") To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 19:19:05 -0000 On Tue, Feb 24, 2015 at 6:58 PM, Garrett Cooper wrote: > On Feb 24, 2015, at 10:53, Miguel Clara wrote: > > > > > On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper > wrote: > > On Feb 24, 2015, at 6:35, Miguel Clara wrote: > > > > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `kerberos' > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `named' > > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > provision `unbound' > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `dbus' in file > `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `ldconfig' in file > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/devfs'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/mdconfig2'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/newsyslog'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/syslogd'. > > > rcorder: Circular dependency on provision `NETWORKING' in file > `/etc/rc.d/kdc'. > > > rcorder: Circular dependency on provision `ldconfig' in file > `/etc/rc.d/SERVERS'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/archdep'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/SERVERS'. > > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > providers. > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > providers. > > > > > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `kerberos' > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `named' > > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > provision `unbound' > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `dbus' in file > `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `ldconfig' in file > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/devfs'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/mdconfig2'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/newsyslog'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/syslogd'. > > > rcorder: Circular dependency on provision `NETWORKING' in file > `/etc/rc.d/kdc'. > > > rcorder: Circular dependency on provision `ldconfig' in file > `/etc/rc.d/SERVERS'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/archdep'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/SERVERS'. > > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > providers. > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > providers. > > > cleanvar: Command not found. > > > dbus/: Command not found. > > > > > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE > (adding ldconfig) > > > > Your rcorder is 50 shades of broken :(. Please remove all local > modifications to scripts, then repost the output of the rcorder commands > again. I suspect what=E2=80=99s going wrong is the result of some of my c= hanges to > remove etc/rc.d based on build knobs=E2=80=A6 > > Cheers, > > > > So much like the movies them... damn.... :X > > > > I don't recall any changes to the rc.d scripts except the one to > dnscrypt-proxy (adding the ldconfig REQUIRE) > > Adding ldconfig can screw everything up, depending on what the ordering > is. Dependency loops can be longer than you think. Hum... removing it gives the same output.. and the issue with the order already existed anyway, so I don't think the change to dnscrypt-proxy is the main issue here... > > I also don't really know what to make of the output... expect this part= : > > > > "Circular dependency on provision", but the man says: > > A set of files has a circular dependency which was detected while > processing the stated condition. > > > > So it should mean that 'A' requires 'B' but 'B' requires 'A'... but thi= s > does not seem to be the case=E2=80=A6 > > Not directly, but indirectly, maybe. > > > I guess I'll have to go one by one and see if I can identify issue. But > first I'll make sure the ports that use those rc.d scripts are up to date= . > > Some of your ports are depending on named (which is no longer in base), > and unbound (which isn=E2=80=99t installed if MK_UNBOUND=3Dno). > > It looks like you=E2=80=99re installing world with MK_KERBEROS=3Dno. > I'm used the provided "GENERIC-NODEBUG" config, and I'm jus running "make installworld" no options... just followed the guide (1). make delete-old and make delete-old-libs were both run... > I was going to create a dummy provider called =E2=80=9CDNS=E2=80=9D for a= ll scripts to > depend on (and named/unbound would PROVIDE: DNS), but it would require > backporting that script everywhere (and I haven=E2=80=99t done that quite= yet=E2=80=A6). > > Please also run `make delete-old` and delete any stale rc.d scripts if > prompted by mergemaster/etcupdate. As stated above make delete-old was run and re-runing show nothing to delete. > > HTH, > (1) https://www.freebsd.org/doc/handbook/makeworld.html From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 23:10:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8ACEEC3; Tue, 24 Feb 2015 23:10:25 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67C0E997; Tue, 24 Feb 2015 23:10:25 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 9F8A51B123; Wed, 25 Feb 2015 00:10:22 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 99F14F257; Wed, 25 Feb 2015 00:10:22 +0100 (CET) Date: Wed, 25 Feb 2015 00:10:22 +0100 From: Kristof Provost To: Davide Italiano Subject: Re: pf crash on -current Message-ID: <20150224231022.GN2181@vega.codepro.be> References: <54EBD112.8050705@freebsd.org> <20150224070547.GH2181@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150224070547.GH2181@vega.codepro.be> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 23:10:25 -0000 On 2015-02-24 08:05:47 (+0100), Kristof Provost wrote: > On 2015-02-23 17:23:55 (-0800), Davide Italiano wrote: > > The bt you posted suggest this could be stack overflow, probably due > > to infinite recursion. > > Also, as a wild guess, just looking at the stacktrace, I think this > > might be related to the recent ipv6 fragment changes. Try to back them > > out, and see if things gets more stable ( r278831 and r278843). > > > That's almost certainly what it is. > After a bit of fiddling around I've managed to reproduce this locally. Essentially we get caught in a loop of defragmenting and refragmenting: Fragmented packets come in on one interface and get collected until we can defragment it. At that point the defragmented packet is handed back to the ip stack (at the pfil point in ip6_input(). Normal processing continues. Eventually we figure out that the packet has to be forwarded and we end up at the pfil hook in ip6_forward(). After doing the inspection on the defragmented packet we see that the packet has been defragmented and because we're forwarding we have to refragment it. That's indicated by the presence of the PF_REASSEMBLED tag. In pf_refragment6() we remove that tag, split the packet up again and then ip6_forward() the individual fragments. Those fragments hit the pfil hook on the way out, so they're collected until we can reconstruct the full packet, at which point we're right back where we left off and things continue until we run out of stack. There are two reasons Allan is seeing this and no one else has so far. The first is that he's scrubbing both on input and output. My own tests have always been done with 'scrub in all fragment reassemble', rather than 'scrub all fragment reassemble' so I didn't see this problem. The second is that he's got an internal interface with a higher MTU, so the refragmentation actually works for him. There's an open problem where ip6_forward() drops the defragmented packet before the pfil(PFIL_OUT) hook because it's too big for the output interface. If the last patch of my series (https://reviews.freebsd.org/D1815) had been merged as well more people would have been affected. One possible fix for Allan's problem would be to tag the fragments after refragmentation so that pf ignores them. After all, the defragmented packet has already been inspected so there's no point in checking the fragments again. I have the feeling there's a way to fix this problem and the issue D1815 tries to fix in one go though. I'll need to think about it a bit more. Regards, Kristof From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 23:11:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F40ABFCE for ; Tue, 24 Feb 2015 23:11:40 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC25EA3F for ; Tue, 24 Feb 2015 23:11:40 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so32422138igb.0 for ; Tue, 24 Feb 2015 15:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uNPBL3X+eex2yMvwCw1U+9qIloKRUhAAhPNl7Mm44es=; b=BhzVScq3UHrqAg44MG+Cx777D635Y0uoqde+nyk+RigQoXYCZOUe5N/T6PLbXMy1iK +4/Y4rztJ0dr1XYn7O25EH8JcTm9f3g0NnuESp0qRcNm3jOg+qAzQE+5F8otG46rQpsl /nERM41MNuviXzlgyJ6emovHpfSUczcEpDsXTvx9KLIGPLFLrJSynn5t5vTCMKOj7B9p IQrp2sPK1VzA7dWL6GrN8CKn73XPjNFGdltGxakisxHn1SpwHQEQn+P8YL0t3yJhpGJY 1KU3jRMcoTfonQXA9WnDmxsa/kxY9dSXIwu2F5etyLswL9lSk3yXuW/i+Dt35RRKVeZe D+Yw== MIME-Version: 1.0 X-Received: by 10.42.170.200 with SMTP id g8mr679845icz.5.1424819500013; Tue, 24 Feb 2015 15:11:40 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Tue, 24 Feb 2015 15:11:39 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> Date: Tue, 24 Feb 2015 15:11:39 -0800 X-Google-Sender-Auth: O6S_uza2yWpKas6JKNkfC4qw8mk Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Feb 2015 23:11:41 -0000 On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara wrote: > On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper > wrote: > > > On Feb 24, 2015, at 6:35, Miguel Clara wrote: > > > > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > > `kerberos' > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > > `named' > > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > > provision `unbound' > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `dbus' in file > > `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `ldconfig' in file > > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/devfs'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/mdconfig2'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/newsyslog'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/syslogd'. > > > rcorder: Circular dependency on provision `NETWORKING' in file > > `/etc/rc.d/kdc'. > > > rcorder: Circular dependency on provision `ldconfig' in file > > `/etc/rc.d/SERVERS'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/archdep'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/SERVERS'. > > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > > providers. > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > > providers. > > > > > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk > > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > > `kerberos' > > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > > `named' > > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown > > provision `unbound' > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `dbus' in file > > `/usr/local/etc/rc.d/webcamd'. > > > rcorder: Circular dependency on provision `ldconfig' in file > > `/usr/local/etc/rc.d/dnscrypt-proxy'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/devfs'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/mdconfig2'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/newsyslog'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/syslogd'. > > > rcorder: Circular dependency on provision `NETWORKING' in file > > `/etc/rc.d/kdc'. > > > rcorder: Circular dependency on provision `ldconfig' in file > > `/etc/rc.d/SERVERS'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/archdep'. > > > rcorder: Circular dependency on provision `mountcritremote' in file > > `/etc/rc.d/SERVERS'. > > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no > > providers. > > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > > providers. > > > cleanvar: Command not found. > > > dbus/: Command not found. > > > > > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE > > (adding ldconfig) > > > > Your rcorder is 50 shades of broken :(. Please remove all local > > modifications to scripts, then repost the output of the rcorder command= s > > again. I suspect what=E2=80=99s going wrong is the result of some of my= changes > to > > remove etc/rc.d based on build knobs=E2=80=A6 > > Cheers, > > > > So much like the movies them... damn.... :X > > I don't recall any changes to the rc.d scripts except the one to > dnscrypt-proxy (adding the ldconfig REQUIRE) > > I also don't really know what to make of the output... expect this part: > > "Circular dependency on provision", but the man says: > A set of files has a circular dependency which was detected while > processing the stated condition. > > So it should mean that 'A' requires 'B' but 'B' requires 'A'... but this > does not seem to be the case... > > I guess I'll have to go one by one and see if I can identify issue. But > first I'll make sure the ports that use those rc.d scripts are up to date= . > Just to save a bit of time, many RC scripts are messed up at install time. One of the worst I have is for security/trousers-tddl. It is a mess. It wants kerberos and named, but most FreeBSD systems no longer run named or kerberos. As far as I can tell, no FreeBSD port provides a tpmd, so I have no idea where the heck that comes from. hald wants usbd which has been obsolete for some years. Certainly no providers any longer. I don't think that any supported version of FreeBSD still has usbd, so any port requiring it should be fixed. Also, webcamd and dbus have a circular dependency. It really needs to be fixed some time, but does not break anything. I suspect that whatever is causing the multiple circular dependencies on mountcritremote might be tied to the issue. I don't see the obvious problem here and I don't have it. Circular dependencies are a real pain to track down as they are often not direct. A required E and G and B requires A. But the rcorder only knows that. It does not report that E does require B and just reports that A is a circular dependency. (I hope that makes some sense.) Normally mountcritremote should be very soon after NETWORKING...usually after NETWORKING and netwait. This means it should run right after the network starts and before anything that depends on the network. rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this with ldconfig right after mountcritremote. There is no reason that devfs, syslogd or any of the others listed should precede mountcritremote! The errors indicate that SOMETHING before NETWORKING and netwait is causing all of these other things to run and, BOOM, your script is firing off before ldconfig is run. Good luck! It will likely be tedious, but looking at the output of rcorder should point the finger in at least the right direction. Hete is an exerpt from mine in the area where these things belong: /etc/rc.d/NETWORKING /etc/rc.d/netwait /etc/rc.d/mountcritremote /etc/rc.d/ldconfig /etc/rc.d/accounting /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/ntpdate /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/devfs /etc/rc.d/ipmon /etc/rc.d/mdconfig2 /etc/rc.d/kdc --=20 Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 00:26:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4E8E1A9 for ; Wed, 25 Feb 2015 00:26:33 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D3C5199 for ; Wed, 25 Feb 2015 00:26:33 +0000 (UTC) Received: by iecar1 with SMTP id ar1so781828iec.0 for ; Tue, 24 Feb 2015 16:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/r6TxtLXo1tFWwH8OvHYDLGBrecYmJClsu+HYoltyHw=; b=bXsyaHfarwgHZsfE1ejk1upPnMLMFed7CAWdJfMH4kami3FdhmfCDLlXfEl1TsXXat L8XfPIVTGZeYc1LvtvKQtGvqquiASDZCgbWAKQuE4nD3gjczV1j6F9EzrLU5g2PMqvqm rWFjojsWt+sPe2zNgkb9fpOjre4kgM+cowucA9NpO4inxBO70x9jZo7Vypz1fibuFi97 uTYSHslZ+hRvOVAOVDm0zMvhhCudLi1yV+hI1UkIs8U00Oqcm4tjUIvjgUY9kqwT9DdF XjworxX8Q6o4jZ1mYO9c8C6vgJHUw9aJLPo3x7PLwuxZHUUusu8wUeXIPSJf8MPdx0ei gYpA== X-Received: by 10.42.201.78 with SMTP id ez14mr1080983icb.22.1424823992666; Tue, 24 Feb 2015 16:26:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 16:26:12 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> From: Miguel Clara Date: Wed, 25 Feb 2015 00:26:12 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 00:26:33 -0000 On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman wrote= : > On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara > wrote: > >> On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper >> wrote: >> >> > On Feb 24, 2015, at 6:35, Miguel Clara wrote: >> > >> > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null >> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> > `kerberos' >> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> > `named' >> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown >> > provision `unbound' >> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >> > > rcorder: Circular dependency on provision `dbus' in file >> > `/usr/local/etc/rc.d/webcamd'. >> > > rcorder: Circular dependency on provision `ldconfig' in file >> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/devfs'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/mdconfig2'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/newsyslog'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/syslogd'. >> > > rcorder: Circular dependency on provision `NETWORKING' in file >> > `/etc/rc.d/kdc'. >> > > rcorder: Circular dependency on provision `ldconfig' in file >> > `/etc/rc.d/SERVERS'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/archdep'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/SERVERS'. >> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has n= o >> > providers. >> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has n= o >> > providers. >> > > >> > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk >> > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 >> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> > `kerberos' >> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> > `named' >> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknown >> > provision `unbound' >> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >> > > rcorder: Circular dependency on provision `dbus' in file >> > `/usr/local/etc/rc.d/webcamd'. >> > > rcorder: Circular dependency on provision `ldconfig' in file >> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/devfs'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/mdconfig2'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/newsyslog'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/syslogd'. >> > > rcorder: Circular dependency on provision `NETWORKING' in file >> > `/etc/rc.d/kdc'. >> > > rcorder: Circular dependency on provision `ldconfig' in file >> > `/etc/rc.d/SERVERS'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/archdep'. >> > > rcorder: Circular dependency on provision `mountcritremote' in file >> > `/etc/rc.d/SERVERS'. >> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has n= o >> > providers. >> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has n= o >> > providers. >> > > cleanvar: Command not found. >> > > dbus/: Command not found. >> > > >> > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE >> > (adding ldconfig) >> > >> > Your rcorder is 50 shades of broken :(. Please remove all local >> > modifications to scripts, then repost the output of the rcorder comman= ds >> > again. I suspect what=E2=80=99s going wrong is the result of some of m= y changes >> to >> > remove etc/rc.d based on build knobs=E2=80=A6 >> > Cheers, >> > >> >> So much like the movies them... damn.... :X >> >> I don't recall any changes to the rc.d scripts except the one to >> dnscrypt-proxy (adding the ldconfig REQUIRE) >> >> I also don't really know what to make of the output... expect this part: >> >> "Circular dependency on provision", but the man says: >> A set of files has a circular dependency which was detected while >> processing the stated condition. >> >> So it should mean that 'A' requires 'B' but 'B' requires 'A'... but this >> does not seem to be the case... >> >> I guess I'll have to go one by one and see if I can identify issue. But >> first I'll make sure the ports that use those rc.d scripts are up to dat= e. >> > > Just to save a bit of time, many RC scripts are messed up at install time= . > > One of the worst I have is for security/trousers-tddl. It is a mess. It > wants kerberos and named, but most FreeBSD systems no longer run named or > kerberos. As far as I can tell, no FreeBSD port provides a tpmd, so I hav= e > no idea where the heck that comes from. > > hald wants usbd which has been obsolete for some years. Certainly no > providers any longer. I don't think that any supported version of FreeBSD > still has usbd, so any port requiring it should be fixed. > > Also, webcamd and dbus have a circular dependency. It really needs to be > fixed some time, but does not break anything. > > I suspect that whatever is causing the multiple circular dependencies on > mountcritremote might be tied to the issue. I don't see the obvious probl= em > here and I don't have it. Circular dependencies are a real pain to track > down as they are often not direct. A required E and G and B requires A. B= ut > the rcorder only knows that. It does not report that E does require B and > just reports that A is a circular dependency. (I hope that makes some > sense.) > > Normally mountcritremote should be very soon after NETWORKING...usually > after NETWORKING and netwait. This means it should run right after the > network starts and before anything that depends on the network. > rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this with > ldconfig right after mountcritremote. There is no reason that devfs, > syslogd or any of the others listed should precede mountcritremote! The > errors indicate that SOMETHING before NETWORKING and netwait is causing a= ll > of these other things to run and, BOOM, your script is firing off before > ldconfig is run. > > Good luck! It will likely be tedious, but looking at the output of rcorde= r > should point the finger in at least the right direction. Hete is an exerp= t > from mine in the area where these things belong: > /etc/rc.d/NETWORKING > /etc/rc.d/netwait > /etc/rc.d/mountcritremote > /etc/rc.d/ldconfig > /etc/rc.d/accounting > /etc/rc.d/newsyslog > /etc/rc.d/syslogd > /etc/rc.d/ntpdate > /etc/rc.d/rpcbind > /etc/rc.d/nfsclient > /etc/rc.d/devfs > /etc/rc.d/ipmon > /etc/rc.d/mdconfig2 > /etc/rc.d/kdc > Kevin... many thanks, for this I was really thinking the same... "I just installed the ports and the system was upgrade properly WTH did I do wrong"= . I've reinstalled the the ports of the affected scripts to be sure I'm running the most updated version, I still see the issues so now I'lll have to go one by one and see if I can fix them, or maybe start by moving them elsewhere and run rcorder until its happy and then move back one by one and rcorder should start complaining... But just so I try to understand this better.... dbus and webcamd have a circular dependency... is this beacause: webcamd requires "FILESYSTEMS netif dbus" dbus requires "DAEMON ldconfig" And then ldconfig also requires FILESYSTEMS? > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 00:51:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74270709 for ; Wed, 25 Feb 2015 00:51:18 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7C83DE for ; Wed, 25 Feb 2015 00:51:17 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id BA482977B5 for ; Wed, 25 Feb 2015 00:51:16 +0000 (UTC) Message-ID: <54ED1C88.7020703@freebsd.org> Date: Tue, 24 Feb 2015 19:51:20 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pf crash on -current References: <54EBD112.8050705@freebsd.org> <20150224070547.GH2181@vega.codepro.be> <20150224231022.GN2181@vega.codepro.be> In-Reply-To: <20150224231022.GN2181@vega.codepro.be> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 00:51:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-02-24 18:10, Kristof Provost wrote: > On 2015-02-24 08:05:47 (+0100), Kristof Provost wr= ote: >> On 2015-02-23 17:23:55 (-0800), Davide Italiano w= rote: >>> The bt you posted suggest this could be stack overflow, probably due >>> to infinite recursion. >>> Also, as a wild guess, just looking at the stacktrace, I think this >>> might be related to the recent ipv6 fragment changes. Try to back the= m >>> out, and see if things gets more stable ( r278831 and r278843). >>> >> That's almost certainly what it is. >> > After a bit of fiddling around I've managed to reproduce this locally. >=20 > Essentially we get caught in a loop of defragmenting and refragmenting:= > Fragmented packets come in on one interface and get collected until we > can defragment it. At that point the defragmented packet is handed back= > to the ip stack (at the pfil point in ip6_input(). Normal processing > continues. > Eventually we figure out that the packet has to be forwarded and we end= > up at the pfil hook in ip6_forward(). After doing the inspection on the= > defragmented packet we see that the packet has been defragmented and > because we're forwarding we have to refragment it. That's indicated by > the presence of the PF_REASSEMBLED tag. >=20 > In pf_refragment6() we remove that tag, split the packet up again and > then ip6_forward() the individual fragments. > Those fragments hit the pfil hook on the way out, so they're > collected until we can reconstruct the full packet, at which point we'r= e > right back where we left off and things continue until we run out of > stack. >=20 > There are two reasons Allan is seeing this and no one else has so far. >=20 > The first is that he's scrubbing both on input and output. My own tests= > have always been done with 'scrub in all fragment reassemble', rather > than 'scrub all fragment reassemble' so I didn't see this problem. >=20 > The second is that he's got an internal interface with a higher MTU, > so the refragmentation actually works for him. > There's an open problem where ip6_forward() drops the defragmented > packet before the pfil(PFIL_OUT) hook because it's too big for the > output interface. > If the last patch of my series (https://reviews.freebsd.org/D1815) had > been merged as well more people would have been affected. >=20 > One possible fix for Allan's problem would be to tag the fragments afte= r > refragmentation so that pf ignores them. After all, the defragmented > packet has already been inspected so there's no point in checking the > fragments again. >=20 > I have the feeling there's a way to fix this problem and the issue D181= 5 > tries to fix in one go though. I'll need to think about it a bit more. >=20 > Regards, > Kristof > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Admittedly, when I switched from using pfSense to vanilla FreeBSD for my firewall, when I got new hardware and wanted to run bhyve as well, i just dumped the rules from my pfsense into a file and then started editing by hand. So the scrub rule was not really a decision I made, but was inherited from the pfsense. It is actually my external interface (point-to-point fibre transport from my basement to the data center) that has the higher MTU (4400), whereas my internal network is all standard 1500 MTU. --=20 Allan Jude --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJU7RyLAAoJEJrBFpNRJZKfKgAP/Au7s8eDon8h6RN+B+M+6s8V 5/Ol5VQFEi01KQRBDbXe4h+8FPPzXJIhIDISrNQf8CCoNcc1gZXL4/2Z6zpLEFvX UGMPQykiy7/oOFvjyICNzd/UXq4Aq5z/ayVViZQ7xgj9LForjYxbt/lZf7IvkaFr G8AMQ0EV76rycUBsGhKZMU3ZMOZQzP7AfkZ13GgKA4rzuKa7I6+fNvhVK+vyzHgx Vre4HKhYPhCVH8U/5nFDBbOKIIZjX61aXMcX6p09yM19tUgWtM839cSv7PwIYdAA w008LZqP9h72uwp+mq1d8HHSfpUaHAKa3HlkgzAbC1kESFwPbaMTmrqeUA2HcZtI tG1/ZTFWwTnaL+tRHk1EtdPuxSZWJ8kXmcihiCqYILL8xaUZSDaL+t5oqAP2e9Ut ULMkE1Rz+oCIbe6teOAd9HPjYzWAwsD0arPIrOefM06TOKGwz4pYPhz/dtcwU+aa booFxCMTeOV4NZOH6Cdt8UkEocn0naxnqvXlANgqALViP08rJ4c948/ZaPRZRBYJ OO1m+y43/izL1f8gwhaMBDffkAzsw90e/YLcay3H6kdnOIIiXsdkTH5d9kFPDX03 Xf0JpqfmRn9Ja6b2pE7LqRyS0XVZ68Y+VzJ2MvOcu/CPijY7peqGxjdHiCNFZugf lc3cC6l6zuCYRCVBoHBO =q9nr -----END PGP SIGNATURE----- --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 01:58:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7D81A8C for ; Wed, 25 Feb 2015 01:58:56 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87F9CD1F for ; Wed, 25 Feb 2015 01:58:56 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h15so31862348igd.4 for ; Tue, 24 Feb 2015 17:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mKP1ZXUnNTdHXXtLfF5IlGOcvcrctvkfRhcwzl6vUII=; b=TANgwXces1m4lJKyAevcaUaVE9R18VClZj59AtyKuqwq+rZxjuDV4SfW2yLyTZjWK8 OLdF5TdvwHO+BByUaEuxsquIiqnP6knH3AQI1nqe3B6IVp6B2nFWGlaNLKchegTIgKK5 QOYiRT27Nr1CMFQSIPAqbrMzOgQYGugYFxCwp0Paw+YVJLdIcPuYM6jFuWyjmvDj99L5 GTbPQdehLrrOD5cAwXQOsWV6NTug93rr+XpeMbOsQKPt5FOAQdDG+sbeHfXRXR+Po9Cd RKvwkAU9i4qj9rtLWjL6j+eE81Y4Vs+Lek6MkK/0dRiOH+gSx211VO+K701DZeyPmOcx JzoQ== X-Received: by 10.50.50.142 with SMTP id c14mr1644141igo.42.1424829535638; Tue, 24 Feb 2015 17:58:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 17:58:35 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> From: Miguel Clara Date: Wed, 25 Feb 2015 01:58:35 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 01:58:57 -0000 On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara wrote: > > On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman > wrote: > >> On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara >> wrote: >> >>> On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper >>> wrote: >>> >>> > On Feb 24, 2015, at 6:35, Miguel Clara wrote= : >>> > >>> > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null >>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisio= n >>> > `kerberos' >>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisio= n >>> > `named' >>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknow= n >>> > provision `unbound' >>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >>> > > rcorder: Circular dependency on provision `dbus' in file >>> > `/usr/local/etc/rc.d/webcamd'. >>> > > rcorder: Circular dependency on provision `ldconfig' in file >>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/devfs'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/mdconfig2'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/newsyslog'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/syslogd'. >>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>> > `/etc/rc.d/kdc'. >>> > > rcorder: Circular dependency on provision `ldconfig' in file >>> > `/etc/rc.d/SERVERS'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/archdep'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/SERVERS'. >>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has = no >>> > providers. >>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has = no >>> > providers. >>> > > >>> > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk >>> > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 >>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisio= n >>> > `kerberos' >>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisio= n >>> > `named' >>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unknow= n >>> > provision `unbound' >>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >>> > > rcorder: Circular dependency on provision `dbus' in file >>> > `/usr/local/etc/rc.d/webcamd'. >>> > > rcorder: Circular dependency on provision `ldconfig' in file >>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/devfs'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/mdconfig2'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/newsyslog'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/syslogd'. >>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>> > `/etc/rc.d/kdc'. >>> > > rcorder: Circular dependency on provision `ldconfig' in file >>> > `/etc/rc.d/SERVERS'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/archdep'. >>> > > rcorder: Circular dependency on provision `mountcritremote' in file >>> > `/etc/rc.d/SERVERS'. >>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has = no >>> > providers. >>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has = no >>> > providers. >>> > > cleanvar: Command not found. >>> > > dbus/: Command not found. >>> > > >>> > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE >>> > (adding ldconfig) >>> > >>> > Your rcorder is 50 shades of broken :(. Please remove all local >>> > modifications to scripts, then repost the output of the rcorder >>> commands >>> > again. I suspect what=E2=80=99s going wrong is the result of some of = my >>> changes to >>> > remove etc/rc.d based on build knobs=E2=80=A6 >>> > Cheers, >>> > >>> >>> So much like the movies them... damn.... :X >>> >>> I don't recall any changes to the rc.d scripts except the one to >>> dnscrypt-proxy (adding the ldconfig REQUIRE) >>> >>> I also don't really know what to make of the output... expect this part= : >>> >>> "Circular dependency on provision", but the man says: >>> A set of files has a circular dependency which was detected while >>> processing the stated condition. >>> >>> So it should mean that 'A' requires 'B' but 'B' requires 'A'... but thi= s >>> does not seem to be the case... >>> >>> I guess I'll have to go one by one and see if I can identify issue. But >>> first I'll make sure the ports that use those rc.d scripts are up to >>> date. >>> >> >> Just to save a bit of time, many RC scripts are messed up at install >> time. >> >> One of the worst I have is for security/trousers-tddl. It is a mess. It >> wants kerberos and named, but most FreeBSD systems no longer run named o= r >> kerberos. As far as I can tell, no FreeBSD port provides a tpmd, so I ha= ve >> no idea where the heck that comes from. >> >> hald wants usbd which has been obsolete for some years. Certainly no >> providers any longer. I don't think that any supported version of FreeBS= D >> still has usbd, so any port requiring it should be fixed. >> >> Also, webcamd and dbus have a circular dependency. It really needs to be >> fixed some time, but does not break anything. >> >> I suspect that whatever is causing the multiple circular dependencies on >> mountcritremote might be tied to the issue. I don't see the obvious prob= lem >> here and I don't have it. Circular dependencies are a real pain to track >> down as they are often not direct. A required E and G and B requires A. = But >> the rcorder only knows that. It does not report that E does require B an= d >> just reports that A is a circular dependency. (I hope that makes some >> sense.) >> >> Normally mountcritremote should be very soon after NETWORKING...usually >> after NETWORKING and netwait. This means it should run right after the >> network starts and before anything that depends on the network. >> rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this with >> ldconfig right after mountcritremote. There is no reason that devfs, >> syslogd or any of the others listed should precede mountcritremote! The >> errors indicate that SOMETHING before NETWORKING and netwait is causing = all >> of these other things to run and, BOOM, your script is firing off before >> ldconfig is run. >> >> Good luck! It will likely be tedious, but looking at the output of >> rcorder should point the finger in at least the right direction. Hete is= an >> exerpt from mine in the area where these things belong: >> /etc/rc.d/NETWORKING >> /etc/rc.d/netwait >> /etc/rc.d/mountcritremote >> /etc/rc.d/ldconfig >> /etc/rc.d/accounting >> /etc/rc.d/newsyslog >> /etc/rc.d/syslogd >> /etc/rc.d/ntpdate >> /etc/rc.d/rpcbind >> /etc/rc.d/nfsclient >> /etc/rc.d/devfs >> /etc/rc.d/ipmon >> /etc/rc.d/mdconfig2 >> /etc/rc.d/kdc >> > > Kevin... many thanks, for this I was really thinking the same... "I just > installed the ports and the system was upgrade properly WTH did I do wron= g". > > I've reinstalled the the ports of the affected scripts to be sure I'm > running the most updated version, I still see the issues so now I'lll hav= e > to go one by one and see if I can fix them, or maybe start by moving them > elsewhere and run rcorder until its happy and then move back one by one a= nd > rcorder should start complaining... > > But just so I try to understand this better.... dbus and webcamd have a > circular dependency... is this beacause: > webcamd requires "FILESYSTEMS netif dbus" > dbus requires "DAEMON ldconfig" > > And then ldconfig also requires FILESYSTEMS? > > > Acctaully dnscrypt-proxy is running just after SERVERS and this requires ldconfig but does not run it before... Example: etc/rc.d/netif /etc/rc.d/devd /etc/rc.d/ipsec rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/devfs'. /etc/rc.d/devfs /etc/rc.d/ipmon rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/mdconfig2'. /etc/rc.d/mdconfig2 rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/newsyslog'. /etc/rc.d/newsyslog rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/syslogd'. /etc/rc.d/syslogd rcorder: Circular dependency on provision `NETWORKING' in file `/etc/rc.d/kdc'. /etc/rc.d/kdc /etc/rc.d/watchdogd /etc/rc.d/savecore rcorder: Circular dependency on provision `ldconfig' in file `/etc/rc.d/SERVERS'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/archdep'. /etc/rc.d/archdep /etc/rc.d/abi rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/SERVERS'. /etc/rc.d/SERVERS /usr/local/etc/rc.d/dnscrypt-proxy /etc/rc.d/resolv /etc/rc.d/local_unbound /etc/rc.d/atm2 /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/stf /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/mroute6d /etc/rc.d/nsswitch /etc/rc.d/rtsold /etc/rc.d/static_ndp /etc/rc.d/static_arp /etc/rc.d/bridge /etc/rc.d/route6d /etc/rc.d/routed /etc/rc.d/defaultroute /etc/rc.d/ipfw /etc/rc.d/NETWORKING If I just leave SERVERS out of dnscrypt-proxy the order seems ok (not sure if perfect). SERVERS now runs after NETWORKING, and still runs because DEAMON requires SERVERS and a bunch of the rc.d's require DEAMON ofc... Now its more like this (just shoing some to proof dnscrypt-proxy is better placed now: % rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | egrep "SERVERS|ldconfig|dnscrypt|DAEMON|NETWORKING|FILESYSTEMS|sshd" rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `kerberos' rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `named= ' rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on provision `dbus' in file `/usr/local/etc/rc.d/webcamd'. rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no providers. /etc/rc.d/FILESYSTEMS /etc/rc.d/NETWORKING /etc/rc.d/ldconfig /etc/rc.d/SERVERS /etc/rc.d/DAEMON /etc/rc.d/sshd /usr/local/etc/rc.d/dnscrypt-proxy So basically if SERVERS is required by dnscrypt-proxy ldconfig (and others) complain about "Circular dependency" issues and don't run, I have no idea why, but could somebody try to replicate the issue in freebsd current (by installing dnscrypt-proxy I mean)? thanks > >> -- >> Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com >> > > From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 02:05:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A814C00 for ; Wed, 25 Feb 2015 02:05:41 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10974DF6 for ; Wed, 25 Feb 2015 02:05:41 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so33199551igb.0 for ; Tue, 24 Feb 2015 18:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WgxgFRinvuuYx9VBYbUUFKKu4qphq1+Ez3WZe7iz0NI=; b=dX4Yop7iiVTzW9tN3TwNv95y5TxeVv303AvxQEOPi7+qqs96Yab1D6K8c4sDF/47OT s6e403bTk9LM3NNXtBBkQqIdmkkzEretMBQi2EEc4+jBZBYGAksBheaNCExhqTX6/kTS PwT+pvPxv7DITnwDnsYboXFQmrvi1lVvuAs106NUDzybeZbjuZSs1yC0Qcjy8Q5kZs9w iemfyw75DmWAN5a9VOXHEDN6w2vURZwLy49qzExLYmIXgRqbOUQBP6h+8vnU/9IiE3ef 0W3yJgA8xzi/Rv1T1gIkFbnfYqh2gZKD5e6LqRNYNA5r6g1R9TX1eYUupxO4hh81bueC fbBw== X-Received: by 10.50.32.33 with SMTP id f1mr1692354igi.9.1424829940565; Tue, 24 Feb 2015 18:05:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Tue, 24 Feb 2015 18:05:19 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> From: Miguel Clara Date: Wed, 25 Feb 2015 02:05:19 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 02:05:41 -0000 On Wed, Feb 25, 2015 at 1:58 AM, Miguel Clara wrote: > > On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara > wrote: > >> >> On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman >> wrote: >> >>> On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara >>> wrote: >>> >>>> On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper >>>> wrote: >>>> >>>> > On Feb 24, 2015, at 6:35, Miguel Clara >>>> wrote: >>>> > >>>> > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null >>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisi= on >>>> > `kerberos' >>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisi= on >>>> > `named' >>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unkno= wn >>>> > provision `unbound' >>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'= . >>>> > > rcorder: Circular dependency on provision `dbus' in file >>>> > `/usr/local/etc/rc.d/webcamd'. >>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/devfs'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/mdconfig2'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/newsyslog'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/syslogd'. >>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>> > `/etc/rc.d/kdc'. >>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>> > `/etc/rc.d/SERVERS'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/archdep'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/SERVERS'. >>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has >>>> no >>>> > providers. >>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has >>>> no >>>> > providers. >>>> > > >>>> > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk >>>> > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 >>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisi= on >>>> > `kerberos' >>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provisi= on >>>> > `named' >>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before unkno= wn >>>> > provision `unbound' >>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'= . >>>> > > rcorder: Circular dependency on provision `dbus' in file >>>> > `/usr/local/etc/rc.d/webcamd'. >>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/devfs'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/mdconfig2'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/newsyslog'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/syslogd'. >>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>> > `/etc/rc.d/kdc'. >>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>> > `/etc/rc.d/SERVERS'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/archdep'. >>>> > > rcorder: Circular dependency on provision `mountcritremote' in fil= e >>>> > `/etc/rc.d/SERVERS'. >>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has >>>> no >>>> > providers. >>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has >>>> no >>>> > providers. >>>> > > cleanvar: Command not found. >>>> > > dbus/: Command not found. >>>> > > >>>> > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE >>>> > (adding ldconfig) >>>> > >>>> > Your rcorder is 50 shades of broken :(. Please remove all local >>>> > modifications to scripts, then repost the output of the rcorder >>>> commands >>>> > again. I suspect what=E2=80=99s going wrong is the result of some of= my >>>> changes to >>>> > remove etc/rc.d based on build knobs=E2=80=A6 >>>> > Cheers, >>>> > >>>> >>>> So much like the movies them... damn.... :X >>>> >>>> I don't recall any changes to the rc.d scripts except the one to >>>> dnscrypt-proxy (adding the ldconfig REQUIRE) >>>> >>>> I also don't really know what to make of the output... expect this par= t: >>>> >>>> "Circular dependency on provision", but the man says: >>>> A set of files has a circular dependency which was detected while >>>> processing the stated condition. >>>> >>>> So it should mean that 'A' requires 'B' but 'B' requires 'A'... but th= is >>>> does not seem to be the case... >>>> >>>> I guess I'll have to go one by one and see if I can identify issue. Bu= t >>>> first I'll make sure the ports that use those rc.d scripts are up to >>>> date. >>>> >>> >>> Just to save a bit of time, many RC scripts are messed up at install >>> time. >>> >>> One of the worst I have is for security/trousers-tddl. It is a mess. It >>> wants kerberos and named, but most FreeBSD systems no longer run named = or >>> kerberos. As far as I can tell, no FreeBSD port provides a tpmd, so I h= ave >>> no idea where the heck that comes from. >>> >>> hald wants usbd which has been obsolete for some years. Certainly no >>> providers any longer. I don't think that any supported version of FreeB= SD >>> still has usbd, so any port requiring it should be fixed. >>> >>> Also, webcamd and dbus have a circular dependency. It really needs to b= e >>> fixed some time, but does not break anything. >>> >>> I suspect that whatever is causing the multiple circular dependencies o= n >>> mountcritremote might be tied to the issue. I don't see the obvious pro= blem >>> here and I don't have it. Circular dependencies are a real pain to trac= k >>> down as they are often not direct. A required E and G and B requires A.= But >>> the rcorder only knows that. It does not report that E does require B a= nd >>> just reports that A is a circular dependency. (I hope that makes some >>> sense.) >>> >>> Normally mountcritremote should be very soon after NETWORKING...usually >>> after NETWORKING and netwait. This means it should run right after the >>> network starts and before anything that depends on the network. >>> rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this with >>> ldconfig right after mountcritremote. There is no reason that devfs, >>> syslogd or any of the others listed should precede mountcritremote! The >>> errors indicate that SOMETHING before NETWORKING and netwait is causing= all >>> of these other things to run and, BOOM, your script is firing off befor= e >>> ldconfig is run. >>> >>> Good luck! It will likely be tedious, but looking at the output of >>> rcorder should point the finger in at least the right direction. Hete i= s an >>> exerpt from mine in the area where these things belong: >>> /etc/rc.d/NETWORKING >>> /etc/rc.d/netwait >>> /etc/rc.d/mountcritremote >>> /etc/rc.d/ldconfig >>> /etc/rc.d/accounting >>> /etc/rc.d/newsyslog >>> /etc/rc.d/syslogd >>> /etc/rc.d/ntpdate >>> /etc/rc.d/rpcbind >>> /etc/rc.d/nfsclient >>> /etc/rc.d/devfs >>> /etc/rc.d/ipmon >>> /etc/rc.d/mdconfig2 >>> /etc/rc.d/kdc >>> >> >> Kevin... many thanks, for this I was really thinking the same... "I just >> installed the ports and the system was upgrade properly WTH did I do wro= ng". >> >> I've reinstalled the the ports of the affected scripts to be sure I'm >> running the most updated version, I still see the issues so now I'lll ha= ve >> to go one by one and see if I can fix them, or maybe start by moving the= m >> elsewhere and run rcorder until its happy and then move back one by one = and >> rcorder should start complaining... >> >> But just so I try to understand this better.... dbus and webcamd have a >> circular dependency... is this beacause: >> webcamd requires "FILESYSTEMS netif dbus" >> dbus requires "DAEMON ldconfig" >> >> And then ldconfig also requires FILESYSTEMS? >> >> >> > Acctaully dnscrypt-proxy is running just after SERVERS and this requires > ldconfig but does not run it before... Example: > > etc/rc.d/netif > /etc/rc.d/devd > /etc/rc.d/ipsec > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/devfs'. > /etc/rc.d/devfs > /etc/rc.d/ipmon > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/mdconfig2'. > /etc/rc.d/mdconfig2 > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/newsyslog'. > /etc/rc.d/newsyslog > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/syslogd'. > /etc/rc.d/syslogd > rcorder: Circular dependency on provision `NETWORKING' in file > `/etc/rc.d/kdc'. > /etc/rc.d/kdc > /etc/rc.d/watchdogd > /etc/rc.d/savecore > rcorder: Circular dependency on provision `ldconfig' in file > `/etc/rc.d/SERVERS'. > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/archdep'. > /etc/rc.d/archdep > /etc/rc.d/abi > rcorder: Circular dependency on provision `mountcritremote' in file > `/etc/rc.d/SERVERS'. > /etc/rc.d/SERVERS > /usr/local/etc/rc.d/dnscrypt-proxy > /etc/rc.d/resolv > /etc/rc.d/local_unbound > /etc/rc.d/atm2 > /etc/rc.d/pfsync > /etc/rc.d/pflog > /etc/rc.d/pf > /etc/rc.d/stf > /etc/rc.d/ppp > /etc/rc.d/routing > /etc/rc.d/mroute6d > /etc/rc.d/nsswitch > /etc/rc.d/rtsold > /etc/rc.d/static_ndp > /etc/rc.d/static_arp > /etc/rc.d/bridge > /etc/rc.d/route6d > /etc/rc.d/routed > /etc/rc.d/defaultroute > /etc/rc.d/ipfw > /etc/rc.d/NETWORKING > > > If I just leave SERVERS out of dnscrypt-proxy the order seems ok (not sur= e > if perfect). > SERVERS now runs after NETWORKING, and still runs because DEAMON requires > SERVERS and a bunch of the rc.d's require DEAMON ofc... > > Now its more like this (just shoing some to proof dnscrypt-proxy is bette= r > placed now: > % rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | egrep > "SERVERS|ldconfig|dnscrypt|DAEMON|NETWORKING|FILESYSTEMS|sshd" > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `kerberos' > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision > `named' > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on provision `dbus' in file > `/usr/local/etc/rc.d/webcamd'. > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no > providers. > /etc/rc.d/FILESYSTEMS > /etc/rc.d/NETWORKING > /etc/rc.d/ldconfig > /etc/rc.d/SERVERS > /etc/rc.d/DAEMON > /etc/rc.d/sshd > /usr/local/etc/rc.d/dnscrypt-proxy > > > So basically if SERVERS is required by dnscrypt-proxy ldconfig (and > others) complain about "Circular dependency" issues and don't run, I have > no idea why, but could somebody try to replicate the issue in freebsd > current (by installing dnscrypt-proxy I mean)? > > thanks > > Actually I have another box with Current: I can not reproduce the issue, dnscrypt and SERVERS have the same in "REQUIRE" The order machine as a older kernel/world version: FreeBSD hpbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #7 b6a4dfa(master)-dirty: Tue Feb 10 22:21:46 WET 2015 root@hpbsd:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd FreeBSD r2d2 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r279098+c2ec8fb(master)-dirty <--- this is the one where I see the issue! > >> >>> -- >>> Kevin Oberman, Network Engineer, Retired >>> E-mail: rkoberman@gmail.com >>> >> >> > From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 12:12:04 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1CF6EB; Wed, 25 Feb 2015 12:12:04 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 77AC9D76; Wed, 25 Feb 2015 12:12:04 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D49831FE022; Wed, 25 Feb 2015 13:12:00 +0100 (CET) Message-ID: <54EDBC3F.1030302@selasky.org> Date: Wed, 25 Feb 2015 13:12:47 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dervishe , "freebsd-current@FreeBSD.org" Subject: Re: [Call for testers] DRM device-independent code update to Linux 3.8 References: <20150220221246.661f2d01@shibato> <1227462529.6746581.1424602457182.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1227462529.6746581.1424602457182.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-x11@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 12:12:04 -0000 The -h patch Works for me, tested on a mac book pro. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 12:55:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FBD9443 for ; Wed, 25 Feb 2015 12:55:16 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28F86262 for ; Wed, 25 Feb 2015 12:55:15 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id B30BE40A99 for ; Wed, 25 Feb 2015 12:46:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1424868387; bh=52Qrn6wrZMso2gJDCNQcoAdk4kl/klqyJWQ5O0ocFLs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=F8N6okZsDPBTK9tosa1izuX5GKzhqcn3JXpSvTtduC9o6H0GryVvGJb+mUNgx6zg+ 0LXcLiqLl4YJaOyO5cCzV1mAKpCqZFhNnPM4s5OyevoEbBFDb4LYOjipAU0RIdSrdj ofWcCpbnwo72r9iZVBMkR1iazoVYONIc2qVrSins= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 0EB2B23266 Message-ID: <54EDC41F.1010506@riseup.net> Date: Wed, 25 Feb 2015 13:46:23 +0100 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Shared object "libsodium.so.13" not found, required by, "dnscrypt-proxy" References: In-Reply-To: X-Virus-Scanned: clamav-milter 0.98.5 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Wed, 25 Feb 2015 13:27:01 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 12:55:16 -0000 Although I'm not on CURRENT, I can reproduce this problem on my PC's running 10.1-RELEASE. It started on 31st January on only 1 PC and then appeared on others after a few days. I update ports on a daily basis, so that may be a hint. Strangely, only 3 of 5 of my computers are affected. Once it appears during a reboot, it never goes away during other reboots, so manual start of dnscrypt-proxy is required. The same also happens with fuse on another computer, but that is a separate issue. From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 13:40:28 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E52370 for ; Wed, 25 Feb 2015 13:40:28 +0000 (UTC) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx143.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3D9E937 for ; Wed, 25 Feb 2015 13:40:27 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,645,1418112000"; d="asc'?scan'208";a="25917339" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 25 Feb 2015 05:34:52 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 25 Feb 2015 05:34:52 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::90b4:b24a:2e3b:2056%21]) with mapi id 15.00.0995.031; Wed, 25 Feb 2015 05:34:52 -0800 From: "Eggert, Lars" To: "current@freebsd.org" Subject: FreeBSD FUSE calls truncate() on read-only files Thread-Topic: FreeBSD FUSE calls truncate() on read-only files Thread-Index: AQHQUP/VwHChp6TwukC1a1H1Ww9z6w== Date: Wed, 25 Feb 2015 13:34:52 +0000 Message-ID: <6676D082-5C06-4E59-B22C-5C00D1FD229F@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_CB347791-2515-49DA-B930-B709DD527588"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 13:40:28 -0000 --Apple-Mail=_CB347791-2515-49DA-B930-B709DD527588 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this came up when trying to port tup (https://github.com/gittup/tup) to = FreeBSD. Even though we are opening the file read-only with cat, FUSE calls = truncate() on it, which modifies its mtime and this screws up tup. See = https://github.com/gittup/tup/issues/198 Anyone know why FreeBSD's FUSE is doing this? Thanks, Lars --Apple-Mail=_CB347791-2515-49DA-B930-B709DD527588 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVO3PetZcnpRveo1xAQKA3gP/YkKnEICJuASEc/JHOvRE2Rzo6h1jr1Pf cdWBCeEQoKoFbSNyx0+09x88cnmoTX9/Tp8mNmcLSiVhF4qOdkusBxAlNsA5oBbl 7mK3k0xDBXTNjyp+129idNOiCOy/GZdj8FvyfDiuGZOr8ha9fJDWRUwizaDV5Qem Nd3rQCm19mk= =dqsV -----END PGP SIGNATURE----- --Apple-Mail=_CB347791-2515-49DA-B930-B709DD527588-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 15:00:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66EA394E; Wed, 25 Feb 2015 15:00:13 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28A8C231; Wed, 25 Feb 2015 15:00:13 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so5570957iec.1; Wed, 25 Feb 2015 07:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F/sSwcQtUIUg4Fh13WAbgJXyeZphU0papjjQhL2Hrbs=; b=sGRwFnE+NXEbjpg3LdyHMVBl57P0vYoJZzyVS9MVf3avF4ME0SosaBhEbrc20VGn3j RMU1tCDldvsmMsJUoRcRhlKHZL32YfwyPegbYKQd99PmznBihdg/NR7ry7uO6ZHL6e32 2qxgTM38EMV7zGqzf8KxYtj9/7qWczoH7d2mC6grzopb96bwG+pjvv7+m3nHTygiuGtE FkUY/QP7vAiDKKnsSmZ0dwKimtQw+l/YiejPdVYtpI4cc78QwEyc5J4KYCePNtzP6jrX 2wOQE/Z3vK4qWuF9iSCb6a7NF3Xon6Gkz8LP+9C61+B3fhEFFiZcfkEGxYk2VMk+UOiU udxA== X-Received: by 10.107.7.93 with SMTP id 90mr4957372ioh.69.1424876412598; Wed, 25 Feb 2015 07:00:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.107.138 with HTTP; Wed, 25 Feb 2015 06:59:52 -0800 (PST) In-Reply-To: <20150217193132.65fe16bb.ohartman@zedat.fu-berlin.de> References: <4E4BF84E-F6FD-4D25-8B2C-2B443894697B@gmail.com> <20150217193132.65fe16bb.ohartman@zedat.fu-berlin.de> From: Luca Pizzamiglio Date: Wed, 25 Feb 2015 15:59:52 +0100 Message-ID: Subject: Re: pcie Realtek 8168G issues (re driver) To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: Ben Perrault , freebsd-net@freebsd.org, FreeBSD Current , "freebsd-hardware@freebsd.org" , FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 15:00:13 -0000 Hi, thanks you all for the replies. Unfortunately, the network chip is still not working and I updated the PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the last tests. It seems that received packets are not transferred to mbuf or they are transferred, but later, after the mbuf is already freed; moreover, the ring entries are written without looping, overwriting and messing up the whole kernel memory. It looks like a DMA issues, but Apparently it seems a hardware error, but using a Linux distro, it works :( Has someone maybe any other ideas? In the meanwhile I'll get another board with the same chip :O Best regards, Luca On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann wrote: > Am Tue, 17 Feb 2015 18:32:22 +0100 > Luca Pizzamiglio schrieb: > >> Hi Ben, >> thanks for the tip! tso was already disabled. >> I tried anyway and unfortunately it crashes as before. >> >> I filled a bug report >> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ >> is giving me a big help on it. >> >> Best regards, >> Luca >> >> On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault wrote: >> > Luca, >> > >> > I've had the same issue with this interface on both PCIe boards and embedded in a >> > handful of Lenovo products. The one, fairly ugly workaround I've found that makes it >> > work well enough is disable tso ( i.e. ifconfig re0 down && ifconfig re0 -tso && >> > ifconfig re0 up ). This also seems to stop the panics under current. >> > >> > I'm not sure it will work for you - but it has on everyone of those interfaces I've >> > dealt with. >> > >> > Good luck, >> > -bp >> > >> >> On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio wrote: >> >> >> >> Hi, I'm Luca, >> >> >> >> I've some issues using a PCIe Realtek Ethernet board: >> >> re0@pci0:3:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 >> >> vendor = 'Realtek Semiconductor Co., Ltd.' >> >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >> >> class = network >> >> subclass = ethernet >> >> bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled >> >> bar [18] = type Memory, range 64, base 0x90500000, size 4096, enabled >> >> bar [20] = type Prefetchable Memory, range 64, base 0x90400000, >> >> size 16384, enabled >> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >> >> cap 05[50] = MSI supports 1 message, 64 bit >> >> cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) >> >> speed 2.5(2.5) ASPM disabled(L0s/L1) >> >> cap 11[b0] = MSI-X supports 4 messages >> >> Table in map 0x20[0x0], PBA in map 0x20[0x800] >> >> cap 03[d0] = VPD >> >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >> >> ecap 0002[140] = VC 1 max VC0 >> >> ecap 0003[160] = Serial 1 01000000684ce000 >> >> ecap 0018[170] = LTR 1 >> >> >> >> Rx and Tx don't work. After some minutes the interface is activated I >> >> get kernel panic. >> >> I've already tried to disable MSIx and MSI. >> >> It seems a DMA problem, rx fill the 256 descriptors and the nothing >> >> else until the panic. netstat -s shows now new packets. >> >> >> >> I filled a bug report with more infos: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 >> >> >> >> could someone kindly pointing some ideas? >> >> >> >> Best regards, >> >> Luca >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > In September 2014 I filed allready a bug acoording to strange behaviour with a Lenovo > ThinkPad E540 with a Realtek chip: > > > Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet > controller: doesn't work properly, problems getting UP automatically From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 15:33:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 864EB337 for ; Wed, 25 Feb 2015 15:33:06 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54F5689B for ; Wed, 25 Feb 2015 15:33:06 +0000 (UTC) Received: by pablj1 with SMTP id lj1so3621953pab.9 for ; Wed, 25 Feb 2015 07:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=7Uu489Y1cy5huxCxQxGCQx98+SFTyJ1d6hbOtOfDW70=; b=hqTP9gg6GYy9sN8sys7Fx8QRRq7RAJU+hw7Uc7hWTA6Hx8W9N8ycah/HVMsEo1PlIl kYKJ7p7vDRtl4pbIDZ9XvHyAdyqM5tNvkmF5fRD3MhxKxAyuaqlyDWIPI0TTeXDH9yJk q1VyZz2YyIqdpH8a0sl3TSk8r+JgEW54TLT11euC3RJEdnQmYqeIwnXfaPm2d7CFnSAH JvNzj2SnoR/ol+88jV7HaBve+p1TK2MtIonvi8Il8ZpztovizhyoZ4fIzSXK7nGKgEM3 XhAEX/etLYdfK6ncBBGMh9zgvDj9QA5QR/EVegWwUvZxdBehzldUrLebgv6SSFI+RdAS Ic8A== X-Received: by 10.68.172.193 with SMTP id be1mr6531859pbc.64.1424878385887; Wed, 25 Feb 2015 07:33:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.232.9 with HTTP; Wed, 25 Feb 2015 07:32:45 -0800 (PST) From: Arseny Nasokin Date: Wed, 25 Feb 2015 19:32:45 +0400 Message-ID: Subject: r279278 failed to build (yacc: maximum table size exceeded) To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 15:33:06 -0000 I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: ===> usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y > aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 15:43:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B551523; Wed, 25 Feb 2015 15:43:31 +0000 (UTC) Date: Wed, 25 Feb 2015 15:43:27 +0000 From: Glen Barber To: Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150225154327.GD1161@hub.FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rqzD5py0kzyFAOWN" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 15:43:31 -0000 --rqzD5py0kzyFAOWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: > I have clean svn tree with base/head branch. I try to build world, but I > have some mysterious bugs. The latest is yacc failed to make c file on > phase 4.3: >=20 > =3D=3D=3D> usr.sbin/acpi/iasl (depend) > m4 -P > -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/asl= parser.y > > aslcompiler.y > yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y > yacc: 89 shift/reduce conflicts. > yacc: f - maximum table size exceeded > *** Error code 2 >=20 > /etc/make.conf is /dev/null. > I've also tried empty /etc/src.conf with no luck. >=20 Out of curiosity, is your src tree mounted via NFS? Glen --rqzD5py0kzyFAOWN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU7e2aAAoJEAMUWKVHj+KT9lAQAJOFvR4jjcHbQd+OT0mC0z1E xwXlgTqjOQQKMeks3n+KnQBEQajJfbPOF7XpPM1VZcVwohdFuR5LXvRCdR9Vxmw+ ns4xvSyk1mUmvCqcbmhw0f2wDnX8/JnCmFGbyfMDOqc/JjFJ0zNcbYEaYNmY7ctd QF25Tly0mURcOGh0ZP6WWq/DS3Zl1fwlo0OWbcSpUyqXrZp/lrK+VJOUXQCn1HQZ jAQD391Tab4dJEMD5yWLLck33DuPB/ODs9mrrHA0nwPGMxmZPgoZ5aOFmLQx//ko 5ybPGcp6B1wmFLr6boY/iEqWCBoSexUCZJZehJAFtWYLViBXFXDqIKEMQVVOFqTr SzcW2ZXzBlFpmzJsVHAy6ssm0fjcvg0cpQIxvpyEQeciQM7oMXlstfidScwSJ/+L wqDKbtF6Uv4tNwkrxumFGfCeFsFIse4iqnfs7igYsOGUpL2UgvqlNK7XcL+M53kD Z3jHumOuseW57J1Hd9T4AShjuEeyYxE5m7C/sUodszylW2fTg+K8ueFAd1pIOkhQ yC37E3fq2ncV6KJimTmIyU0oimr4xRElv0iPGqEoWqnwlw34Q+cwQcRqaQp7Jvc6 uFrlefVpCL7V7GWHvonpXIR7w1yTcX1K5+b4tw3TTKeAjgLa62+99MZdLiBD8kog tp6ptFyPXFxKQbIZxNcE =FDuy -----END PGP SIGNATURE----- --rqzD5py0kzyFAOWN-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 16:39:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6D4DCFE; Wed, 25 Feb 2015 16:39:08 +0000 (UTC) Received: from frv25.fwdcdn.com (frv25.fwdcdn.com [212.42.77.25]) by mx1.freebsd.org (Postfix) with ESMTP id 63D73F15; Wed, 25 Feb 2015 16:39:08 +0000 (UTC) Received: from [10.10.14.27] (helo=frv27.fwdcdn.com) by frv25.fwdcdn.com QID:1YQeix-000AaU-3M/RC:2; Wed, 25 Feb 2015 18:22:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=ojP0N0z6YDBdxROlKEVHuVdHsZbMN+dQNfsN/0Ulbq8=; b=fQS4f8y6vYmWNrsky6yy3kXtm6gy5ikw2UPXihZhjRAExYHCYfgREqr0Otrl5kYEStixHkgb4qsQ3/1tIZ47jkvZzl4WF5Ny+7p4IXKrYVnJBJdOe3X0viW7jo5iLrrB+tSXDLObeqGv9mv4bieb5jgQK3gpadbhOtExQW85goU=; Received: from [5.248.241.121] (helo=nonamehost.local) by frv27.fwdcdn.com with esmtpsa ID 1YQeio-000GZa-DJ ; Wed, 25 Feb 2015 18:22:02 +0200 Date: Wed, 25 Feb 2015 18:22:01 +0200 From: Ivan Klymenko To: Glen Barber Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150225182201.216f6fee@nonamehost.local> In-Reply-To: <20150225154327.GD1161@hub.FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=5.248.241.121; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 Cc: Arseny Nasokin , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 16:39:08 -0000 =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: > > I have clean svn tree with base/head branch. I try to build world, > > but I have some mysterious bugs. The latest is yacc failed to make > > c file on phase 4.3: > >=20 > > =3D=3D=3D> usr.sbin/acpi/iasl (depend) > > m4 -P > > -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/a= slparser.y > > > aslcompiler.y > > yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y > > yacc: 89 shift/reduce conflicts. > > yacc: f - maximum table size exceeded > > *** Error code 2 > >=20 > > /etc/make.conf is /dev/null. > > I've also tried empty /etc/src.conf with no luck. > >=20 >=20 > Out of curiosity, is your src tree mounted via NFS? >=20 > Glen >=20 I have a similar problem on revision=20 /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 16:55:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC8E0CA8 for ; Wed, 25 Feb 2015 16:55:40 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 B866C30B for ; Wed, 25 Feb 2015 16:55:36 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PGuDeA027802 for ; Wed, 25 Feb 2015 08:56:14 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 08:56:14 -0800 Content-Type: multipart/mixed; boundary="--==8bc01cd88383431337ce92a572cfb537" MIME-Version: 1.0 Message-id: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 16:55:41 -0000 ----==8bc01cd88383431337ce92a572cfb537 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit I just wiped a system last night to perform a fresh install from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, and choosing the "reboot system", resulted in a LOR. I wasn't able to capture the output. But I'm still plagued with LOR's. They almost always follow the halt(8) command, and almost always occur during the final stages of the boot. But aren't always restricted to those events. The LOR's output seem indicative of fs related issues. This system has *always* worked w/o fail, and prior to this install, has never indicated hardware issues. Aside from the dmesg(8) attached, here are 2 of the examples. NOTE the numbers, and files are not always the same, from LOR to LOR; lock order reversal: 1st 0xfffff8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 2nd 0xfffff80004caf5f0 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame 0xfffffe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfffffe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120c277f0 ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfffffe0120c27860 softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfffffe0120c278d0 ffs_unmount() at ffs_unmount+0x81/frame 0xfffffe0120c27930 dounmount() at dounmount+0x42c/frame 0xfffffe0120c279b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfffffe0120c27ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c27bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c27bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = 0x7ffffff fe348, rbp = 0x7fffffffe460 --- lock order reversal: 1st 0xfffffe00f749ddc8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xfffff80004f28c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 85 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame 0xfffffe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0120c6d540 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe0120c6d580 ufs_direnter() at ufs_direnter+0x641/frame 0xfffffe0120c6d640 ufs_rename() at ufs_rename+0xffe/frame 0xfffffe0120c6d830 VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe0120c6d860 kern_renameat() at kern_renameat+0x4bc/frame 0xfffffe0120c6dae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c6dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c6dbf0 --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = 0x7ffffff fded8, rbp = 0x7fffffffdee0 --- and another lock order reversal: 1st 0xfffff800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 2nd 0xfffffe00f72442e0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xfffff80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame 0xfffffe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfffffe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfffffe0120aea030 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120aea060 _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120aea0d0 vget() at vget+0x67/frame 0xfffffe0120aea110 vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfffffe0120aea160 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0120aea1f0 softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfffffe0120aea2d0 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfffffe0120aea350 ffs_truncate() at ffs_truncate+0x671/frame 0xfffffe0120aea530 ufs_direnter() at ufs_direnter+0x7d1/frame 0xfffffe0120aea5f0 ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfffffe0120aea7b0 ufs_create() at ufs_create+0x2d/frame 0xfffffe0120aea7d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe0120aea800 vn_open_cred() at vn_open_cred+0x2c6/frame 0xfffffe0120aea960 kern_openat() at kern_openat+0x257/frame 0xfffffe0120aeaae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120aeabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120aeabf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp = 0x7ffffff fd598, rbp = 0x7fffffffd670 --- I *really* need to build/install world/kernel on this box. But am fairly confident that there will be issues as I LOR's to occur during the process. Any insight || help with this, greatly appreciated. Thanks! --Chris -- ----==8bc01cd88383431337ce92a572cfb537 Content-Type: text/plain; name="dmesg.boot" Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: base64 CWRvbWFpbj0wLCBidXM9MSwgc2xvdD0xMCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDIwMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03CgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweGJjMDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjE6IGFsbG9jYXRl ZCBJL08gcG9ydCByYW5nZSAoMHhiYzAwLTB4YmMxZikgZm9yIHJpZCAxMCBvZiBwY2kwOjE6MTA6 MApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4xMC5JTlRBIChzcmMgXDEzNF9TQl8uUENJMC5B UEMzOjApCnBjaV9saW5rMjE6IFBpY2tlZCBJUlEgMTggd2l0aCB3ZWlnaHQgMApwY2liMTogc2xv dCAxMCBJTlRBIHJvdXRlZCB0byBpcnEgMTggdmlhIFwxMzRfU0JfLlBDSTAuQVBDMwpwY2kxOiA8 bmV0d29yaywgZXRoZXJuZXQ+IGF0IGRldmljZSAxMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmhk YWMwOiA8TlZJRElBIE1DUDYxIEhEQSBDb250cm9sbGVyPiBtZW0gMHhmZTAyNDAwMC0weGZlMDI3 ZmZmIGlycSAyMyBhdCBkZXZpY2UgNS4wIG9uIHBjaTAKaGRhYzA6IFBDSSBjYXJkIHZlbmRvcjog MHgxMDNjLCBkZXZpY2U6IDB4MmE3MgpoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAxMjAx MjZfMDAwMgpoZGFjMDogQ29uZmlnIG9wdGlvbnM6IG9uPTB4MDAwMDAwMDAgb2ZmPTB4MDAwMDAw MDAKaGRhYzA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVjdG9ycyAoMSBzdXBwb3J0 ZWQpCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDUzCmhk YWMwOiB1c2luZyBJUlEgMjU2IGZvciBNU0kKaGRhYzA6IENhcHM6IE9TUyA0LCBJU1MgNCwgQlNT IDAsIE5TRE8gMSwgNjRiaXQsIENPUkIgMjU2LCBSSVJCIDI1NgpuZmUwOiA8TlZJRElBIG5Gb3Jj ZSBNQ1A2MSBOZXR3b3JraW5nIEFkYXB0ZXI+IHBvcnQgMHhmMDAwLTB4ZjAwNyBtZW0gMHhmZTAy ZDAwMC0weGZlMDJkZmZmIGlycSAyMiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKbmZlMDogYXR0ZW1w dGluZyB0byBhbGxvY2F0ZSA4IE1TSSB2ZWN0b3JzICg4IHN1cHBvcnRlZCkKbXNpOiByb3V0aW5n IE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTYKbXNpOiByb3V0aW5nIE1TSSBJ UlEgMjU4IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTcKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjU5 IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTgKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYwIHRvIGxv Y2FsIEFQSUMgMCB2ZWN0b3IgNTkKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYxIHRvIGxvY2FsIEFQ SUMgMCB2ZWN0b3IgNjAKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYyIHRvIGxvY2FsIEFQSUMgMCB2 ZWN0b3IgNjEKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYzIHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3Ig NjIKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjY0IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNjMKbmZl MDogdXNpbmcgSVJRcyAyNTctMjY0IGZvciBNU0kKbmZlMDogVXNpbmcgOCBNU0kgbWVzc2FnZXMK bWlpYnVzMDogPE1JSSBidXM+IG9uIG5mZTAKcmdlcGh5MDogPFJUTDgxNjlTLzgxMTBTLzgyMTEg MTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKcmdlcGh5MDogT1VJ IDB4MDBlMDRjLCBtb2RlbCAweDAwMTEsIHJldi4gMgpyZ2VwaHkwOiAgbm9uZSwgMTBiYXNlVCwg MTBiYXNlVC1GRFgsIDEwYmFzZVQtRkRYLWZsb3csIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwg MTAwYmFzZVRYLUZEWC1mbG93LCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNl VC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLWZsb3csIDEwMDBiYXNl VC1GRFgtZmxvdy1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpuZmUwOiBicGYgYXR0YWNoZWQKbmZl MDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjQ6ODE6Y2U6YmE6ODcKYXRhcGNpMDogPG5WaWRpYSBu Rm9yY2UgTUNQNjEgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4OWYwLTB4OWY3LDB4YmYwLTB4 YmYzLDB4OTcwLTB4OTc3LDB4YjcwLTB4YjczLDB4ZGMwMC0weGRjMGYgbWVtIDB4ZmUwMmMwMDAt MHhmZTAyY2ZmZiBpcnEgMjAgYXQgZGV2aWNlIDguMCBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDIwIChQQ0kgSVJRIDIwKSB0byBsYXBpYyAwIHZlY3RvciA1NAphdGEyOiA8QVRBIGNo YW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwCmF0YTM6IDxBVEEgY2hhbm5lbD4gYXQgY2hh bm5lbCAxIG9uIGF0YXBjaTAKYXRhcGNpMTogPG5WaWRpYSBuRm9yY2UgTUNQNjEgU0FUQTMwMCBj b250cm9sbGVyPiBwb3J0IDB4OWUwLTB4OWU3LDB4YmUwLTB4YmUzLDB4OTYwLTB4OTY3LDB4YjYw LTB4YjYzLDB4YzgwMC0weGM4MGYgbWVtIDB4ZmUwMmIwMDAtMHhmZTAyYmZmZiBpcnEgMjEgYXQg ZGV2aWNlIDguMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIx KSB0byBsYXBpYyAwIHZlY3RvciA1NQphdGE0OiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBv biBhdGFwY2kxCmF0YTU6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTEKcGNp YjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOS4wIG9uIHBjaTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDQgKDB4YTAwMC0weGFmZmYpIGZvciByaWQgMWMgb2YgcGNpYjIKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmEwMDAwMDAtMHhmY2ZmZmZmZikgZm9yIHJpZCAyMCBvZiBw Y2liMgpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMDAwMDAwMC0weGVmZmZmZmZmKSBmb3Ig cmlkIDI0IG9mIHBjaWIyCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAgc2Vj b25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4YTAwMC0weGFmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAg MHhmYTAwMDAwMC0weGZjZmZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZTAwMDAw MDAtMHhlZmZmZmZmZgpwY2liMjogICBzcGVjaWFsIGRlY29kZSAgICBWR0EKcGNpYjI6IGNvdWxk IG5vdCBnZXQgUENJIGludGVycnVwdCByb3V0aW5nIHRhYmxlIGZvciBcMTM0X1NCXy5QQ0kwLlhW UjAgLSBBRV9OT1RfRk9VTkQKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjI6IGFs bG9jYXRlZCBidXMgcmFuZ2UgKDItMikgZm9yIHJpZCAwIG9mIHBjaTIKcGNpMjogZG9tYWluPTAs IHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDFkMywgcmV2aWQ9 MHhhMQoJZG9tYWluPTAsIGJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0Cglt YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYTAwMDAwMCwgc2l6ZSAyNCwg ZW5hYmxlZApwY2liMjogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmYTAwMDAwMC0weGZhZmZm ZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MjowOjAKCW1hcFsxNF06IHR5cGUgUHJlZmV0Y2hhYmxl IE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhlMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApwY2li MjogYWxsb2NhdGVkIHByZWZldGNoIHJhbmdlICgweGUwMDAwMDAwLTB4ZWZmZmZmZmYpIGZvciBy aWQgMTQgb2YgcGNpMDoyOjA6MAoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNl IDB4ZmIwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjI6IGFsbG9jYXRlZCBtZW1vcnkgcmFu Z2UgKDB4ZmIwMDAwMDAtMHhmYmZmZmZmZikgZm9yIHJpZCAxYyBvZiBwY2kwOjI6MDowCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjkuSU5UQSAoc3JjIFwxMzRfU0JfLlBDSTAuQVBDODowKQpw Y2lfbGluazI2OiBQaWNrZWQgSVJRIDE2IHdpdGggd2VpZ2h0IDAKcGNpYjA6IHNsb3QgOSBJTlRB IHJvdXRlZCB0byBpcnEgMTYgdmlhIFwxMzRfU0JfLlBDSTAuQVBDOApwY2liMjogc2xvdCAwIElO VEEgaXMgcm91dGVkIHRvIGlycSAxNgp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4g bWVtIDB4ZmEwMDAwMDAtMHhmYWZmZmZmZiwweGUwMDAwMDAwLTB4ZWZmZmZmZmYsMHhmYjAwMDAw MC0weGZiZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKdmdhcGNpMDogQm9vdCB2 aWRlbyBkZXZpY2UKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBv biBwY2kwCnBjaWIzOiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHg5MDAwLTB4OTBmZgpwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHg5MDAwLTB4OTBmZikgZm9yIHJpZCAxYyBvZiBwY2liMwpw Y2liMzogYWxsb2NhdGluZyBub24tSVNBIHJhbmdlIDB4OTQwMC0weDk0ZmYKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDQgKDB4OTQwMC0weDk0ZmYpIGZvciByaWQgMWMgb2YgcGNpYjMKcGNpYjM6IGFs bG9jYXRpbmcgbm9uLUlTQSByYW5nZSAweDk4MDAtMHg5OGZmCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSA0ICgweDk4MDAtMHg5OGZmKSBmb3IgcmlkIDFjIG9mIHBjaWIzCnBjaWIzOiBhbGxvY2F0aW5n IG5vbi1JU0EgcmFuZ2UgMHg5YzAwLTB4OWNmZgpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg5 YzAwLTB4OWNmZikgZm9yIHJpZCAxYyBvZiBwY2liMwpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhmZGMwMDAwMC0weGZkY2ZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWIzCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGZkYjAwMDAwLTB4ZmRiZmZmZmYpIGZvciByaWQgMjQgb2YgcGNpYjMKcGNp YjM6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMzogICBzZWNvbmRhcnkgYnVzICAgICAzCnBj aWIzOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDMKcGNpYjM6ICAgSS9PIGRlY29kZSAgICAgICAgMHg5 MDAwLTB4OWZmZgpwY2liMzogICBtZW1vcnkgZGVjb2RlICAgICAweGZkYzAwMDAwLTB4ZmRjZmZm ZmYKcGNpYjM6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZGIwMDAwMC0weGZkYmZmZmZmCnBjaWIz OiAgIHNwZWNpYWwgZGVjb2RlICAgIElTQQpwY2liMzogY291bGQgbm90IGdldCBQQ0kgaW50ZXJy dXB0IHJvdXRpbmcgdGFibGUgZm9yIFwxMzRfU0JfLlBDSTAuWFZSMSAtIEFFX05PVF9GT1VORApw Y2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liMzogYWxsb2NhdGVkIGJ1cyByYW5nZSAo My0zKSBmb3IgcmlkIDAgb2YgcGNpMwpwY2kzOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTMKcGNp YjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIuMCBvbiBwY2kwCnBjaWI0OiBh bGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHg4MDAwLTB4ODBmZgpwY2liMDogYWxsb2NhdGVkIHR5 cGUgNCAoMHg4MDAwLTB4ODBmZikgZm9yIHJpZCAxYyBvZiBwY2liNApwY2liNDogYWxsb2NhdGlu ZyBub24tSVNBIHJhbmdlIDB4ODQwMC0weDg0ZmYKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4 ODQwMC0weDg0ZmYpIGZvciByaWQgMWMgb2YgcGNpYjQKcGNpYjQ6IGFsbG9jYXRpbmcgbm9uLUlT QSByYW5nZSAweDg4MDAtMHg4OGZmCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDg4MDAtMHg4 OGZmKSBmb3IgcmlkIDFjIG9mIHBjaWI0CnBjaWI0OiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2Ug MHg4YzAwLTB4OGNmZgpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg4YzAwLTB4OGNmZikgZm9y IHJpZCAxYyBvZiBwY2liNApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhmZGEwMDAwMC0weGZk YWZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWI0CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZk OTAwMDAwLTB4ZmQ5ZmZmZmYpIGZvciByaWQgMjQgb2YgcGNpYjQKcGNpYjQ6ICAgZG9tYWluICAg ICAgICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHg4MDAwLTB4OGZmZgpwY2li NDogICBtZW1vcnkgZGVjb2RlICAgICAweGZkYTAwMDAwLTB4ZmRhZmZmZmYKcGNpYjQ6ICAgcHJl ZmV0Y2hlZCBkZWNvZGUgMHhmZDkwMDAwMC0weGZkOWZmZmZmCnBjaWI0OiAgIHNwZWNpYWwgZGVj b2RlICAgIElTQQpwY2liNDogY291bGQgbm90IGdldCBQQ0kgaW50ZXJydXB0IHJvdXRpbmcgdGFi bGUgZm9yIFwxMzRfU0JfLlBDSTAuWFZSMiAtIEFFX05PVF9GT1VORApwY2k0OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNApwY2liNDogYWxsb2NhdGVkIGJ1cyByYW5nZSAoNC00KSBmb3IgcmlkIDAg b2YgcGNpNApwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTQKYWNwaV90ejA6IDxUaGVybWFs IFpvbmU+IG9uIGFjcGkwCnBzbWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNw aTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRr YmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDQ3CmF0a2JkOiBr ZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQgMTAx LzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50 cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNjQKYXRrYmQwOiBbR0lBTlQtTE9D S0VEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ3CnBzbTA6IDxQUy8yIE1vdXNlPiBp cnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikg dG8gbGFwaWMgMCB2ZWN0b3IgNjUKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwgSW50 ZWxsaU1vdXNlIEV4cGxvcmVyLCBkZXZpY2UgSUQgNC0wMCwgNSBidXR0b25zCnBzbTA6IGNvbmZp ZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjQKcHNtMDogc3luY21hc2s6 MDgsIHN5bmNiaXRzOjAwCmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGZmZmZmZTAwMDAyMWQwMDAg cGEgMHg5MDAwMAphaGNfaXNhX2lkZW50aWZ5IDA6IGlvcG9ydCAweGMwMCBhbGxvYyBmYWlsZWQK YWhjX2lzYV9pZGVudGlmeSAxOiBpb3BvcnQgMHgxYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lk ZW50aWZ5IDI6IGlvcG9ydCAweDJjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgMzog aW9wb3J0IDB4M2MwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSA0OiBpb3BvcnQgMHg0 YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDU6IGlvcG9ydCAweDVjMDAgYWxsb2Mg ZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgNjogaW9wb3J0IDB4NmMwMCBhbGxvYyBmYWlsZWQKYWhj X2lzYV9pZGVudGlmeSA3OiBpb3BvcnQgMHg3YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50 aWZ5IDg6IGlvcG9ydCAweDhjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgOTogaW9w b3J0IDB4OWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMDogaW9wb3J0IDB4YWMw MCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMTogaW9wb3J0IDB4YmMwMCBhbGxvYyBm YWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMjogaW9wb3J0IDB4Y2MwMCBhbGxvYyBmYWlsZWQKYWhj X2lzYV9pZGVudGlmeSAxMzogaW9wb3J0IDB4ZGMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVu dGlmeSAxNDogaW9wb3J0IDB4ZWMwMCBhbGxvYyBmYWlsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YTAwMDAtMHhhMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YTA4MDAtMHhhMGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YTEwMDAtMHhhMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YTE4MDAtMHhhMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YTIwMDAtMHhhMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTI4MDAtMHhhMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTMwMDAtMHhhMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTM4MDAtMHhhM2ZmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQwMDAtMHhhNDdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQ4MDAtMHhhNGZmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTUwMDAtMHhhNTdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTU4MDAtMHhhNWZmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTYwMDAtMHhhNjdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTY4MDAtMHhhNmZm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTcwMDAtMHhh NzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTc4MDAt MHhhN2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTgw MDAtMHhhODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YTg4MDAtMHhhOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YTkwMDAtMHhhOTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YTk4MDAtMHhhOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YWEwMDAtMHhhYTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YWE4MDAtMHhhYWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YWIwMDAtMHhhYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YWI4MDAtMHhhYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWMwMDAtMHhhYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWM4MDAtMHhhY2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQwMDAtMHhhZDdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQ4MDAtMHhhZGZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWUwMDAtMHhhZTdmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWU4MDAtMHhhZWZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWYwMDAtMHhhZjdmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWY4MDAtMHhhZmZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjAwMDAtMHhiMDdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjA4MDAtMHhi MGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjEwMDAt MHhiMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjE4 MDAtMHhiMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YjIwMDAtMHhiMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YjI4MDAtMHhiMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YjMwMDAtMHhiMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YjM4MDAtMHhiM2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YjQwMDAtMHhiNDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YjQ4MDAtMHhiNGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YjUwMDAtMHhiNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjU4MDAtMHhiNWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjYwMDAtMHhiNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjY4MDAtMHhiNmZmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjcwMDAtMHhiNzdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjc4MDAtMHhiN2ZmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjgwMDAtMHhiODdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjg4MDAtMHhiOGZmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjkwMDAtMHhiOTdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjk4MDAtMHhiOWZm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmEwMDAtMHhi YTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmE4MDAt MHhiYWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmIw MDAtMHhiYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YmI4MDAtMHhiYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YmMwMDAtMHhiYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YmM4MDAtMHhiY2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YmQwMDAtMHhiZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YmQ4MDAtMHhiZGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YmUwMDAtMHhiZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YmU4MDAtMHhiZWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmYwMDAtMHhiZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmY4MDAtMHhiZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzAwMDAtMHhjMDdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzA4MDAtMHhjMGZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzEwMDAtMHhjMTdmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzE4MDAtMHhjMWZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzIwMDAtMHhjMjdmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzI4MDAtMHhjMmZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzMwMDAtMHhjMzdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzM4MDAtMHhj M2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzQwMDAt MHhjNDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzQ4 MDAtMHhjNGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YzUwMDAtMHhjNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YzU4MDAtMHhjNWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YzYwMDAtMHhjNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YzY4MDAtMHhjNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YzcwMDAtMHhjNzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4Yzc4MDAtMHhjN2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YzgwMDAtMHhjODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzg4MDAtMHhjOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzkwMDAtMHhjOTdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzk4MDAtMHhjOWZmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2EwMDAtMHhjYTdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2E4MDAtMHhjYWZmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2IwMDAtMHhjYjdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2I4MDAtMHhjYmZmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2MwMDAtMHhjYzdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2M4MDAtMHhjY2Zm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2QwMDAtMHhj ZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2Q4MDAt MHhjZGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2Uw MDAtMHhjZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 Y2U4MDAtMHhjZWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4Y2YwMDAtMHhjZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4Y2Y4MDAtMHhjZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZDAwMDAtMHhkMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4ZDAwMDAtMHhkMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZDE4MDAtMHhkMWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4ZDIwMDAtMHhkMjdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDI4MDAtMHhkMmZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDMwMDAtMHhkMzdmZikgZm9yIHJpZCAxIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDM4MDAtMHhkM2ZmZikgZm9yIHJpZCAxIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQwMDAtMHhkNDdmZikgZm9yIHJpZCAxIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQ4MDAtMHhkNGZmZikgZm9yIHJpZCAx IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDUwMDAtMHhkNTdmZikgZm9yIHJp ZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDU4MDAtMHhkNWZmZikgZm9y IHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDYwMDAtMHhkNjdmZikg Zm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDY4MDAtMHhkNmZm ZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDcwMDAtMHhk NzdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDc4MDAt MHhkN2ZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDgw MDAtMHhkODdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 ZDg4MDAtMHhkOGZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDkwMDAtMHhkOTdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4ZDk4MDAtMHhkOWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZGEwMDAtMHhkYTdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4ZGE4MDAtMHhkYWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZGIwMDAtMHhkYjdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4ZGI4MDAtMHhkYmZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGMwMDAtMHhkYzdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGM4MDAtMHhkY2ZmZikgZm9yIHJpZCAxIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGQwMDAtMHhkZDdmZikgZm9yIHJpZCAxIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGQ4MDAtMHhkZGZmZikgZm9yIHJpZCAxIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGUwMDAtMHhkZTdmZikgZm9yIHJpZCAx IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGU4MDAtMHhkZWZmZikgZm9yIHJp ZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGYwMDAtMHhkZjdmZikgZm9y IHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGY4MDAtMHhkZmZmZikg Zm9yIHJpZCAxIG9mIG9ybTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmlj ZXMKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHJ0YzogYXRy dGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK aXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9w dGlvbiBST00+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkMTdmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBj b25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNv bGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzY3Rl a2VuICh0ZWtlbiB0ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNj MC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgNCAoMHgzYzAtMHgzZGYpIGZvciByaWQgMCBvZiB2Z2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGEwMDAwLTB4YmZmZmYpIGZvciByaWQgMCBvZiB2Z2EwCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSA0ICgweDNmMC0weDNmNSkgZm9yIHJpZCAwIG9mIGZkYzAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDQgKDB4M2Y3LTB4M2Y3KSBmb3IgcmlkIDEgb2YgZmRjMApmZGMwIGZhaWxlZCB0byBwcm9i ZSBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKcHBjMDogY2Fu bm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKcHBjMCBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcg b24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjgtMHgzZmYpIGZvciByaWQgMCBv ZiB1YXJ0MAp1YXJ0MCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBv biBpc2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDJmOC0weDJmZikgZm9yIHJpZCAwIG9m IHVhcnQxCnVhcnQxIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9u IGlzYTAKd2J3ZDAgZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBw cm9iaW5nIFBuUCBkZXZpY2VzCnBvd2Vybm93MDogPFBvd2VyTm93ISBLOD4gb24gY3B1MApwb3dl cm5vdzE6IDxQb3dlck5vdyEgSzg+IG9uIGNwdTEKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNo ZWQuCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDA0NTcw MjMgSHoKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2bGFuOiBpbml0aWFsaXpl ZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwp0Y3BfaW5pdDogbmV0LmluZXQudGNw LnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMzI3NjgKbG8wOiBicGYgYXR0YWNoZWQKaHB0bnI6 IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdDI3eHg6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQu CmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpoZGFjYzA6IDxSZWFsdGVrIEFMQzEyMDAg SERBIENPREVDPiBhdCBjYWQgMCBvbiBoZGFjMApoZGFhMDogPFJlYWx0ZWsgQUxDMTIwMCBBdWRp byBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MwCmhkYWEwOiBTdWJzeXN0ZW0gSUQ6 IDB4MTAzYzJhNzIKaGRhYTA6IE51bUdQSU89MiBOdW1HUE89MCBOdW1HUEk9MCBHUElXYWtlPTAg R1BJVW5zb2w9MQpoZGFhMDogIEdQSU8wOiBkaXNhYmxlZApoZGFhMDogIEdQSU8xOiBkaXNhYmxl ZApoZGFhMDogT3JpZ2luYWwgcGlucyBjb25maWd1cmF0aW9uOgpoZGFhMDogbmlkICAgMHggICAg YXMgc2VxIGRldmljZSAgICAgICBjb25uICBqYWNrICAgIGxvYyAgICAgICAgY29sb3IgICBtaXNj CmhkYWEwOiAxNyA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVh ciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDIwIDAxMDE0MDEwIDEgIDAgIExpbmUtb3V0ICAgICAg SmFjayAgMS84ICAgICBSZWFyICAgICAgIEdyZWVuICAgMApoZGFhMDogMjEgOTkxMzAxMjAgMiAg MCAgU3BlYWtlciAgICAgICBGaXhlZCBBVEFQSSAgIE9uYm9hcmQgICAgVW5rbm93biAxCmhkYWEw OiAyMiAwMTgxMzA0ZiA0ICAxNSBMaW5lLWluICAgICAgIEphY2sgIDEvOCAgICAgUmVhciAgICAg ICBCbHVlICAgIDAKaGRhYTA6IDIzIDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAg MS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMjQgMDFhMTk4NDAgNCAgMCAgTWlj ICAgICAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgUGluayAgICA4CmhkYWEwOiAyNSAw MmExOTg0MiA0ICAyICBNaWMgICAgICAgICAgIEphY2sgIDEvOCAgICAgRnJvbnQgICAgICBQaW5r ICAgIDgKaGRhYTA6IDI2IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAg ICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMjcgMDIyMTQwMWYgMSAgMTUgSGVhZHBob25l cyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgR3JlZW4gICAwCmhkYWEwOiAyOCA0MTExMTFm MCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEK aGRhYTA6IDI5IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFy ICAgICAgIEJsYWNrICAgMQpoZGFhMDogMzAgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBO b25lICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxCmhkYWEwOiAzMSA0MTExMTFmMCAxNSAw ICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6 IFBhdGNoaW5nIHdpZGdldCBjYXBzIG5pZD0yOSAweDAwNDAwMDAwIC0+IDB4MDA3MDAwMDAKaGRh YTA6IFBhdGNoZWQgcGlucyBjb25maWd1cmF0aW9uOgpoZGFhMDogbmlkICAgMHggICAgYXMgc2Vx IGRldmljZSAgICAgICBjb25uICBqYWNrICAgIGxvYyAgICAgICAgY29sb3IgICBtaXNjCmhkYWEw OiAxNyA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAg ICBCbGFjayAgIDEgRElTQQpoZGFhMDogMjAgMDEwMTQwMTAgMSAgMCAgTGluZS1vdXQgICAgICBK YWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAwCmhkYWEwOiAyMSA5OTEzMDEyMCAyICAw ICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2FyZCAgICBVbmtub3duIDEKaGRhYTA6 IDIyIDAxODEzMDRmIDQgIDE1IExpbmUtaW4gICAgICAgSmFjayAgMS84ICAgICBSZWFyICAgICAg IEJsdWUgICAgMApoZGFhMDogMjMgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAx LzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxIERJU0EKaGRhYTA6IDI0IDAxYTE5ODQwIDQgIDAg IE1pYyAgICAgICAgICAgSmFjayAgMS84ICAgICBSZWFyICAgICAgIFBpbmsgICAgOApoZGFhMDog MjUgMDJhMTk4NDIgNCAgMiAgTWljICAgICAgICAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAg UGluayAgICA4CmhkYWEwOiAyNiA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEv OCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMjcgMDIyMTQwMWYgMSAgMTUg SGVhZHBob25lcyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgR3JlZW4gICAwCmhkYWEwOiAy OCA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBC bGFjayAgIDEgRElTQQpoZGFhMDogMzAgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25l ICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxIERJU0EKaGRhYTA6IDMxIDQxMTExMWYwIDE1 IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNB CmhkYWEwOiAzIGFzc29jaWF0aW9ucyBmb3VuZDoKaGRhYTA6IEFzc29jaWF0aW9uIDAgKDEpIG91 dDoKaGRhYTA6ICBQaW4gbmlkPTIwIHNlcT0wCmhkYWEwOiAgUGluIG5pZD0yNyBzZXE9MTUKaGRh YTA6IEFzc29jaWF0aW9uIDEgKDIpIG91dDoKaGRhYTA6ICBQaW4gbmlkPTIxIHNlcT0wCmhkYWEw OiBBc3NvY2lhdGlvbiAyICg0KSBpbjoKaGRhYTA6ICBQaW4gbmlkPTI0IHNlcT0wCmhkYWEwOiAg UGluIG5pZD0yNSBzZXE9MgpoZGFhMDogIFBpbiBuaWQ9MjIgc2VxPTE1CmhkYWEwOiBUcmFjaW5n IGFzc29jaWF0aW9uIDAgKDEpCmhkYWEwOiAgUGluIDIwIHRyYWNlZCB0byBEQUMgMgpoZGFhMDog IFBpbiAyNyB0cmFjZWQgdG8gREFDIDIgYW5kIGhwcmVkaXIgMApoZGFhMDogQXNzb2NpYXRpb24g MCAoMSkgdHJhY2Ugc3VjY2VlZGVkCmhkYWEwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDEgKDIpCmhk YWEwOiAgUGluIDIxIHRyYWNlZCB0byBEQUMgMwpoZGFhMDogQXNzb2NpYXRpb24gMSAoMikgdHJh Y2Ugc3VjY2VlZGVkCmhkYWEwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDIgKDQpCmhkYWEwOiAgUGlu IDI0IHRyYWNlZCB0byBBREMgOApoZGFhMDogIFBpbiAyNSB0cmFjZWQgdG8gQURDIDgKaGRhYTA6 ICBQaW4gMjIgdHJhY2VkIHRvIEFEQyA4CmhkYWEwOiBBc3NvY2lhdGlvbiAyICg0KSB0cmFjZSBz dWNjZWVkZWQKaGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgREFDIGZvciBhc3NvY2lhdGlv biAwICgxKQpoZGFhMDogTG9va2luZyBmb3IgYWRkaXRpb25hbCBEQUMgZm9yIGFzc29jaWF0aW9u IDEgKDIpCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIEFEQyBmb3IgYXNzb2NpYXRpb24g MiAoNCkKaGRhYTA6ICBBREMgOSBjb25zaWRlcmVkIGVxdWFsIHRvIEFEQyA4CmhkYWEwOiBUcmFj aW5nIGlucHV0IG1vbml0b3IKaGRhYTA6ICBUcmFjaW5nIG5pZCAxMSB0byBvdXQKaGRhYTA6ICBu aWQgMTEgaXMgaW5wdXQgbW9uaXRvcgpoZGFhMDogIFRyYWNpbmcgbmlkIDM0IHRvIG91dApoZGFh MDogIFRyYWNpbmcgbmlkIDM1IHRvIG91dApoZGFhMDogVHJhY2luZyBvdGhlciBpbnB1dCBtb25p dG9ycwpoZGFhMDogIFRyYWNpbmcgbmlkIDIyIHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDI0 IHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDI1IHRvIG91dApoZGFhMDogVHJhY2luZyBiZWVw ZXIKaGRhYTA6IEhlYWRwaG9uZXMgcmVkaXJlY3Rpb24gZm9yIGFzc29jaWF0aW9uIDAgbmlkPTI3 IHVzaW5nIHVuc29saWNpdGVkIHJlc3BvbnNlcy4KaGRhYTA6IFJlZGlyZWN0IG91dHB1dCB0bzog bWFpbgpoZGFhMDogRkcgY29uZmlnL3F1aXJrczogZm9yY2VzdGVyZW8gaXZyZWY1MCBpdnJlZjgw IGl2cmVmMTAwIGl2cmVmCnBjbTA6IDxSZWFsdGVrIEFMQzEyMDAgKEFuYWxvZyAyLjArSFAvMi4w KT4gYXQgbmlkIDIwLDI3IGFuZCAyNCwyNSwyMiBvbiBoZGFhMApwY20wOiBQbGF5YmFjazoKcGNt MDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20wOiAgICAgICAgIFBDTSBjYXA6 IDB4MDAwZTA1NjAgMTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpwY20wOiAgICAgICAg ICAgICBEQUM6IDIKcGNtMDogCnBjbTA6ICAgICBuaWQ9MjAgW3BpbjogTGluZS1vdXQgKEdyZWVu IEphY2spXQpwY20wOiAgICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwg bWl4XQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XSBbc3JjOiBw Y21dCnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdIFtzcmM6IG1p eF0KcGNtMDogCnBjbTA6ICAgICBuaWQ9MjcgW3BpbjogSGVhZHBob25lcyAoR3JlZW4gSmFjayld CnBjbTA6ICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBj bTA6ICAgICAgICAgICAgICArIDwtIG5pZD0yIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNt MDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20w OiAKcGNtMDogUmVjb3JkOgpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEgUENNCnBj bTA6ICAgICAgICAgUENNIGNhcDogMHgwMDA2MDE2MCAxNiAyMCBiaXRzLCA0NCA0OCA5NiBLSHoK cGNtMDogICAgICAgICAgICAgQURDOiA4CnBjbTA6ICAgICAgICAgICAgIEFEQzogOQpwY20wOiAK cGNtMDogICAgIG5pZD04IFthdWRpbyBpbnB1dF0KcGNtMDogICAgICAgKyA8LSBuaWQ9MzUgW2F1 ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBtaWMsIG1peCwgbW9uaXRvcl0KcGNtMDog ICAgICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWlj XQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWljIChQaW5rIEphY2spXSBb c3JjOiBtb25pdG9yXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0 XSBbc3JjOiBzcGVha2VyXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGlu ZS1pbiAoQmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlk PTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5pZD05IFthdWRp byBpbnB1dF0KcGNtMDogICAgICAgKyA8LSBuaWQ9MzQgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVh a2VyLCBsaW5lLCBtaWMsIG1peCwgbW9uaXRvcl0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlk PTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWljXQpwY20wOiAgICAgICAgICAgICAg KyA8LSBuaWQ9MjUgW3BpbjogTWljIChQaW5rIEphY2spXSBbc3JjOiBtb25pdG9yXQpwY20wOiAg ICAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0XSBbc3JjOiBzcGVha2VyXQpwY20w OiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0gW3Ny YzogbGluZV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3Ny YzogbWl4XQpwY20wOiAKcGNtMDogSW5wdXQgTWl4OgpwY20wOiAKcGNtMDogICAgIG5pZD0xMSBb YXVkaW8gbWl4ZXJdCnBjbTA6ICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNr KV0gW3NyYzogbWljXQpwY20wOiAgICAgICArIDwtIG5pZD0yNSBbcGluOiBNaWMgKFBpbmsgSmFj ayldIFtzcmM6IG1vbml0b3JdCnBjbTA6ICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0g W3NyYzogc3BlYWtlcl0KcGNtMDogICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGluZS1pbiAoQmx1 ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogCnBjbTA6IE1hc3RlciBWb2x1bWUgKE9TUzogdm9s KTogLTQ2LzBkQgpwY20wOiAgICArLSBjdGwgMTMgKG5pZCAgMTIgb3V0KTogICAgLTQ2LzBkQiAo MzIgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAxNCAobmlkICAxMiBpbiAgIDApOiBtdXRlCnBjbTA6 ICAgICstIGN0bCAxNSAobmlkICAxMiBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyNSAo bmlkICAyMCBpbiApOiAgICBtdXRlCnBjbTA6ICAgICstIGN0bCAzOSAobmlkICAyNyBpbiApOiAg ICBtdXRlCnBjbTA6IApwY20wOiBQQ00gVm9sdW1lIChPU1M6IHBjbSk6IDAvMGRCCnBjbTA6ICAg ICstIGN0bCAxNCAobmlkICAxMiBpbiAgIDApOiBtdXRlCnBjbTA6IApwY20wOiBNaWNyb3Bob25l IFZvbHVtZSAoT1NTOiBtaWMpOiAwLzMwZEIKcGNtMDogICAgKy0gY3RsICAzIChuaWQgIDExIGlu ICAgMCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAzNCAobmlk ICAyNCBvdXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTA6ICAgICstIGN0bCA0MSAobmlkICAz NCBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MiAobmlkICAzNSBpbiAgIDApOiBtdXRl CnBjbTA6IApwY20wOiBNaWNyb3Bob25lMiBWb2x1bWUgKE9TUzogbW9uaXRvcik6IDAvMzBkQgpw Y20wOiAgICArLSBjdGwgIDQgKG5pZCAgMTEgaW4gICAxKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSAr IG11dGUKcGNtMDogICAgKy0gY3RsIDM2IChuaWQgIDI1IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVw cykKcGNtMDogICAgKy0gY3RsIDQyIChuaWQgIDM0IGluICAgMSk6IG11dGUKcGNtMDogICAgKy0g Y3RsIDUzIChuaWQgIDM1IGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6IExpbmUtaW4gVm9sdW1l IChPU1M6IGxpbmUpOiAwLzMwZEIKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDExIGluICAgOCk6 IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAzMCAobmlkICAyMiBv dXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTA6ICAgICstIGN0bCA0OSAobmlkICAzNCBpbiAg IDgpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MCAobmlkICAzNSBpbiAgIDgpOiBtdXRlCnBjbTA6 IApwY20wOiBTcGVha2VyL0JlZXAgVm9sdW1lIChPU1M6IHNwZWFrZXIpOiAtMzQvMTJkQgpwY20w OiAgICArLSBjdGwgIDggKG5pZCAgMTEgaW4gICA1KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11 dGUKcGNtMDogICAgKy0gY3RsIDQ2IChuaWQgIDM0IGluICAgNSk6IG11dGUKcGNtMDogICAgKy0g Y3RsIDU3IChuaWQgIDM1IGluICAgNSk6IG11dGUKcGNtMDogCnBjbTA6IFJlY29yZGluZyBMZXZl bCAoT1NTOiByZWMpOiAtMTYvMzBkQgpwY20wOiAgICArLSBjdGwgIDEgKG5pZCAgIDggaW4gICAw KTogLTE2LzMwZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsICAyIChuaWQgICA5 IGluICAgMCk6IC0xNi8zMGRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCA0MSAo bmlkICAzNCBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA0MiAobmlkICAzNCBpbiAgIDEp OiBtdXRlCnBjbTA6ICAgICstIGN0bCA0NiAobmlkICAzNCBpbiAgIDUpOiBtdXRlCnBjbTA6ICAg ICstIGN0bCA0OSAobmlkICAzNCBpbiAgIDgpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MSAobmlk ICAzNCBpbiAgMTApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MiAobmlkICAzNSBpbiAgIDApOiBt dXRlCnBjbTA6ICAgICstIGN0bCA1MyAobmlkICAzNSBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICst IGN0bCA1NyAobmlkICAzNSBpbiAgIDUpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MCAobmlkICAz NSBpbiAgIDgpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MiAobmlkICAzNSBpbiAgMTApOiBtdXRl CnBjbTA6IApwY20wOiBJbnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KTogLTM0LzEyZEIKcGNtMDog ICAgKy0gY3RsICAzIChuaWQgIDExIGluICAgMCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRl CnBjbTA6ICAgICstIGN0bCAgNCAobmlkICAxMSBpbiAgIDEpOiAtMzQvMTJkQiAoMzIgc3RlcHMp ICsgbXV0ZQpwY20wOiAgICArLSBjdGwgIDggKG5pZCAgMTEgaW4gICA1KTogLTM0LzEyZEIgKDMy IHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDExIGluICAgOCk6IC0zNC8x MmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAxNSAobmlkICAxMiBpbiAgIDEp OiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MSAobmlkICAzNCBpbiAgMTApOiBtdXRlCnBjbTA6ICAg ICstIGN0bCA2MiAobmlkICAzNSBpbiAgMTApOiBtdXRlCnBjbTA6IApwY20wOiBJbnB1dCBNb25p dG9yaW5nIExldmVsIChPU1M6IGlnYWluKTogMC8wZEIKcGNtMDogICAgKy0gY3RsIDE1IChuaWQg IDEyIGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6IE1peGVyICJ2b2wiOgpwY20wOiBNaXhlciAi cGNtIjoKcGNtMDogTWl4ZXIgInNwZWFrZXIiOgpwY20wOiBNaXhlciAibGluZSI6CnBjbTA6IE1p eGVyICJtaWMiOgpwY20wOiBNaXhlciAibWl4IjoKcGNtMDogTWl4ZXIgInJlYyI6CnBjbTA6IE1p eGVyICJpZ2FpbiI6CnBjbTA6IE1peGVyICJtb25pdG9yIjoKcGNtMDogU29mdCBQQ00gbWl4ZXIg RU5BQkxFRApwY20wOiBQbGF5YmFjayBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQg UmlnaHQsIApwY20wOiBQbGF5YmFjayBjaGFubmVsIG1hdHJpeCBpczogMi4wIChkaXNjb25uZWN0 ZWQpCnBjbTA6IFJlY29yZGluZyBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmln aHQsIApwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBtYXRyaXggaXM6IDIuMCAoZGlzY29ubmVjdGVk KQpwY20xOiA8UmVhbHRlayBBTEMxMjAwIChPbmJvYXJkIEFuYWxvZyBTcGVha2VyKT4gYXQgbmlk IDIxIG9uIGhkYWEwCnBjbTE6IFBsYXliYWNrOgpwY20xOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAw MDAwMDEgUENNCnBjbTE6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDU2MCAxNiAyMCAyNCBiaXRz LCA0NCA0OCA5NiAxOTIgS0h6CnBjbTE6ICAgICAgICAgICAgIERBQzogMwpwY20xOiAKcGNtMTog ICAgIG5pZD0yMSBbcGluOiBTcGVha2VyIChGaXhlZCldCnBjbTE6ICAgICAgICsgPC0gbmlkPTEz IFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBjbTE6ICAgICAgICAgICAgICArIDwtIG5p ZD0zIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMTogICAgICAgICAgICAgICsgPC0gbmlk PTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20xOiAKcGNtMTogTWFzdGVyIFZvbHVtZSAo T1NTOiB2b2wpOiAtNDYvMGRCCnBjbTE6ICAgICstIGN0bCAxNiAobmlkICAxMyBvdXQpOiAgICAt NDYvMGRCICgzMiBzdGVwcykKcGNtMTogICAgKy0gY3RsIDE3IChuaWQgIDEzIGluICAgMCk6IG11 dGUKcGNtMTogICAgKy0gY3RsIDE4IChuaWQgIDEzIGluICAgMSk6IG11dGUKcGNtMTogICAgKy0g Y3RsIDI3IChuaWQgIDIxIGluICk6ICAgIG11dGUKcGNtMTogCnBjbTE6IFBDTSBWb2x1bWUgKE9T UzogcGNtKTogMC8wZEIKcGNtMTogICAgKy0gY3RsIDE3IChuaWQgIDEzIGluICAgMCk6IG11dGUK cGNtMTogCnBjbTE6IElucHV0IE1peCBMZXZlbCAoT1NTOiBtaXgpCnBjbTE6ICAgICstIGN0bCAx OCAobmlkICAxMyBpbiAgIDEpOiBtdXRlCnBjbTE6IApwY20xOiBJbnB1dCBNb25pdG9yaW5nIExl dmVsIChPU1M6IGlnYWluKTogMC8wZEIKcGNtMTogICAgKy0gY3RsIDE4IChuaWQgIDEzIGluICAg MSk6IG11dGUKcGNtMTogCnBjbTE6IE1peGVyICJ2b2wiOgpwY20xOiBNaXhlciAicGNtIjoKcGNt MTogTWl4ZXIgImlnYWluIjoKcGNtMTogU29mdCBQQ00gbWl4ZXIgRU5BQkxFRApwY20xOiBQbGF5 YmFjayBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmlnaHQsIApwY20xOiBQbGF5 YmFjayBjaGFubmVsIG1hdHJpeCBpczogMi4wICh1bmtub3duKQp1c2J1czA6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCmF0YTI6 IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMjogcmVzZXQgdHAxIG1h c2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMAp1Z2VuMS4xOiA8blZpZGlhPiBhdCB1c2J1czEKdWh1 YjA6IDxuVmlkaWEgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYnVzMQp1Z2VuMC4xOiA8blZpZGlhPiBhdCB1c2J1czAKdWh1YjE6IDxuVmlkaWEg T0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz MAphdGEyOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHJlc2V0 IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGEzOiBTQVRBIGNvbm5lY3QgdGlt ZT0wbXMgc3RhdHVzPTAwMDAwMTEzCmF0YTM6IHJlc2V0IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBv c3RhdDE9MDAKYXRhMzogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGEz OiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDEwMDAwCnVodWIxOiAxMCBw b3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmF0YTQ6IFNBVEEgY29ubmVjdCB0 aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGE1OiBTQVRBIGNvbm5lY3QgdGltZW91dCBzdGF0dXM9 MDAwMDAwMDAKYWRhMCBhdCBhdGEyIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiA8 U1QzMTYwMzE4QVMgSFAzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1i ZXIgNVZZMFdSUkIKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTUs IFBJTyA4MTkyYnl0ZXMpCmFkYTA6IDE1MjYyN01CICgzMTI1ODE4MDggNTEyIGJ5dGUgc2VjdG9y czogMTZIIDYzUy9UIDE2MzgzQykKYWRhMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CnBh c3MwIGF0IGF0YTIgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCnBhc3MwOiA8U1QzMTYwMzE4 QVMgSFAzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCnBhc3MwOiBTZXJpYWwgTnVtYmVyIDVWWTBX UlJCCnBhc3MwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNSwgUElPIDgx OTJieXRlcykKcGFzczEgYXQgYXRhMyBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKcGFzczE6 IDxocCBDRERWRFcgVFMtSDY1M1IgMEUwMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNl IApwYXNzMTogU2VyaWFsIE51bWJlciBSMDYyNkdDU0EwMzcxNjAwCnBhc3MxOiAxNTAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgxOTJieXRl cykKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KTmV0dnNjIGluaXRpYWxpemluZy4uLiBkb25l IQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAg IFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6 IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAw MDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBm MCBwbWM6IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoY2QwIGF0IGF0YTMg YnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCklTQSBJUlEgMWNkMDogKSB0byBsYXBpYyAxIHZl Y3RvciA0OAo8aHAgQ0REVkRXIFRTLUg2NTNSIDBFMDA+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0w IGRldmljZSAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIgKGNkMDogU2VyaWFsIE51bWJlciBS MDYyNkdDU0EwMzcxNjAwCklTQSBJUlEgMTJjZDA6IDE1MC4wMDBNQi9zIHRyYW5zZmVycykgdG8g bGFwaWMgMSB2ZWN0b3IgNDkKIChTQVRBIDEueCwgVURNQTUsIEFUQVBJIDEyYnl0ZXMsIGlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDIxIChQSU8gODE5MmJ5dGVzUENJIElSUSAyMSkpIHRvIGxhcGlj IDEgdmVjdG9yIDUwCgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMyAoY2QwOiBBdHRlbXB0IHRv IHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQg LSB0cmF5IGNsb3NlZApQQ0kgSVJRIDIzKSB0byBsYXBpYyAxIHZlY3RvciA1MQptc2k6IEFzc2ln bmluZyBNU0kgSVJRIDI1NyB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDU2Cm1zaTogQXNzaWduaW5n IE1TSSBJUlEgMjU4IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTcKbXNpOiBBc3NpZ25pbmcgTVNJ IElSUSAyNTkgdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA1OAptc2k6IEFzc2lnbmluZyBNU0kgSVJR IDI2MCB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDU5Cm1zaTogQXNzaWduaW5nIE1TSSBJUlEgMjYx IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNjAKbXNpOiBBc3NpZ25pbmcgTVNJIElSUSAyNjIgdG8g bG9jYWwgQVBJQyAxIHZlY3RvciA2MQptc2k6IEFzc2lnbmluZyBNU0kgSVJRIDI2MyB0byBsb2Nh bCBBUElDIDEgdmVjdG9yIDYyCm1zaTogQXNzaWduaW5nIE1TSSBJUlEgMjY0IHRvIGxvY2FsIEFQ SUMgMSB2ZWN0b3IgNjMKVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxvd2VyIDEgYml0KHMpClRp bWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTEwNTA1MDkzNSBIeiBxdWFsaXR5IC0xMDAK V0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFu Y2UuCkdFT006IG5ldyBkaXNrIGFkYTAKR0VPTTogbmV3IGRpc2sgY2QwClJvb3QgbW91bnQgd2Fp dGluZyBmb3I6IHVzYnVzMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEKdWh1YjA6IDEw IHBvcnRzIHdpdGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKVHJ5aW5nIHRvIG1vdW50IHJv b3QgZnJvbSB1ZnM6L2Rldi9ncHQvZ3Byb290IFtyd10uLi4Kc3RhcnRfaW5pdDogdHJ5aW5nIC9z YmluL2luaXQKdWdlbjEuMjogPFdlc3Rlcm4gRGlnaXRhbD4gYXQgdXNidXMxCnVtYXNzMDogPFdl c3Rlcm4gRGlnaXRhbCBVU0IgSGFyZCBEcml2ZSwgY2xhc3MgMC8wLCByZXYgMi4wMC8xMS4wNSwg YWRkciAyPiBvbiB1c2J1czEKdW1hc3MwOiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtzID0g MHg0MTAwCnVtYXNzMDo0OjA6IEF0dGFjaGVkIHRvIHNjYnVzNAoocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBEb3duIHJldmluZyBQcm90b2NvbCBWZXJzaW9uIGZyb20gMiB0byAwPwpwYXNzMiBh dCB1bWFzcy1zaW0wIGJ1cyAwIHNjYnVzNCB0YXJnZXQgMCBsdW4gMApwYXNzMjogPFdEQyBXRDgw IDBCQi0wMENBQTEgMTcuMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApwYXNz MjogU2VyaWFsIE51bWJlciAwQjAwMDEyMjA0NENFQkUzCnBhc3MyOiA0MC4wMDBNQi9zIHRyYW5z ZmVycwpHRU9NOiBuZXcgZGlzayBkYTAKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXM0IHRh cmdldCAwIGx1biAwCmRhMDogPFdEQyBXRDgwIDBCQi0wMENBQTEgMTcuMD4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTA6IFNlcmlhbCBOdW1iZXIgMEIwMDAxMjIwNDRDRUJF MwpkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNzYzMTlNQiAoMTU2MzAxNDg4IDUxMiBi eXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgOTcyOUMpCmRhMDogcXVpcmtzPTB4MjxOT182X0JZVEU+ CmRhMDogRGVsZXRlIG1ldGhvZHM6IDxOT05FKCopPgpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0 IDB4ZmZmZmZlMDBmNzk4NGQ1OCBidWZ3YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19iaW8uYzozMDk3CiAybmQgMHhmZmZmZjgwMDA0ODYzMjAwIGRpcmhhc2ggKGRpcmhhc2gp IEAgL3Vzci9zcmMvc3lzL3Vmcy91ZnMvdWZzX2Rpcmhhc2guYzoyODUKS0RCOiBzdGFjayBiYWNr dHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisw eDJiL2ZyYW1lIDB4ZmZmZmZlMDAwMDM1ZDQyMAp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRu ZXNzX2NoZWNrb3JkZXIrMHhlNDUvZnJhbWUgMHhmZmZmZmUwMDAwMzVkNGIwCl9zeF94bG9jaygp IGF0IF9zeF94bG9jaysweDc1L2ZyYW1lIDB4ZmZmZmZlMDAwMDM1ZDRmMAp1ZnNkaXJoYXNoX2Fk ZCgpIGF0IHVmc2Rpcmhhc2hfYWRkKzB4M2EvZnJhbWUgMHhmZmZmZmUwMDAwMzVkNTMwCnVmc19k aXJlbnRlcigpIGF0IHVmc19kaXJlbnRlcisweDY0MS9mcmFtZSAweGZmZmZmZTAwMDAzNWQ1ZjAK dWZzX21ha2Vpbm9kZSgpIGF0IHVmc19tYWtlaW5vZGUrMHg1YmYvZnJhbWUgMHhmZmZmZmUwMDAw MzVkN2IwCnVmc19jcmVhdGUoKSBhdCB1ZnNfY3JlYXRlKzB4MmQvZnJhbWUgMHhmZmZmZmUwMDAw MzVkN2QwClZPUF9DUkVBVEVfQVBWKCkgYXQgVk9QX0NSRUFURV9BUFYrMHhmMS9mcmFtZSAweGZm ZmZmZTAwMDAzNWQ4MDAKdm5fb3Blbl9jcmVkKCkgYXQgdm5fb3Blbl9jcmVkKzB4MmM2L2ZyYW1l IDB4ZmZmZmZlMDAwMDM1ZDk2MAprZXJuX29wZW5hdCgpIGF0IGtlcm5fb3BlbmF0KzB4MjU3L2Zy YW1lIDB4ZmZmZmZlMDAwMDM1ZGFlMAphbWQ2NF9zeXNjYWxsKCkgYXQgYW1kNjRfc3lzY2FsbCsw eDI3Zi9mcmFtZSAweGZmZmZmZTAwMDAzNWRiZjAKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5 c2NhbGwrMHhmYi9mcmFtZSAweGZmZmZmZTAwMDAzNWRiZjAKLS0tIHN5c2NhbGwgKDQ5OSwgRnJl ZUJTRCBFTEY2NCwgc3lzX29wZW5hdCksIHJpcCA9IDB4ODAwYmE0NzlhLCByc3AgPSAweDdmZmZm ZmZmZTU2OCwgcmJwID0gMHg3ZmZmZmZmZmU2NjAgLS0tCldhaXRpbmcgKG1heCA2MCBzZWNvbmRz KSBmb3Igc3lzdGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXgg NjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3AuLi5kb25l CldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNlcicgdG8g c3RvcC4uLgpTeW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uMyAxIDAgMSAwIDAgZG9u ZQpBbGwgYnVmZmVycyBzeW5jZWQuCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhmZmZmZjgw MDA0ODJjZDUwIHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19tb3VudC5jOjEyMjkK IDJuZCAweGZmZmZmODAwMDQ2NTI5YTAgZGV2ZnMgKGRldmZzKSBAIC91c3Ivc3JjL3N5cy91ZnMv ZmZzL2Zmc192ZnNvcHMuYzoxMzc1CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm X3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9mcmFtZSAweGZmZmZmZTAw MDAzNWQ1ZDAKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ZTQ1 L2ZyYW1lIDB4ZmZmZmZlMDAwMDM1ZDY2MApfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9h cmdzKzB4YWNmL2ZyYW1lIDB4ZmZmZmZlMDAwMDM1ZDc5MAp2b3Bfc3RkbG9jaygpIGF0IHZvcF9z dGRsb2NrKzB4M2MvZnJhbWUgMHhmZmZmZmUwMDAwMzVkN2IwClZPUF9MT0NLMV9BUFYoKSBhdCBW T1BfTE9DSzFfQVBWKzB4ZmMvZnJhbWUgMHhmZmZmZmUwMDAwMzVkN2UwCl92bl9sb2NrKCkgYXQg X3ZuX2xvY2srMHg4YS9mcmFtZSAweGZmZmZmZTAwMDAzNWQ4NTAKZmZzX2ZsdXNoZmlsZXMoKSBh dCBmZnNfZmx1c2hmaWxlcysweDExMy9mcmFtZSAweGZmZmZmZTAwMDAzNWQ4YzAKc29mdGRlcF9m bHVzaGZpbGVzKCkgYXQgc29mdGRlcF9mbHVzaGZpbGVzKzB4MjczL2ZyYW1lIDB4ZmZmZmZlMDAw MDM1ZDkzMApmZnNfdW5tb3VudCgpIGF0IGZmc191bm1vdW50KzB4ODEvZnJhbWUgMHhmZmZmZmUw MDAwMzVkOTkwCmRvdW5tb3VudCgpIGF0IGRvdW5tb3VudCsweDQyYy9mcmFtZSAweGZmZmZmZTAw MDAzNWRhMTAKdmZzX3VubW91bnRhbGwoKSBhdCB2ZnNfdW5tb3VudGFsbCsweDYxL2ZyYW1lIDB4 ZmZmZmZlMDAwMDM1ZGE0MAprZXJuX3JlYm9vdCgpIGF0IGtlcm5fcmVib290KzB4NGY2L2ZyYW1l IDB4ZmZmZmZlMDAwMDM1ZGFjMApzeXNfcmVib290KCkgYXQgc3lzX3JlYm9vdCsweDU4L2ZyYW1l IDB4ZmZmZmZlMDAwMDM1ZGFlMAphbWQ2NF9zeXNjYWxsKCkgYXQgYW1kNjRfc3lzY2FsbCsweDI3 Zi9mcmFtZSAweGZmZmZmZTAwMDAzNWRiZjAKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2Nh bGwrMHhmYi9mcmFtZSAweGZmZmZmZTAwMDAzNWRiZjAKLS0tIHN5c2NhbGwgKDU1LCBGcmVlQlNE IEVMRjY0LCBzeXNfcmVib290KSwgcmlwID0gMHg4MDA4NmI1ZWMsIHJzcCA9IDB4N2ZmZmZmZmZl YTM4LCByYnAgPSAweDdmZmZmZmZmZWJhMCAtLS0KU3dhcCBkZXZpY2UgYWRhMHAxIHJlbW92ZWQu ClVwdGltZTogMWgxNm0zMHMKKGFkYTA6YXRhMjowOjA6MCk6IHNwaW4tZG93bgpUYWJsZSAnRkFD UCcgYXQgMHhkZmVlN2Y0MApUYWJsZSAnU0xJQycgYXQgMHhkZmVlODE4MApUYWJsZSAnU1NEVCcg YXQgMHhkZmVlODM0MApUYWJsZSAnSFBFVCcgYXQgMHhkZmVlODVjMApUYWJsZSAnTUNGRycgYXQg MHhkZmVlODY0MApUYWJsZSAnQVBJQycgYXQgMHhkZmVlODA4MApBUElDOiBGb3VuZCB0YWJsZSBh dCAweGRmZWU4MDgwCkFQSUM6IFVzaW5nIHRoZSBNQURUIGVudW1lcmF0b3IuCk1BRFQ6IEZvdW5k IENQVSBBUElDIElEIDAgQUNQSSBJRCAwOiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDAgKEFQKQpN QURUOiBGb3VuZCBDUFUgQVBJQyBJRCAxIEFDUEkgSUQgMTogZW5hYmxlZApTTVA6IEFkZGVkIENQ VSAxIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMiBBQ1BJIElEIDI6IGRpc2FibGVkCk1B RFQ6IEZvdW5kIENQVSBBUElDIElEIDMgQUNQSSBJRCAzOiBkaXNhYmxlZApDb3B5cmlnaHQgKGMp IDE5OTItMjAxNSBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAs IDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdl bnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQu CkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0 aW9uLgpGcmVlQlNEIDExLjAtQ1VSUkVOVCAjMCByMjc5MjEwOiBNb24gRmViIDIzIDE5OjE0OjEy IFVUQyAyMDE1CiAgICByb290QHJlbGVuZzIubnlpLmZyZWVic2Qub3JnOi91c3Ivb2JqL3Vzci9z cmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuNS4xICh0YWdzL1JF TEVBU0VfMzUxL2ZpbmFsIDIyNTY2OCkgMjAxNTAxMTUKV0FSTklORzogV0lUTkVTUyBvcHRpb24g ZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClByZWxvYWRlZCBlbGYga2VybmVs ICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODFiZjkwMDAuCkNhbGlicmF0aW5n IFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAyMjEwMTAwNDYzIEh6CkNQVTogQU1EIEF0aGxvbih0 bSkgNjQgWDIgRHVhbCBDb3JlIFByb2Nlc3NvciA0MjAwKyAoMjIxMC4xMC1NSHogSzgtY2xhc3Mg Q1BVKQogIE9yaWdpbj0iQXV0aGVudGljQU1EIiAgSWQ9MHg0MGZiMiAgRmFtaWx5PTB4ZiAgTW9k ZWw9MHg0YiAgU3RlcHBpbmc9MgogIEZlYXR1cmVzPTB4MTc4YmZiZmY8RlBVLFZNRSxERSxQU0Us VFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYs Q0xGTFVTSCxNTVgsRlhTUixTU0UsU1NFMixIVFQ+CiAgRmVhdHVyZXMyPTB4MjAwMTxTU0UzLENY MTY+CiAgQU1EIEZlYXR1cmVzPTB4ZWE1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFJEVFND UCxMTSwzRE5vdyErLDNETm93IT4KICBBTUQgRmVhdHVyZXMyPTB4MWY8TEFIRixDTVAsU1ZNLEV4 dEFQSUMsQ1I4PgogIFNWTTogKGRpc2FibGVkIGluIEJJT1MpIEZlYXR1cmVzPTB4MApSZXZpc2lv bj0xLCBBU0lEcz02NApMMSAyTUIgZGF0YSBUTEI6IDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRp dmUKTDEgMk1CIGluc3RydWN0aW9uIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpM MSA0S0IgZGF0YSBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBpbnN0 cnVjdGlvbiBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIGRhdGEgY2FjaGU6 IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0aXZl CkwxIGluc3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMv dGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiAyTUIgdW5pZmllZCBUTEI6IDAgZW50cmllcywgZGlz YWJsZWQvbm90IHByZXNlbnQKTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmllcywgNC13YXkgYXNz b2NpYXRpdmUKTDIgNEtCIGluc3RydWN0aW9uIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFzc29j aWF0aXZlCkwyIHVuaWZpZWQgY2FjaGU6IDUxMiBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGlu ZXMvdGFnLCAxNi13YXkgYXNzb2NpYXRpdmUKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5 NiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMTAwMDAgLSAweDAw MDAwMDAwMDAwOWFmZmYsIDU2OTM0NCBieXRlcyAoMTM5IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAw MDAgLSAweDAwMDAwMDAwMDAxZmZmZmYsIDEwNDg1NzYgYnl0ZXMgKDI1NiBwYWdlcykKMHgwMDAw MDAwMDAxYzI1MDAwIC0gMHgwMDAwMDAwMGQ4OTM0ZmZmLCAzNjA0MDIxMjQ4IGJ5dGVzICg4Nzk4 ODggcGFnZXMpCjB4MDAwMDAwMDEwMDAwMDAwMCAtIDB4MDAwMDAwMDExZmZlN2ZmZiwgNTM2Nzcy NjA4IGJ5dGVzICgxMzEwNDggcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDQxMDU2NDE5ODQgKDM5MTUg TUIpCkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA0MDAKQUNQSSBBUElDIFRhYmxlOiA8SFBR T0VNIFNMSUMtQlBDPgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAxIGFzIGEgdGFyZ2V0CkZyZWVC U0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NN UDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1 MSAoQVApOiBBUElDIElEOiAgMQpBUElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwCkFQSUM6IENQVSAx IGhhcyBBQ1BJIElEIDEKeDg2YmlvczogIElWVCAweDAwMDAwMC0weDAwMDRmZiBhdCAweGZmZmZm ODAwMDAwMDAwMDAKeDg2YmlvczogU1NFRyAweDA5YTAwMC0weDA5YWZmZiBhdCAweGZmZmZmZTAx MWM1NWMwMDAKeDg2YmlvczogRUJEQSAweDA5ZjAwMC0weDA5ZmZmZiBhdCAweGZmZmZmODAwMDAw OWYwMDAKeDg2YmlvczogIFJPTSAweDBhMDAwMC0weDBmZWZmZiBhdCAweGZmZmZmODAwMDAwYTAw MDAKVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVwIGNwdSAxCkFDUEk6IFJTRFAgMHgwMDAwMDAw MDAwMEY3ODMwIDAwMDAyNCAodjAyIEhQUU9FTSkKQUNQSTogWFNEVCAweDAwMDAwMDAwREZFRTMx MDAgMDAwMDU0ICh2MDEgSFBRT0VNIFNMSUMtQlBDIDQyMzAyRTMxIEFXUkQgMDAwMDAwMDApCkFD UEk6IEZBQ1AgMHgwMDAwMDAwMERGRUU3RjQwIDAwMDBGNCAodjAzIEhQUU9FTSBTTElDLUJQQyA0 MjMwMkUzMSBBV1JEIDAwMDAwMDAwKQpBQ1BJIEJJT1MgV2FybmluZyAoYnVnKTogMzIvNjRYIGxl bmd0aCBtaXNtYXRjaCBpbiBGQURUL1BtMWFFdmVudEJsb2NrOiAzMi84ICgyMDE1MDIwNC90YmZh ZHQtNjQ0KQpBQ1BJIEJJT1MgV2FybmluZyAoYnVnKTogMzIvNjRYIGxlbmd0aCBtaXNtYXRjaCBp biBGQURUL1BtMWFDb250cm9sQmxvY2s6IDE2LzggKDIwMTUwMjA0L3RiZmFkdC02NDQpCkFDUEkg QklPUyBXYXJuaW5nIChidWcpOiAzMi82NFggbGVuZ3RoIG1pc21hdGNoIGluIEZBRFQvUG1UaW1l ckJsb2NrOiAzMi84ICgyMDE1MDIwNC90YmZhZHQtNjQ0KQpBQ1BJIEJJT1MgV2FybmluZyAoYnVn KTogMzIvNjRYIGxlbmd0aCBtaXNtYXRjaCBpbiBGQURUL0dwZTBCbG9jazogNjQvOCAoMjAxNTAy MDQvdGJmYWR0LTY0NCkKQUNQSSBCSU9TIFdhcm5pbmcgKGJ1Zyk6IDMyLzY0WCBsZW5ndGggbWlz bWF0Y2ggaW4gRkFEVC9HcGUxQmxvY2s6IDEyOC84ICgyMDE1MDIwNC90YmZhZHQtNjQ0KQpBQ1BJ IEJJT1MgV2FybmluZyAoYnVnKTogSW52YWxpZCBsZW5ndGggZm9yIEZBRFQvUG0xYUV2ZW50Qmxv Y2s6IDgsIHVzaW5nIGRlZmF1bHQgMzIgKDIwMTUwMjA0L3RiZmFkdC03MjUpCkFDUEkgQklPUyBX YXJuaW5nIChidWcpOiBJbnZhbGlkIGxlbmd0aCBmb3IgRkFEVC9QbTFhQ29udHJvbEJsb2NrOiA4 LCB1c2luZyBkZWZhdWx0IDE2ICgyMDE1MDIwNC90YmZhZHQtNzI1KQpBQ1BJIEJJT1MgV2Fybmlu ZyAoYnVnKTogSW52YWxpZCBsZW5ndGggZm9yIEZBRFQvUG1UaW1lckJsb2NrOiA4LCB1c2luZyBk ZWZhdWx0IDMyICgyMDE1MDIwNC90YmZhZHQtNzI1KQpBQ1BJOiBEU0RUIDB4MDAwMDAwMDBERkVF MzJDMCAwMDRDMzQgKHYwMSBIUFFPRU0gU0xJQy1CUEMgMDAwMDEwMDAgTVNGVCAwMzAwMDAwMCkK QUNQSTogRkFDUyAweDAwMDAwMDAwREZFRTAwMDAgMDAwMDQwCkFDUEk6IFNMSUMgMHgwMDAwMDAw MERGRUU4MTgwIDAwMDE3NiAodjAxIEhQUU9FTSBTTElDLUJQQyA0MjMwMkUzMSBBV1JEIDAwMDAw MDAwKQpBQ1BJOiBTU0RUIDB4MDAwMDAwMDBERkVFODM0MCAwMDAyMDYgKHYwMSBIUFFPRU0gU0xJ Qy1CUEMgMDAwMDAwMDEgIExUUCAwMDAwMDAwMSkKQUNQSTogSFBFVCAweDAwMDAwMDAwREZFRTg1 QzAgMDAwMDM4ICh2MDEgSFBRT0VNIFNMSUMtQlBDIDQyMzAyRTMxIEFXUkQgMDAwMDAwOTgpCkFD UEk6IE1DRkcgMHgwMDAwMDAwMERGRUU4NjQwIDAwMDAzQyAodjAxIEhQUU9FTSBTTElDLUJQQyA0 MjMwMkUzMSBBV1JEIDAwMDAwMDAwKQpBQ1BJOiBBUElDIDB4MDAwMDAwMDBERkVFODA4MCAwMDAw OTggKHYwMSBIUFFPRU0gU0xJQy1CUEMgNDIzMDJFMzEgQVdSRCAwMDAwMDAwMCkKTUFEVDogRm91 bmQgSU8gQVBJQyBJRCA0LCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6IENoYW5n aW5nIEFQSUMgSUQgdG8gNAppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50 cGluIDAKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKaW9hcGljMDog Um91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJj ZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbApNQURUOiBJbnRlcnJ1 cHQgb3ZlcnJpZGU6IHNvdXJjZSAxNCwgaXJxIDE0Ck1BRFQ6IEludGVycnVwdCBvdmVycmlkZTog c291cmNlIDE1LCBpcnEgMTUKbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzA6IExJ TlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWMwOiBMSU5UMSBwb2xhcml0eTogaGlnaApsYXBpYzE6IFJv dXRpbmcgTk1JIC0+IExJTlQxCmxhcGljMTogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzE6IExJ TlQxIHBvbGFyaXR5OiBoaWdoCk1BRFQ6IElnbm9yaW5nIGxvY2FsIE5NSSByb3V0ZWQgdG8gQUNQ SSBDUFUgMgpNQURUOiBJZ25vcmluZyBsb2NhbCBOTUkgcm91dGVkIHRvIEFDUEkgQ1BVIDMKaW9h cGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAg ICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAw eGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAw MDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEw MDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKc25kX3VuaXRfaW5pdCgpIHU9MHgw MGZmODAwMCBbNTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdCmZlZWRl cl9yZWdpc3Rlcjogc25kX3VuaXQ9LTEgc25kX21heGF1dG92Y2hhbnM9MTYgbGF0ZW5jeT01IGZl ZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9yYXRlX21heD0yMDE2MDAwIGZlZWRlcl9yYXRlX3JvdW5k PTI1CndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KcmFuZG9tOiBlbnRyb3B5IGRldmljZSBpbmZy YXN0cnVjdHVyZSBkcml2ZXIKcmFuZG9tOiBzZWxlY3RpbmcgaGlnaGVzdCBwcmlvcml0eSBhZGFw dG9yIDxEdW1teT4Ka2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxt ZW1vcnk+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKbmV0bWFwOiBsb2FkZWQgbW9kdWxlCm51bGw6 IDxmdWxsIGRldmljZSwgbnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5kb206IFNPRlQ6IHlh cnJvdyBpbml0KCkKcmFuZG9tOiBzZWxlY3RpbmcgaGlnaGVzdCBwcmlvcml0eSBhZGFwdG9yIDxZ YXJyb3c+ClZFU0E6IElOVCAweDEwIHZlY3RvciAweGMwMDA6MHgxMDBjClZFU0E6IGluZm9ybWF0 aW9uIGJsb2NrCjAwMDAgICA1NiA0NSA1MyA0MSAwMCAwMyAwMCAwMSAwMCA5OCAwMSAwMCAwMCAw MCAyMiAwMAowMDEwICAgMDAgOTggMDAgMDggNzIgMDUgMDcgMDEgMDAgOTggMWEgMDEgMDAgOTgg MmYgMDEKMDAyMCAgIDAwIDk4IDAwIDAxIDAxIDAxIDAyIDAxIDAzIDAxIDA0IDAxIDA1IDAxIDA2 IDAxCjAwMzAgICAwNyAwMSAwZSAwMSAwZiAwMSAxMSAwMSAxMiAwMSAxNCAwMSAxNSAwMSAxNyAw MQowMDQwICAgMTggMDEgMWEgMDEgMWIgMDEgMzAgMDEgMzEgMDEgMzIgMDEgMzMgMDEgMzQgMDEK MDA1MCAgIDM1IDAxIDM2IDAxIDNkIDAxIDNlIDAxIDQ1IDAxIDQ2IDAxIDQ3IDAxIDQ4IDAxCjAw NjAgICA1MiAwMSBmZiBmZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMDcw ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDA4MCAg IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwOTAgICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGEwICAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBiMCAgIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwYzAgICAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGQwICAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBlMCAgIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwZjAgICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTAwICAgNGUgNTYgNDkgNDQgNDkg NDEgMDAgNGUgNTYgNDkgNDQgNDkgNDEgMjAgNDMgNmYKMDExMCAgIDcyIDcwIDZmIDcyIDYxIDc0 IDY5IDZmIDZlIDAwIDQ3IDM3IDMyIDIwIDQyIDZmCjAxMjAgICA2MSA3MiA2NCAyMCAyZCAyMCA3 MCAzMyAzOCAzMSA2ZSAzMiAzMCAyMCAwMCA0MwowMTMwICAgNjggNjkgNzAgMjAgNTIgNjUgNzYg MjAgMjAgMjAgMDAgMDAgMDAgMDAgMDAgMDAKMDE0MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxNTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTYwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKMDE3MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCjAxODAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMAowMTkwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAKMDFhMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCjAxYjAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAowMWMwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAKMDFkMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwCjAxZTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMAowMWYwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKVkVTQTogMzIgbW9kZShzKSBmb3VuZApWRVNBOiB2My4wLCAxMzEwNzJrIG1lbW9yeSwgZmxh Z3M6MHgxLCBtb2RlIHRhYmxlOjB4ZmZmZmZlMDExYzU5ZTAyMiAoOTgwMDAwMjIpClZFU0E6IE5W SURJQQpWRVNBOiBOVklESUEgQ29ycG9yYXRpb24gRzcyIEJvYXJkIC0gcDM4MW4yMCAgQ2hpcCBS ZXYgICAKaW86IDxJL08+ClZNQlVTOiBsb2FkCmhwdG5yOiBSNzUwL0RDNzI4MCBjb250cm9sbGVy IGRyaXZlciB2MS4wLjEKaHB0Mjd4eDogUm9ja2V0UkFJRCAyN3h4IGNvbnRyb2xsZXIgZHJpdmVy IHYxLjEKaHB0cnI6IFJvY2tldFJBSUQgMTd4eC8yeHh4IFNBVEEgY29udHJvbGxlciBkcml2ZXIg djEuMgphY3BpMDogPEhQUU9FTSBTTElDLUJQQz4gb24gbW90aGVyYm9hcmQKQUNQSTogQWxsIEFD UEkgVGFibGVzIHN1Y2Nlc3NmdWxseSBhY3F1aXJlZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZp Z3VyYXRpb24gYmFzZSBAIDB4ZjAwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNB IElSUSA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkK QUNQSSBFcnJvcjogRmllbGQgW0FTU01dIGF0IDUyNDMyMCBleGNlZWRzIEJ1ZmZlciBbQlVGMF0g c2l6ZSA4ODAgKGJpdHMpICgyMDE1MDIwNC9kc29wY29kZS0yNDcpCkFDUEkgRXJyb3I6IE1ldGhv ZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcMTM0X1NCXy5NRU1fLl9DUlNdIChOb2RlIDB4ZmZm ZmY4MDAwMmVkNjUwMCksIEFFX0FNTF9CVUZGRVJfTElNSVQgKDIwMTUwMjA0L3BzcGFyc2UtNTUy KQpBQ1BJIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXDEzNF9TQl8uTUVNXy5fQ1JT XSAoTm9kZSAweGZmZmZmODAwMDJlZDY1MDApLCBBRV9BTUxfQlVGRkVSX0xJTUlUICgyMDE1MDIw NC91dGV2YWwtMTExKQpjYW4ndCBmZXRjaCByZXNvdXJjZXMgZm9yIFwxMzRfU0JfLk1FTV8gLSBB RV9BTUxfQlVGRkVSX0xJTUlUCmNwdTA6IFByb2Nlc3NvciBcMTM0X1BSXy5DMDAwIChBQ1BJIElE IDApIC0+IEFQSUMgSUQgMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTA6IHN3aXRjaGlu ZyB0byBnZW5lcmljIEN4IG1vZGUKY3B1MTogUHJvY2Vzc29yIFwxMzRfUFJfLkMwMDEgKEFDUEkg SUQgMSkgLT4gQVBJQyBJRCAxCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQSTogUHJvY2Vz c29yIFwxMzRfUFJfLkMwMDIgKEFDUEkgSUQgMikgaWdub3JlZApBQ1BJOiBQcm9jZXNzb3IgXDEz NF9QUl8uQzAwMyAoQUNQSSBJRCAzKSBpZ25vcmVkCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQg MHg0MC0weDQzIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIgKElTQSBJUlEgMCkgdG8gbGFw aWMgMCB2ZWN0b3IgNDkKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDEwMApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZl ZmZmMDAwLTB4ZmVmZmYzZmYgaXJxIDAsOCBvbiBhY3BpMApocGV0MDogdmVuZG9yIDB4MTBkZSwg cmV2IDB4MSwgMjUwMDAwMDBIeiwgMyB0aW1lcnMsIGxlZ2FjeSByb3V0ZQpocGV0MDogIHQwOiBp cnFzIDB4MDBmZjNlZmEgKDMxKSwgcGVyaW9kaWMKaHBldDA6ICB0MTogaXJxcyAweDAwZmYzZWZh ICgzMSkKaHBldDA6ICB0MjogaXJxcyAweDAwZmYzZWZhICgzMSkKVGltZWNvdW50ZXIgIkhQRVQi IGZyZXF1ZW5jeSAyNTAwMDAwMCBIeiBxdWFsaXR5IDk1MAphdHJ0YzA6IDxBVCByZWFsdGltZSBj bG9jaz4gcG9ydCAweDcwLTB4NzMgb24gYWNwaTAKYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGlt ZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAwMDAwMHVzLCBhZGp1c3RtZW50IDAuNTAwMDAw MDAwcykKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOCAoSVNBIElSUSA4KSB0byBsYXBpYyAwIHZl Y3RvciA1MApFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwCkFD UEkgdGltZXI6IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAtPiAxMApU aW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAph Y3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgx MDBiIG9uIGFjcGkwCnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAx NQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQg MTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0 IDE1CnBjaV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlk YXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9s aW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAgIDcgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgICA3ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMzogICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAy NTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rNDogICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAg ICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcg OSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3 IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUg NyA5IDEwIDExIDE0IDE1CnBjaV9saW5rNjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAx NCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEg MTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDEx IDE0IDE1CnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBj aV9saW5rODogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rOTog ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTA6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBO ICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAg TiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTE6ICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDUgICBOICAgICAwICA1 IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAg NSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTI6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICA1IDcgOSAxMCAx MSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgNSA3IDkgMTAg MTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEw IDExIDE0IDE1CnBjaV9saW5rMTM6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUK ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1 CnBjaV9saW5rMTQ6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgIDcgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgICA3ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5r MTU6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAgMTEgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTY6ICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTc6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAw ICA1IDcgOSAxMCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAg MCAgNSA3IDkgMTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDUgNyA5IDEwIDExIDE0IDE1CnBjaV9saW5rMTg6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICA1IDcgOSAx MCAxMSAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgNSA3IDkg MTAgMTEgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5 IDEwIDExIDE0IDE1CnBjaV9saW5rMTk6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNgogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjA6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNwogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTcKICBBZnRlciBEaXNhYmxlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDE3CnBjaV9saW5rMjE6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxOAogIFZhbGlk YXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTgKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDE4CnBjaV9saW5rMjI6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxOQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTkKICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDE5CnBjaV9saW5rMjM6ICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNgog IFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjQ6ICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAx NgogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjU6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAw ICAxNgogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjY6ICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAg ICAwICAxNgogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjc6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBO ICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjIg MjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9saW5r Mjg6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIy IDIzCnBjaV9saW5rMjk6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDIyIDIzCnBjaV9saW5rMzA6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZhbGlk YXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9saW5rMzE6ICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAy MiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjIgMjMKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9saW5rMzI6ICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9s aW5rMzM6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDIyIDIzCnBjaV9saW5rMzQ6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9saW5rMzU6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMiAyMwogIFZh bGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjIgMjMKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIyIDIzCnBjaV9saW5rMzY6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAw ICAyMAogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwCnBjaV9saW5rMzc6ICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAg ICAwICAyMQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjEKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxCmFjcGlfYnV0dG9uMDogPFBvd2Vy IEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNm OC0weGNmZiBvbiBhY3BpMApwY2liMDogZGVjb2RpbmcgNCByYW5nZSAwLTB4Y2Y3CnBjaWIwOiBk ZWNvZGluZyA0IHJhbmdlIDB4ZDAwLTB4ZmZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGEw MDAwLTB4YmZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhjMDAwMC0weGRmZmZmCnBjaWIw OiBkZWNvZGluZyAzIHJhbmdlIDB4ZTAwMDAwMDAtMHhmZWJmZmZmZgpwY2kwOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5k b3I9MHgxMGRlLCBkZXY9MHgwM2VhLCByZXZpZD0weGExCglkb21haW49MCwgYnVzPTAsIHNsb3Q9 MCwgZnVuYz0wCgljbGFzcz0wNS0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9 MHgwMDA2LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+ CXZlbmRvcj0weDEwZGUsIGRldj0weDAzZTAsIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMGYsIHN0YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDNlYiwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTEsIGZ1bmM9MQoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1hLCBpcnE9NwoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZjMDAsIHNpemUg IDYsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZmMwMC0weGZjM2YpIGZvciBy aWQgMTAgb2YgcGNpMDowOjE6MQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHgxYzAwLCBzaXplICA2LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDFj MDAtMHgxYzNmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoxOjEKCW1hcFsyNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4MWM0MCwgc2l6ZSAgNiwgZW5hYmxlZApwY2liMDogYWxsb2Nh dGVkIHR5cGUgNCAoMHgxYzQwLTB4MWM3ZikgZm9yIHJpZCAyNCBvZiBwY2kwOjA6MToxCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQSAoc3JjIFwxMzRfU0JfLlBDSTAuQVBDUzowKQpw Y2lfbGluazMyOiBQaWNrZWQgSVJRIDIyIHdpdGggd2VpZ2h0IDAKcGNpYjA6IHNsb3QgMSBJTlRB IHJvdXRlZCB0byBpcnEgMjIgdmlhIFwxMzRfU0JfLlBDSTAuQVBDUwpmb3VuZC0+CXZlbmRvcj0w eDEwZGUsIGRldj0weDAzZjUsIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBm dW5jPTIKCWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDA0 MDAsIHN0YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVu ZG9yPTB4MTBkZSwgZGV2PTB4MDNmMSwgcmV2aWQ9MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTIsIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVn PTB4MDAwNywgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglp bnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJl bnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlMDJmMDAwLCBz aXplIDEyLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZlMDJmMDAwLTB4ZmUw MmZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjI6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4yLklOVEEgKHNyYyBcMTM0X1NCXy5QQ0kwLkFQQ0Y6MCkKcGNpX2xpbmsyODogUGlja2VkIElS USAyMyB3aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDIgSU5UQSByb3V0ZWQgdG8gaXJxIDIzIHZp YSBcMTM0X1NCXy5QQ0kwLkFQQ0YKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwM2YyLCBy ZXZpZD0weGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFzcz0wYy0wMy0y MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDBiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAo NzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1iLCBpcnE9MTEKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1v cnksIHJhbmdlIDMyLCBiYXNlIDB4ZmUwMmUwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4ZmUwMmUwMDAtMHhmZTAyZTBmZikgZm9yIHJpZCAxMCBvZiBwY2kw OjA6MjoxCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQiAoc3JjIFwxMzRfU0JfLlBD STAuQVBDTDowKQpwY2lfbGluazMzOiBQaWNrZWQgSVJRIDIyIHdpdGggd2VpZ2h0IDEKcGNpYjA6 IHNsb3QgMiBJTlRCIHJvdXRlZCB0byBpcnEgMjIgdmlhIFwxMzRfU0JfLlBDSTAuQVBDTApmb3Vu ZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzZjMsIHJldmlkPTB4YTEKCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD00LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAK CWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDIgKDUw MCBucykKCXNlY2J1cz0xLCBzdWJidXM9MQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAz ZjAsIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD01LCBmdW5jPTAKCWNsYXNzPTA0 LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgw MGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNSAoMTI1MCBucykKCWludHBpbj1iLCBpcnE9MTAKCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVz c2FnZSwgNjQgYml0LCB2ZWN0b3IgbWFza3MKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGZlMDI0MDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGZlMDI0MDAwLTB4ZmUwMjdmZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjU6MApwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC41LklOVEIgKHNyYyBcMTM0X1NCXy5QQ0kwLkFBWkE6MCkK cGNpX2xpbmszMTogUGlja2VkIElSUSAyMyB3aXRoIHdlaWdodCAxCnBjaWIwOiBzbG90IDUgSU5U QiByb3V0ZWQgdG8gaXJxIDIzIHZpYSBcMTM0X1NCXy5QQ0kwLkFBWkEKZm91bmQtPgl2ZW5kb3I9 MHgxMGRlLCBkZXY9MHgwM2VmLCByZXZpZD0weGEyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9Nywg ZnVuYz0wCgljbGFzcz0wNi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMSAoMjUwIG5zKSwgbWF4bGF0PTB4MTQgKDUwMDAgbnMpCglpbnRw aW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MAoJTVNJIHN1cHBvcnRzIDggbWVzc2FnZXMsIDY0IGJpdCwgdmVjdG9yIG1hc2tzCgltYXBbMTBd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZTAyZDAwMCwgc2l6ZSAxMiwgZW5hYmxl ZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhmZTAyZDAwMC0weGZlMDJkZmZmKSBmb3Igcmlk IDEwIG9mIHBjaTA6MDo3OjAKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4ZjAwMCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmMDAw LTB4ZjAwNykgZm9yIHJpZCAxNCBvZiBwY2kwOjA6NzowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjcuSU5UQSAoc3JjIFwxMzRfU0JfLlBDSTAuQVBDSDowKQpwY2lfbGluazI5OiBQaWNrZWQg SVJRIDIyIHdpdGggd2VpZ2h0IDIKcGNpYjA6IHNsb3QgNyBJTlRBIHJvdXRlZCB0byBpcnEgMjIg dmlhIFwxMzRfU0JfLlBDSTAuQVBDSApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzZjYs IHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD04LCBmdW5jPTAKCWNsYXNzPTAxLTAx LTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAz ICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdl cywgNjQgYml0CgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDlmMCwg c2l6ZSAgMywgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg5ZjAtMHg5ZjcpIGZv ciByaWQgMTAgb2YgcGNpMDowOjg6MAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHhiZjAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4 YmYwLTB4YmYzKSBmb3IgcmlkIDE0IG9mIHBjaTA6MDo4OjAKCW1hcFsxOF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4OTcwLCBzaXplICAzLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweDk3MC0weDk3NykgZm9yIHJpZCAxOCBvZiBwY2kwOjA6ODowCgltYXBbMWNd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGI3MCwgc2l6ZSAgMiwgZW5hYmxlZApw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhiNzAtMHhiNzMpIGZvciByaWQgMWMgb2YgcGNpMDow Ojg6MAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkYzAwLCBzaXpl ICA0LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGRjMDAtMHhkYzBmKSBmb3Ig cmlkIDIwIG9mIHBjaTA6MDo4OjAKCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGZlMDJjMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGZlMDJjMDAwLTB4ZmUwMmNmZmYpIGZvciByaWQgMjQgb2YgcGNpMDowOjg6MApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC44LklOVEEgKHNyYyBcMTM0X1NCXy5QQ0kwLkFQU0k6MCkKcGNpX2xp bmszNjogUGlja2VkIElSUSAyMCB3aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDggSU5UQSByb3V0 ZWQgdG8gaXJxIDIwIHZpYSBcMTM0X1NCXy5QQ0kwLkFQU0kKZm91bmQtPgl2ZW5kb3I9MHgxMGRl LCBkZXY9MHgwM2Y2LCByZXZpZD0weGEyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9OCwgZnVuYz0x CgljbGFzcz0wMS0wMS04NSwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBz dGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1iLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBv cnRzIDQgbWVzc2FnZXMsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHg5ZTAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4 OWUwLTB4OWU3KSBmb3IgcmlkIDEwIG9mIHBjaTA6MDo4OjEKCW1hcFsxNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4YmUwLCBzaXplICAyLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweGJlMC0weGJlMykgZm9yIHJpZCAxNCBvZiBwY2kwOjA6ODoxCgltYXBbMThd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDk2MCwgc2l6ZSAgMywgZW5hYmxlZApw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg5NjAtMHg5NjcpIGZvciByaWQgMTggb2YgcGNpMDow Ojg6MQoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhiNjAsIHNpemUg IDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YjYwLTB4YjYzKSBmb3Igcmlk IDFjIG9mIHBjaTA6MDo4OjEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4YzgwMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhjODAw LTB4YzgwZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6ODoxCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgMzIsIGJhc2UgMHhmZTAyYjAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhmZTAyYjAwMC0weGZlMDJiZmZmKSBmb3IgcmlkIDI0IG9mIHBjaTA6MDo4 OjEKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuOC5JTlRCIChzcmMgXDEzNF9TQl8uUENJMC5B UFNKOjApCnBjaV9saW5rMzc6IFBpY2tlZCBJUlEgMjEgd2l0aCB3ZWlnaHQgMApwY2liMDogc2xv dCA4IElOVEIgcm91dGVkIHRvIGlycSAyMSB2aWEgXDEzNF9TQl8uUENJMC5BUFNKCmZvdW5kLT4J dmVuZG9yPTB4MTBkZSwgZGV2PTB4MDNlOCwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTksIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MTggKDYwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIg bWVzc2FnZXMsIDY0IGJpdAoJc2VjYnVzPTIsIHN1YmJ1cz0yCmZvdW5kLT4JdmVuZG9yPTB4MTBk ZSwgZGV2PTB4MDNlOSwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTExLCBmdW5j PTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCA2 NCBiaXQKCXNlY2J1cz0zLCBzdWJidXM9Mwpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAz ZTksIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xMiwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CglzZWNi dXM9NCwgc3ViYnVzPTQKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAwLCByZXZpZD0w eDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAxLCBy ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MQoJY2xhc3M9MDYtMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgx MTAyLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MgoJY2xhc3M9 MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w eDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBk ZXY9MHgxMTAzLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwoJ Y2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpMDogPG1lbW9yeSwgUkFN PiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlk Z2U+IGF0IGRldmljZSAxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpMDog PHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBj aTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDEuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpvaGNp MDogPG5WaWRpYSBuRm9yY2UgTUNQNjEgVVNCIENvbnRyb2xsZXI+IG1lbSAweGZlMDJmMDAwLTB4 ZmUwMmZmZmYgaXJxIDIzIGF0IGRldmljZSAyLjAgb24gcGNpMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAyMyAoUENJIElSUSAyMykgdG8gbGFwaWMgMCB2ZWN0b3IgNTEKdXNidXMwIG9uIG9oY2kw Cm9oY2kwOiB1c2JwZjogQXR0YWNoZWQKZWhjaTA6IDxOVklESUEgbkZvcmNlIE1DUDYxIFVTQiAy LjAgY29udHJvbGxlcj4gbWVtIDB4ZmUwMmUwMDAtMHhmZTAyZTBmZiBpcnEgMjIgYXQgZGV2aWNl IDIuMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIyIChQQ0kgSVJRIDIyKSB0byBs YXBpYyAwIHZlY3RvciA1MgplaGNpMDogRG9vcmJlbGwgd29ya2Fyb3VuZCBlbmFibGVkCnVzYnVz MTogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czEgb24gZWhjaTAKZWhjaTA6IHVzYnBmOiBBdHRhY2hl ZApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMApwY2li MTogYWxsb2NhdGluZyBub24tSVNBIHJhbmdlIDB4YjAwMC0weGIwZmYKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDQgKDB4YjAwMC0weGIwZmYpIGZvciByaWQgMWMgb2YgcGNpYjEKcGNpYjE6IGFsbG9j YXRpbmcgbm9uLUlTQSByYW5nZSAweGI0MDAtMHhiNGZmCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0 ICgweGI0MDAtMHhiNGZmKSBmb3IgcmlkIDFjIG9mIHBjaWIxCnBjaWIxOiBhbGxvY2F0aW5nIG5v bi1JU0EgcmFuZ2UgMHhiODAwLTB4YjhmZgpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhiODAw LTB4YjhmZikgZm9yIHJpZCAxYyBvZiBwY2liMQpwY2liMTogYWxsb2NhdGluZyBub24tSVNBIHJh bmdlIDB4YmMwMC0weGJjZmYKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YmMwMC0weGJjZmYp IGZvciByaWQgMWMgb2YgcGNpYjEKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmRlMDAwMDAt MHhmZGVmZmZmZikgZm9yIHJpZCAyMCBvZiBwY2liMQpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhmZGQwMDAwMC0weGZkZGZmZmZmKSBmb3IgcmlkIDI0IG9mIHBjaWIxCnBjaWIxOiAgIGRvbWFp biAgICAgICAgICAgIDAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJv cmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4YjAwMC0weGJmZmYK cGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmZGUwMDAwMC0weGZkZWZmZmZmCnBjaWIxOiAg IHByZWZldGNoZWQgZGVjb2RlIDB4ZmRkMDAwMDAtMHhmZGRmZmZmZgpwY2liMTogICBzcGVjaWFs IGRlY29kZSAgICBJU0EsIHN1YnRyYWN0aXZlCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIx CnBjaWIxOiBhbGxvY2F0ZWQgYnVzIHJhbmdlICgxLTEpIGZvciByaWQgMCBvZiBwY2kxCnBjaTE6 IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZlbmRvcj0weDEwZWMsIGRldj0weDgw MjksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MSwgc2xvdD0xMCwgZnVuYz0wCgljbGFzcz0w Mi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4 MDIwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03CgltYXBbMTBd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGJjMDAsIHNpemUgIDUsIGVuYWJsZWQK cGNpYjE6IGFsbG9jYXRlZCBJL08gcG9ydCByYW5nZSAoMHhiYzAwLTB4YmMxZikgZm9yIHJpZCAx MCBvZiBwY2kwOjE6MTA6MApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4xMC5JTlRBIChzcmMg XDEzNF9TQl8uUENJMC5BUEMzOjApCnBjaV9saW5rMjE6IFBpY2tlZCBJUlEgMTggd2l0aCB3ZWln aHQgMApwY2liMTogc2xvdCAxMCBJTlRBIHJvdXRlZCB0byBpcnEgMTggdmlhIFwxMzRfU0JfLlBD STAuQVBDMwpwY2kxOiA8bmV0d29yaywgZXRoZXJuZXQ+IGF0IGRldmljZSAxMC4wIChubyBkcml2 ZXIgYXR0YWNoZWQpCmhkYWMwOiA8TlZJRElBIE1DUDYxIEhEQSBDb250cm9sbGVyPiBtZW0gMHhm ZTAyNDAwMC0weGZlMDI3ZmZmIGlycSAyMyBhdCBkZXZpY2UgNS4wIG9uIHBjaTAKaGRhYzA6IFBD SSBjYXJkIHZlbmRvcjogMHgxMDNjLCBkZXZpY2U6IDB4MmE3MgpoZGFjMDogSERBIERyaXZlciBS ZXZpc2lvbjogMjAxMjAxMjZfMDAwMgpoZGFjMDogQ29uZmlnIG9wdGlvbnM6IG9uPTB4MDAwMDAw MDAgb2ZmPTB4MDAwMDAwMDAKaGRhYzA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVj dG9ycyAoMSBzdXBwb3J0ZWQpCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElD IDAgdmVjdG9yIDUzCmhkYWMwOiB1c2luZyBJUlEgMjU2IGZvciBNU0kKaGRhYzA6IENhcHM6IE9T UyA0LCBJU1MgNCwgQlNTIDAsIE5TRE8gMSwgNjRiaXQsIENPUkIgMjU2LCBSSVJCIDI1NgpuZmUw OiA8TlZJRElBIG5Gb3JjZSBNQ1A2MSBOZXR3b3JraW5nIEFkYXB0ZXI+IHBvcnQgMHhmMDAwLTB4 ZjAwNyBtZW0gMHhmZTAyZDAwMC0weGZlMDJkZmZmIGlycSAyMiBhdCBkZXZpY2UgNy4wIG9uIHBj aTAKbmZlMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSA4IE1TSSB2ZWN0b3JzICg4IHN1cHBvcnRl ZCkKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTYKbXNp OiByb3V0aW5nIE1TSSBJUlEgMjU4IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTcKbXNpOiByb3V0 aW5nIE1TSSBJUlEgMjU5IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTgKbXNpOiByb3V0aW5nIE1T SSBJUlEgMjYwIHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTkKbXNpOiByb3V0aW5nIE1TSSBJUlEg MjYxIHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNjAKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYyIHRv IGxvY2FsIEFQSUMgMCB2ZWN0b3IgNjEKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjYzIHRvIGxvY2Fs IEFQSUMgMCB2ZWN0b3IgNjIKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjY0IHRvIGxvY2FsIEFQSUMg MCB2ZWN0b3IgNjMKbmZlMDogdXNpbmcgSVJRcyAyNTctMjY0IGZvciBNU0kKbmZlMDogVXNpbmcg OCBNU0kgbWVzc2FnZXMKbWlpYnVzMDogPE1JSSBidXM+IG9uIG5mZTAKcmdlcGh5MDogPFJUTDgx NjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1 czAKcmdlcGh5MDogT1VJIDB4MDBlMDRjLCBtb2RlbCAweDAwMTEsIHJldi4gMgpyZ2VwaHkwOiAg bm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwYmFzZVQtRkRYLWZsb3csIDEwMGJhc2VUWCwg MTAwYmFzZVRYLUZEWCwgMTAwYmFzZVRYLUZEWC1mbG93LCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1t YXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCAxMDAwYmFzZVQtRkRY LWZsb3csIDEwMDBiYXNlVC1GRFgtZmxvdy1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpuZmUwOiBi cGYgYXR0YWNoZWQKbmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjQ6ODE6Y2U6YmE6ODcKYXRh cGNpMDogPG5WaWRpYSBuRm9yY2UgTUNQNjEgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4OWYw LTB4OWY3LDB4YmYwLTB4YmYzLDB4OTcwLTB4OTc3LDB4YjcwLTB4YjczLDB4ZGMwMC0weGRjMGYg bWVtIDB4ZmUwMmMwMDAtMHhmZTAyY2ZmZiBpcnEgMjAgYXQgZGV2aWNlIDguMCBvbiBwY2kwCmlv YXBpYzA6IHJvdXRpbmcgaW50cGluIDIwIChQQ0kgSVJRIDIwKSB0byBsYXBpYyAwIHZlY3RvciA1 NAphdGEyOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwCmF0YTM6IDxBVEEg Y2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTAKYXRhcGNpMTogPG5WaWRpYSBuRm9yY2Ug TUNQNjEgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4OWUwLTB4OWU3LDB4YmUwLTB4YmUzLDB4 OTYwLTB4OTY3LDB4YjYwLTB4YjYzLDB4YzgwMC0weGM4MGYgbWVtIDB4ZmUwMmIwMDAtMHhmZTAy YmZmZiBpcnEgMjEgYXQgZGV2aWNlIDguMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDIxIChQQ0kgSVJRIDIxKSB0byBsYXBpYyAwIHZlY3RvciA1NQphdGE0OiA8QVRBIGNoYW5uZWw+ IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kxCmF0YTU6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAx IG9uIGF0YXBjaTEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOS4wIG9u IHBjaTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YTAwMC0weGFmZmYpIGZvciByaWQgMWMg b2YgcGNpYjIKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmEwMDAwMDAtMHhmY2ZmZmZmZikg Zm9yIHJpZCAyMCBvZiBwY2liMgpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMDAwMDAwMC0w eGVmZmZmZmZmKSBmb3IgcmlkIDI0IG9mIHBjaWIyCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAg IDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMg ICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4YTAwMC0weGFmZmYKcGNpYjI6ICAgbWVt b3J5IGRlY29kZSAgICAgMHhmYTAwMDAwMC0weGZjZmZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQg ZGVjb2RlIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZgpwY2liMjogICBzcGVjaWFsIGRlY29kZSAgICBW R0EKcGNpYjI6IGNvdWxkIG5vdCBnZXQgUENJIGludGVycnVwdCByb3V0aW5nIHRhYmxlIGZvciBc MTM0X1NCXy5QQ0kwLlhWUjAgLSBBRV9OT1RfRk9VTkQKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjIKcGNpYjI6IGFsbG9jYXRlZCBidXMgcmFuZ2UgKDItMikgZm9yIHJpZCAwIG9mIHBjaTIK cGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2 PTB4MDFkMywgcmV2aWQ9MHhhMQoJZG9tYWluPTAsIGJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJY2xh c3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVz c2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYTAw MDAwMCwgc2l6ZSAyNCwgZW5hYmxlZApwY2liMjogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhm YTAwMDAwMC0weGZhZmZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MjowOjAKCW1hcFsxNF06IHR5 cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhlMDAwMDAwMCwgc2l6ZSAy OCwgZW5hYmxlZApwY2liMjogYWxsb2NhdGVkIHByZWZldGNoIHJhbmdlICgweGUwMDAwMDAwLTB4 ZWZmZmZmZmYpIGZvciByaWQgMTQgb2YgcGNpMDoyOjA6MAoJbWFwWzFjXTogdHlwZSBNZW1vcnks IHJhbmdlIDY0LCBiYXNlIDB4ZmIwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjI6IGFsbG9j YXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZmIwMDAwMDAtMHhmYmZmZmZmZikgZm9yIHJpZCAxYyBvZiBw Y2kwOjI6MDowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjkuSU5UQSAoc3JjIFwxMzRfU0Jf LlBDSTAuQVBDODowKQpwY2lfbGluazI2OiBQaWNrZWQgSVJRIDE2IHdpdGggd2VpZ2h0IDAKcGNp YjA6IHNsb3QgOSBJTlRBIHJvdXRlZCB0byBpcnEgMTYgdmlhIFwxMzRfU0JfLlBDSTAuQVBDOApw Y2liMjogc2xvdCAwIElOVEEgaXMgcm91dGVkIHRvIGlycSAxNgp2Z2FwY2kwOiA8VkdBLWNvbXBh dGlibGUgZGlzcGxheT4gbWVtIDB4ZmEwMDAwMDAtMHhmYWZmZmZmZiwweGUwMDAwMDAwLTB4ZWZm ZmZmZmYsMHhmYjAwMDAwMC0weGZiZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIK dmdhcGNpMDogQm9vdCB2aWRlbyBkZXZpY2UKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMTEuMCBvbiBwY2kwCnBjaWIzOiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHg5 MDAwLTB4OTBmZgpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg5MDAwLTB4OTBmZikgZm9yIHJp ZCAxYyBvZiBwY2liMwpwY2liMzogYWxsb2NhdGluZyBub24tSVNBIHJhbmdlIDB4OTQwMC0weDk0 ZmYKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4OTQwMC0weDk0ZmYpIGZvciByaWQgMWMgb2Yg cGNpYjMKcGNpYjM6IGFsbG9jYXRpbmcgbm9uLUlTQSByYW5nZSAweDk4MDAtMHg5OGZmCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSA0ICgweDk4MDAtMHg5OGZmKSBmb3IgcmlkIDFjIG9mIHBjaWIzCnBj aWIzOiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHg5YzAwLTB4OWNmZgpwY2liMDogYWxsb2Nh dGVkIHR5cGUgNCAoMHg5YzAwLTB4OWNmZikgZm9yIHJpZCAxYyBvZiBwY2liMwpwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhmZGMwMDAwMC0weGZkY2ZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWIz CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZkYjAwMDAwLTB4ZmRiZmZmZmYpIGZvciByaWQg MjQgb2YgcGNpYjMKcGNpYjM6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMzogICBzZWNvbmRh cnkgYnVzICAgICAzCnBjaWIzOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDMKcGNpYjM6ICAgSS9PIGRl Y29kZSAgICAgICAgMHg5MDAwLTB4OWZmZgpwY2liMzogICBtZW1vcnkgZGVjb2RlICAgICAweGZk YzAwMDAwLTB4ZmRjZmZmZmYKcGNpYjM6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZGIwMDAwMC0w eGZkYmZmZmZmCnBjaWIzOiAgIHNwZWNpYWwgZGVjb2RlICAgIElTQQpwY2liMzogY291bGQgbm90 IGdldCBQQ0kgaW50ZXJydXB0IHJvdXRpbmcgdGFibGUgZm9yIFwxMzRfU0JfLlBDSTAuWFZSMSAt IEFFX05PVF9GT1VORApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liMzogYWxsb2Nh dGVkIGJ1cyByYW5nZSAoMy0zKSBmb3IgcmlkIDAgb2YgcGNpMwpwY2kzOiBkb21haW49MCwgcGh5 c2ljYWwgYnVzPTMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIuMCBv biBwY2kwCnBjaWI0OiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHg4MDAwLTB4ODBmZgpwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHg4MDAwLTB4ODBmZikgZm9yIHJpZCAxYyBvZiBwY2liNApw Y2liNDogYWxsb2NhdGluZyBub24tSVNBIHJhbmdlIDB4ODQwMC0weDg0ZmYKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDQgKDB4ODQwMC0weDg0ZmYpIGZvciByaWQgMWMgb2YgcGNpYjQKcGNpYjQ6IGFs bG9jYXRpbmcgbm9uLUlTQSByYW5nZSAweDg4MDAtMHg4OGZmCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSA0ICgweDg4MDAtMHg4OGZmKSBmb3IgcmlkIDFjIG9mIHBjaWI0CnBjaWI0OiBhbGxvY2F0aW5n IG5vbi1JU0EgcmFuZ2UgMHg4YzAwLTB4OGNmZgpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg4 YzAwLTB4OGNmZikgZm9yIHJpZCAxYyBvZiBwY2liNApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhmZGEwMDAwMC0weGZkYWZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWI0CnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGZkOTAwMDAwLTB4ZmQ5ZmZmZmYpIGZvciByaWQgMjQgb2YgcGNpYjQKcGNp YjQ6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBj aWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHg4 MDAwLTB4OGZmZgpwY2liNDogICBtZW1vcnkgZGVjb2RlICAgICAweGZkYTAwMDAwLTB4ZmRhZmZm ZmYKcGNpYjQ6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZDkwMDAwMC0weGZkOWZmZmZmCnBjaWI0 OiAgIHNwZWNpYWwgZGVjb2RlICAgIElTQQpwY2liNDogY291bGQgbm90IGdldCBQQ0kgaW50ZXJy dXB0IHJvdXRpbmcgdGFibGUgZm9yIFwxMzRfU0JfLlBDSTAuWFZSMiAtIEFFX05PVF9GT1VORApw Y2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2liNDogYWxsb2NhdGVkIGJ1cyByYW5nZSAo NC00KSBmb3IgcmlkIDAgb2YgcGNpNApwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTQKYWNw aV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCnBzbWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0 PiBpcnEgMTIgb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g cG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAx IG9uIGF0a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0 ZSAwMDQ3CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6 IGF0a2JkMCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNjQKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ3CnBzbTA6 IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAx MiAoSVNBIElSUSAxMikgdG8gbGFwaWMgMCB2ZWN0b3IgNjUKcHNtMDogW0dJQU5ULUxPQ0tFRF0K cHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxvcmVyLCBkZXZpY2UgSUQgNC0wMCwgNSBidXR0 b25zCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjQK cHNtMDogc3luY21hc2s6MDgsIHN5bmNiaXRzOjAwCmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGZm ZmZmZTAwMDAyMWQwMDAgcGEgMHg5MDAwMAphaGNfaXNhX2lkZW50aWZ5IDA6IGlvcG9ydCAweGMw MCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxOiBpb3BvcnQgMHgxYzAwIGFsbG9jIGZh aWxlZAphaGNfaXNhX2lkZW50aWZ5IDI6IGlvcG9ydCAweDJjMDAgYWxsb2MgZmFpbGVkCmFoY19p c2FfaWRlbnRpZnkgMzogaW9wb3J0IDB4M2MwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlm eSA0OiBpb3BvcnQgMHg0YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDU6IGlvcG9y dCAweDVjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgNjogaW9wb3J0IDB4NmMwMCBh bGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSA3OiBpb3BvcnQgMHg3YzAwIGFsbG9jIGZhaWxl ZAphaGNfaXNhX2lkZW50aWZ5IDg6IGlvcG9ydCAweDhjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2Ff aWRlbnRpZnkgOTogaW9wb3J0IDB4OWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAx MDogaW9wb3J0IDB4YWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMTogaW9wb3J0 IDB4YmMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMjogaW9wb3J0IDB4Y2MwMCBh bGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAxMzogaW9wb3J0IDB4ZGMwMCBhbGxvYyBmYWls ZWQKYWhjX2lzYV9pZGVudGlmeSAxNDogaW9wb3J0IDB4ZWMwMCBhbGxvYyBmYWlsZWQKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTAwMDAtMHhhMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTA4MDAtMHhhMGZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTEwMDAtMHhhMTdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTE4MDAtMHhhMWZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTIwMDAtMHhhMjdmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTI4MDAtMHhhMmZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTMwMDAtMHhhMzdmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTM4MDAtMHhhM2ZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQwMDAtMHhhNDdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQ4MDAtMHhh NGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTUwMDAt MHhhNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTU4 MDAtMHhhNWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YTYwMDAtMHhhNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YTY4MDAtMHhhNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YTcwMDAtMHhhNzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YTc4MDAtMHhhN2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YTgwMDAtMHhhODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YTg4MDAtMHhhOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YTkwMDAtMHhhOTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTk4MDAtMHhhOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWEwMDAtMHhhYTdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWE4MDAtMHhhYWZmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWIwMDAtMHhhYjdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWI4MDAtMHhhYmZmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWMwMDAtMHhhYzdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWM4MDAtMHhhY2ZmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQwMDAtMHhhZDdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQ4MDAtMHhhZGZm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWUwMDAtMHhh ZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWU4MDAt MHhhZWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWYw MDAtMHhhZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YWY4MDAtMHhhZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YjAwMDAtMHhiMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YjA4MDAtMHhiMGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YjEwMDAtMHhiMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YjE4MDAtMHhiMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YjIwMDAtMHhiMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YjI4MDAtMHhiMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjMwMDAtMHhiMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjM4MDAtMHhiM2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjQwMDAtMHhiNDdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjQ4MDAtMHhiNGZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjUwMDAtMHhiNTdmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjU4MDAtMHhiNWZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjYwMDAtMHhiNjdmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjY4MDAtMHhiNmZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjcwMDAtMHhiNzdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjc4MDAtMHhi N2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjgwMDAt MHhiODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjg4 MDAtMHhiOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YjkwMDAtMHhiOTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4Yjk4MDAtMHhiOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YmEwMDAtMHhiYTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YmE4MDAtMHhiYWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YmIwMDAtMHhiYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YmI4MDAtMHhiYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YmMwMDAtMHhiYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmM4MDAtMHhiY2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmQwMDAtMHhiZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmQ4MDAtMHhiZGZmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmUwMDAtMHhiZTdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmU4MDAtMHhiZWZmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmYwMDAtMHhiZjdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmY4MDAtMHhiZmZmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzAwMDAtMHhjMDdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzA4MDAtMHhjMGZm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzEwMDAtMHhj MTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzE4MDAt MHhjMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzIw MDAtMHhjMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YzI4MDAtMHhjMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YzMwMDAtMHhjMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YzM4MDAtMHhjM2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YzQwMDAtMHhjNDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YzQ4MDAtMHhjNGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YzUwMDAtMHhjNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YzU4MDAtMHhjNWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzYwMDAtMHhjNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzY4MDAtMHhjNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzcwMDAtMHhjNzdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzc4MDAtMHhjN2ZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzgwMDAtMHhjODdmZikgZm9yIHJpZCAw IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzg4MDAtMHhjOGZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzkwMDAtMHhjOTdmZikgZm9y IHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzk4MDAtMHhjOWZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2EwMDAtMHhjYTdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2E4MDAtMHhj YWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2IwMDAt MHhjYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2I4 MDAtMHhjYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 Y2MwMDAtMHhjYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4Y2M4MDAtMHhjY2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4Y2QwMDAtMHhjZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4Y2Q4MDAtMHhjZGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4Y2UwMDAtMHhjZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4Y2U4MDAtMHhjZWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4Y2YwMDAtMHhjZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2Y4MDAtMHhjZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDAwMDAtMHhkMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDAwMDAtMHhkMTdmZikgZm9yIHJpZCAwIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDE4MDAtMHhkMWZmZikgZm9yIHJpZCAxIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDIwMDAtMHhkMjdmZikgZm9yIHJpZCAx IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDI4MDAtMHhkMmZmZikgZm9yIHJp ZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDMwMDAtMHhkMzdmZikgZm9y IHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDM4MDAtMHhkM2ZmZikg Zm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQwMDAtMHhkNDdm ZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQ4MDAtMHhk NGZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDUwMDAt MHhkNTdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDU4 MDAtMHhkNWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 ZDYwMDAtMHhkNjdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDY4MDAtMHhkNmZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4ZDcwMDAtMHhkNzdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZDc4MDAtMHhkN2ZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4ZDgwMDAtMHhkODdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZDg4MDAtMHhkOGZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4ZDkwMDAtMHhkOTdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDk4MDAtMHhkOWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGEwMDAtMHhkYTdmZikgZm9yIHJpZCAxIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGE4MDAtMHhkYWZmZikgZm9yIHJpZCAxIG9mIG9y bTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGIwMDAtMHhkYjdmZikgZm9yIHJpZCAxIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGI4MDAtMHhkYmZmZikgZm9yIHJpZCAx IG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGMwMDAtMHhkYzdmZikgZm9yIHJp ZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGM4MDAtMHhkY2ZmZikgZm9y IHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGQwMDAtMHhkZDdmZikg Zm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGQ4MDAtMHhkZGZm ZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGUwMDAtMHhk ZTdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGU4MDAt MHhkZWZmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGYw MDAtMHhkZjdmZikgZm9yIHJpZCAxIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 ZGY4MDAtMHhkZmZmZikgZm9yIHJpZCAxIG9mIG9ybTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNh YmxpbmcgUG5QIGRldmljZXMKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu ZyBpdAphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHRpbWVyOiBh dHRpbWVyMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNl cwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkMTdmZiBvbiBpc2Ew CnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDEsIHRlcm1pbmFs IGVtdWxhdG9yOiBzY3Rla2VuICh0ZWtlbiB0ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZH QT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzYzAtMHgzZGYpIGZvciByaWQgMCBvZiB2Z2EwCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGEwMDAwLTB4YmZmZmYpIGZvciByaWQgMCBvZiB2Z2EwCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNmMC0weDNmNSkgZm9yIHJpZCAwIG9mIGZkYzAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2Y3LTB4M2Y3KSBmb3IgcmlkIDEgb2YgZmRjMApmZGMw IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9u IGlzYTAKcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKcHBjMCBmYWlsZWQgdG8g cHJvYmUgYXQgaXJxIDcgb24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjgtMHgz ZmYpIGZvciByaWQgMCBvZiB1YXJ0MAp1YXJ0MCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNm OC0weDNmZiBpcnEgNCBvbiBpc2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDJmOC0weDJm ZikgZm9yIHJpZCAwIG9mIHVhcnQxCnVhcnQxIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4 LTB4MmZmIGlycSAzIG9uIGlzYTAKd2J3ZDAgZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKaXNhX3By b2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnBvd2Vybm93MDogPFBvd2VyTm93ISBL OD4gb24gY3B1MApwb3dlcm5vdzE6IDxQb3dlck5vdyEgSzg+IG9uIGNwdTEKRGV2aWNlIGNvbmZp Z3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZy ZXF1ZW5jeSAxMDA0NTcwODUgSHoKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2 bGFuOiBpbml0aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwp0Y3BfaW5p dDogbmV0LmluZXQudGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMzI3NjgKbG8wOiBicGYg YXR0YWNoZWQKaHB0bnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdDI3eHg6IG5vIGNvbnRy b2xsZXIgZGV0ZWN0ZWQuCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpoZGFjYzA6IDxS ZWFsdGVrIEFMQzEyMDAgSERBIENPREVDPiBhdCBjYWQgMCBvbiBoZGFjMApoZGFhMDogPFJlYWx0 ZWsgQUxDMTIwMCBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MwCmhkYWEw OiBTdWJzeXN0ZW0gSUQ6IDB4MTAzYzJhNzIKaGRhYTA6IE51bUdQSU89MiBOdW1HUE89MCBOdW1H UEk9MCBHUElXYWtlPTAgR1BJVW5zb2w9MQpoZGFhMDogIEdQSU8wOiBkaXNhYmxlZApoZGFhMDog IEdQSU8xOiBkaXNhYmxlZApoZGFhMDogT3JpZ2luYWwgcGlucyBjb25maWd1cmF0aW9uOgpoZGFh MDogbmlkICAgMHggICAgYXMgc2VxIGRldmljZSAgICAgICBjb25uICBqYWNrICAgIGxvYyAgICAg ICAgY29sb3IgICBtaXNjCmhkYWEwOiAxNyA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5v bmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDIwIDAxMDE0MDEwIDEgIDAg IExpbmUtb3V0ICAgICAgSmFjayAgMS84ICAgICBSZWFyICAgICAgIEdyZWVuICAgMApoZGFhMDog MjEgOTkxMzAxMjAgMiAgMCAgU3BlYWtlciAgICAgICBGaXhlZCBBVEFQSSAgIE9uYm9hcmQgICAg VW5rbm93biAxCmhkYWEwOiAyMiAwMTgxMzA0ZiA0ICAxNSBMaW5lLWluICAgICAgIEphY2sgIDEv OCAgICAgUmVhciAgICAgICBCbHVlICAgIDAKaGRhYTA6IDIzIDQxMTExMWYwIDE1IDAgIFNwZWFr ZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMjQgMDFh MTk4NDAgNCAgMCAgTWljICAgICAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgUGluayAg ICA4CmhkYWEwOiAyNSAwMmExOTg0MiA0ICAyICBNaWMgICAgICAgICAgIEphY2sgIDEvOCAgICAg RnJvbnQgICAgICBQaW5rICAgIDgKaGRhYTA6IDI2IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAg ICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMjcgMDIyMTQwMWYg MSAgMTUgSGVhZHBob25lcyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgR3JlZW4gICAwCmhk YWEwOiAyOCA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAg ICAgICBCbGFjayAgIDEKaGRhYTA6IDI5IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9u ZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMzAgNDExMTExZjAgMTUgMCAg U3BlYWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxCmhkYWEwOiAz MSA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBC bGFjayAgIDEKaGRhYTA6IFBhdGNoaW5nIHdpZGdldCBjYXBzIG5pZD0yOSAweDAwNDAwMDAwIC0+ IDB4MDA3MDAwMDAKaGRhYTA6IFBhdGNoZWQgcGlucyBjb25maWd1cmF0aW9uOgpoZGFhMDogbmlk ICAgMHggICAgYXMgc2VxIGRldmljZSAgICAgICBjb25uICBqYWNrICAgIGxvYyAgICAgICAgY29s b3IgICBtaXNjCmhkYWEwOiAxNyA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEv OCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMjAgMDEwMTQwMTAgMSAgMCAg TGluZS1vdXQgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAwCmhkYWEwOiAy MSA5OTEzMDEyMCAyICAwICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2FyZCAgICBV bmtub3duIDEKaGRhYTA6IDIyIDAxODEzMDRmIDQgIDE1IExpbmUtaW4gICAgICAgSmFjayAgMS84 ICAgICBSZWFyICAgICAgIEJsdWUgICAgMApoZGFhMDogMjMgNDExMTExZjAgMTUgMCAgU3BlYWtl ciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxIERJU0EKaGRhYTA6IDI0 IDAxYTE5ODQwIDQgIDAgIE1pYyAgICAgICAgICAgSmFjayAgMS84ICAgICBSZWFyICAgICAgIFBp bmsgICAgOApoZGFhMDogMjUgMDJhMTk4NDIgNCAgMiAgTWljICAgICAgICAgICBKYWNrICAxLzgg ICAgIEZyb250ICAgICAgUGluayAgICA4CmhkYWEwOiAyNiA0MTExMTFmMCAxNSAwICBTcGVha2Vy ICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMjcg MDIyMTQwMWYgMSAgMTUgSGVhZHBob25lcyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgR3Jl ZW4gICAwCmhkYWEwOiAyOCA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAg ICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMzAgNDExMTExZjAgMTUgMCAgU3Bl YWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxIERJU0EKaGRhYTA6 IDMxIDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAg IEJsYWNrICAgMSBESVNBCmhkYWEwOiAzIGFzc29jaWF0aW9ucyBmb3VuZDoKaGRhYTA6IEFzc29j aWF0aW9uIDAgKDEpIG91dDoKaGRhYTA6ICBQaW4gbmlkPTIwIHNlcT0wCmhkYWEwOiAgUGluIG5p ZD0yNyBzZXE9MTUKaGRhYTA6IEFzc29jaWF0aW9uIDEgKDIpIG91dDoKaGRhYTA6ICBQaW4gbmlk PTIxIHNlcT0wCmhkYWEwOiBBc3NvY2lhdGlvbiAyICg0KSBpbjoKaGRhYTA6ICBQaW4gbmlkPTI0 IHNlcT0wCmhkYWEwOiAgUGluIG5pZD0yNSBzZXE9MgpoZGFhMDogIFBpbiBuaWQ9MjIgc2VxPTE1 CmhkYWEwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDAgKDEpCmhkYWEwOiAgUGluIDIwIHRyYWNlZCB0 byBEQUMgMgpoZGFhMDogIFBpbiAyNyB0cmFjZWQgdG8gREFDIDIgYW5kIGhwcmVkaXIgMApoZGFh MDogQXNzb2NpYXRpb24gMCAoMSkgdHJhY2Ugc3VjY2VlZGVkCmhkYWEwOiBUcmFjaW5nIGFzc29j aWF0aW9uIDEgKDIpCmhkYWEwOiAgUGluIDIxIHRyYWNlZCB0byBEQUMgMwpoZGFhMDogQXNzb2Np YXRpb24gMSAoMikgdHJhY2Ugc3VjY2VlZGVkCmhkYWEwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDIg KDQpCmhkYWEwOiAgUGluIDI0IHRyYWNlZCB0byBBREMgOApoZGFhMDogIFBpbiAyNSB0cmFjZWQg dG8gQURDIDgKaGRhYTA6ICBQaW4gMjIgdHJhY2VkIHRvIEFEQyA4CmhkYWEwOiBBc3NvY2lhdGlv biAyICg0KSB0cmFjZSBzdWNjZWVkZWQKaGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgREFD IGZvciBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMDogTG9va2luZyBmb3IgYWRkaXRpb25hbCBEQUMg Zm9yIGFzc29jaWF0aW9uIDEgKDIpCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIEFEQyBm b3IgYXNzb2NpYXRpb24gMiAoNCkKaGRhYTA6ICBBREMgOSBjb25zaWRlcmVkIGVxdWFsIHRvIEFE QyA4CmhkYWEwOiBUcmFjaW5nIGlucHV0IG1vbml0b3IKaGRhYTA6ICBUcmFjaW5nIG5pZCAxMSB0 byBvdXQKaGRhYTA6ICBuaWQgMTEgaXMgaW5wdXQgbW9uaXRvcgpoZGFhMDogIFRyYWNpbmcgbmlk IDM0IHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDM1IHRvIG91dApoZGFhMDogVHJhY2luZyBv dGhlciBpbnB1dCBtb25pdG9ycwpoZGFhMDogIFRyYWNpbmcgbmlkIDIyIHRvIG91dApoZGFhMDog IFRyYWNpbmcgbmlkIDI0IHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDI1IHRvIG91dApoZGFh MDogVHJhY2luZyBiZWVwZXIKaGRhYTA6IEhlYWRwaG9uZXMgcmVkaXJlY3Rpb24gZm9yIGFzc29j aWF0aW9uIDAgbmlkPTI3IHVzaW5nIHVuc29saWNpdGVkIHJlc3BvbnNlcy4KaGRhYTA6IFJlZGly ZWN0IG91dHB1dCB0bzogbWFpbgpoZGFhMDogRkcgY29uZmlnL3F1aXJrczogZm9yY2VzdGVyZW8g aXZyZWY1MCBpdnJlZjgwIGl2cmVmMTAwIGl2cmVmCnBjbTA6IDxSZWFsdGVrIEFMQzEyMDAgKEFu YWxvZyAyLjArSFAvMi4wKT4gYXQgbmlkIDIwLDI3IGFuZCAyNCwyNSwyMiBvbiBoZGFhMApwY20w OiBQbGF5YmFjazoKcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20wOiAg ICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAgMTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtI egpwY20wOiAgICAgICAgICAgICBEQUM6IDIKcGNtMDogCnBjbTA6ICAgICBuaWQ9MjAgW3Bpbjog TGluZS1vdXQgKEdyZWVuIEphY2spXQpwY20wOiAgICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4 ZXJdIFtzcmM6IHBjbSwgbWl4XQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8g b3V0cHV0XSBbc3JjOiBwY21dCnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8g bWl4ZXJdIFtzcmM6IG1peF0KcGNtMDogCnBjbTA6ICAgICBuaWQ9MjcgW3BpbjogSGVhZHBob25l cyAoR3JlZW4gSmFjayldCnBjbTA6ICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gW3Ny YzogcGNtLCBtaXhdCnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0yIFthdWRpbyBvdXRwdXRd IFtzcmM6IHBjbV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0g W3NyYzogbWl4XQpwY20wOiAKcGNtMDogUmVjb3JkOgpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4 MDAwMDAwMDEgUENNCnBjbTA6ICAgICAgICAgUENNIGNhcDogMHgwMDA2MDE2MCAxNiAyMCBiaXRz LCA0NCA0OCA5NiBLSHoKcGNtMDogICAgICAgICAgICAgQURDOiA4CnBjbTA6ICAgICAgICAgICAg IEFEQzogOQpwY20wOiAKcGNtMDogICAgIG5pZD04IFthdWRpbyBpbnB1dF0KcGNtMDogICAgICAg KyA8LSBuaWQ9MzUgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBtaWMsIG1peCwg bW9uaXRvcl0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBK YWNrKV0gW3NyYzogbWljXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWlj IChQaW5rIEphY2spXSBbc3JjOiBtb25pdG9yXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9 MjkgW2JlZXAgd2lkZ2V0XSBbc3JjOiBzcGVha2VyXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBu aWQ9MjIgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAgICAg ICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDog ICAgIG5pZD05IFthdWRpbyBpbnB1dF0KcGNtMDogICAgICAgKyA8LSBuaWQ9MzQgW2F1ZGlvIG1p eGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBtaWMsIG1peCwgbW9uaXRvcl0KcGNtMDogICAgICAg ICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWljXQpwY20w OiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWljIChQaW5rIEphY2spXSBbc3JjOiBt b25pdG9yXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0XSBbc3Jj OiBzcGVha2VyXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGluZS1pbiAo Qmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFth dWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogSW5wdXQgTWl4OgpwY20wOiAKcGNt MDogICAgIG5pZD0xMSBbYXVkaW8gbWl4ZXJdCnBjbTA6ICAgICAgICsgPC0gbmlkPTI0IFtwaW46 IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWljXQpwY20wOiAgICAgICArIDwtIG5pZD0yNSBbcGlu OiBNaWMgKFBpbmsgSmFjayldIFtzcmM6IG1vbml0b3JdCnBjbTA6ICAgICAgICsgPC0gbmlkPTI5 IFtiZWVwIHdpZGdldF0gW3NyYzogc3BlYWtlcl0KcGNtMDogICAgICAgKyA8LSBuaWQ9MjIgW3Bp bjogTGluZS1pbiAoQmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogCnBjbTA6IE1hc3RlciBW b2x1bWUgKE9TUzogdm9sKTogLTQ2LzBkQgpwY20wOiAgICArLSBjdGwgMTMgKG5pZCAgMTIgb3V0 KTogICAgLTQ2LzBkQiAoMzIgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAxNCAobmlkICAxMiBpbiAg IDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCAxNSAobmlkICAxMiBpbiAgIDEpOiBtdXRlCnBjbTA6 ICAgICstIGN0bCAyNSAobmlkICAyMCBpbiApOiAgICBtdXRlCnBjbTA6ICAgICstIGN0bCAzOSAo bmlkICAyNyBpbiApOiAgICBtdXRlCnBjbTA6IApwY20wOiBQQ00gVm9sdW1lIChPU1M6IHBjbSk6 IDAvMGRCCnBjbTA6ICAgICstIGN0bCAxNCAobmlkICAxMiBpbiAgIDApOiBtdXRlCnBjbTA6IApw Y20wOiBNaWNyb3Bob25lIFZvbHVtZSAoT1NTOiBtaWMpOiAwLzMwZEIKcGNtMDogICAgKy0gY3Rs ICAzIChuaWQgIDExIGluICAgMCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAg ICstIGN0bCAzNCAobmlkICAyNCBvdXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTA6ICAgICst IGN0bCA0MSAobmlkICAzNCBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MiAobmlkICAz NSBpbiAgIDApOiBtdXRlCnBjbTA6IApwY20wOiBNaWNyb3Bob25lMiBWb2x1bWUgKE9TUzogbW9u aXRvcik6IDAvMzBkQgpwY20wOiAgICArLSBjdGwgIDQgKG5pZCAgMTEgaW4gICAxKTogLTM0LzEy ZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDM2IChuaWQgIDI1IG91dCk6ICAg IDAvMzBkQiAoNCBzdGVwcykKcGNtMDogICAgKy0gY3RsIDQyIChuaWQgIDM0IGluICAgMSk6IG11 dGUKcGNtMDogICAgKy0gY3RsIDUzIChuaWQgIDM1IGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6 IExpbmUtaW4gVm9sdW1lIChPU1M6IGxpbmUpOiAwLzMwZEIKcGNtMDogICAgKy0gY3RsIDExIChu aWQgIDExIGluICAgOCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0 bCAzMCAobmlkICAyMiBvdXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTA6ICAgICstIGN0bCA0 OSAobmlkICAzNCBpbiAgIDgpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MCAobmlkICAzNSBpbiAg IDgpOiBtdXRlCnBjbTA6IApwY20wOiBTcGVha2VyL0JlZXAgVm9sdW1lIChPU1M6IHNwZWFrZXIp OiAtMzQvMTJkQgpwY20wOiAgICArLSBjdGwgIDggKG5pZCAgMTEgaW4gICA1KTogLTM0LzEyZEIg KDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDQ2IChuaWQgIDM0IGluICAgNSk6IG11 dGUKcGNtMDogICAgKy0gY3RsIDU3IChuaWQgIDM1IGluICAgNSk6IG11dGUKcGNtMDogCnBjbTA6 IFJlY29yZGluZyBMZXZlbCAoT1NTOiByZWMpOiAtMTYvMzBkQgpwY20wOiAgICArLSBjdGwgIDEg KG5pZCAgIDggaW4gICAwKTogLTE2LzMwZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0g Y3RsICAyIChuaWQgICA5IGluICAgMCk6IC0xNi8zMGRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6 ICAgICstIGN0bCA0MSAobmlkICAzNCBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA0MiAo bmlkICAzNCBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA0NiAobmlkICAzNCBpbiAgIDUp OiBtdXRlCnBjbTA6ICAgICstIGN0bCA0OSAobmlkICAzNCBpbiAgIDgpOiBtdXRlCnBjbTA6ICAg ICstIGN0bCA1MSAobmlkICAzNCBpbiAgMTApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MiAobmlk ICAzNSBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MyAobmlkICAzNSBpbiAgIDEpOiBt dXRlCnBjbTA6ICAgICstIGN0bCA1NyAobmlkICAzNSBpbiAgIDUpOiBtdXRlCnBjbTA6ICAgICst IGN0bCA2MCAobmlkICAzNSBpbiAgIDgpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MiAobmlkICAz NSBpbiAgMTApOiBtdXRlCnBjbTA6IApwY20wOiBJbnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KTog LTM0LzEyZEIKcGNtMDogICAgKy0gY3RsICAzIChuaWQgIDExIGluICAgMCk6IC0zNC8xMmRCICgz MiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAgNCAobmlkICAxMSBpbiAgIDEpOiAtMzQv MTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgIDggKG5pZCAgMTEgaW4gICA1 KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDEx IGluICAgOCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAxNSAo bmlkICAxMiBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCA1MSAobmlkICAzNCBpbiAgMTAp OiBtdXRlCnBjbTA6ICAgICstIGN0bCA2MiAobmlkICAzNSBpbiAgMTApOiBtdXRlCnBjbTA6IApw Y20wOiBJbnB1dCBNb25pdG9yaW5nIExldmVsIChPU1M6IGlnYWluKTogMC8wZEIKcGNtMDogICAg Ky0gY3RsIDE1IChuaWQgIDEyIGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6IE1peGVyICJ2b2wi OgpwY20wOiBNaXhlciAicGNtIjoKcGNtMDogTWl4ZXIgInNwZWFrZXIiOgpwY20wOiBNaXhlciAi bGluZSI6CnBjbTA6IE1peGVyICJtaWMiOgpwY20wOiBNaXhlciAibWl4IjoKcGNtMDogTWl4ZXIg InJlYyI6CnBjbTA6IE1peGVyICJpZ2FpbiI6CnBjbTA6IE1peGVyICJtb25pdG9yIjoKcGNtMDog U29mdCBQQ00gbWl4ZXIgRU5BQkxFRApwY20wOiBQbGF5YmFjayBjaGFubmVsIHNldCBpczogRnJv bnQgTGVmdCwgRnJvbnQgUmlnaHQsIApwY20wOiBQbGF5YmFjayBjaGFubmVsIG1hdHJpeCBpczog Mi4wIChkaXNjb25uZWN0ZWQpCnBjbTA6IFJlY29yZGluZyBjaGFubmVsIHNldCBpczogRnJvbnQg TGVmdCwgRnJvbnQgUmlnaHQsIApwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBtYXRyaXggaXM6IDIu MCAoZGlzY29ubmVjdGVkKQpwY20xOiA8UmVhbHRlayBBTEMxMjAwIChPbmJvYXJkIEFuYWxvZyBT cGVha2VyKT4gYXQgbmlkIDIxIG9uIGhkYWEwCnBjbTE6IFBsYXliYWNrOgpwY20xOiAgICAgIFN0 cmVhbSBjYXA6IDB4MDAwMDAwMDEgUENNCnBjbTE6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDU2 MCAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6CnBjbTE6ICAgICAgICAgICAgIERBQzog MwpwY20xOiAKcGNtMTogICAgIG5pZD0yMSBbcGluOiBTcGVha2VyIChGaXhlZCldCnBjbTE6ICAg ICAgICsgPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBjbTE6ICAgICAg ICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMTogICAgICAg ICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20xOiAKcGNtMTog TWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wpOiAtNDYvMGRCCnBjbTE6ICAgICstIGN0bCAxNiAobmlk ICAxMyBvdXQpOiAgICAtNDYvMGRCICgzMiBzdGVwcykKcGNtMTogICAgKy0gY3RsIDE3IChuaWQg IDEzIGluICAgMCk6IG11dGUKcGNtMTogICAgKy0gY3RsIDE4IChuaWQgIDEzIGluICAgMSk6IG11 dGUKcGNtMTogICAgKy0gY3RsIDI3IChuaWQgIDIxIGluICk6ICAgIG11dGUKcGNtMTogCnBjbTE6 IFBDTSBWb2x1bWUgKE9TUzogcGNtKTogMC8wZEIKcGNtMTogICAgKy0gY3RsIDE3IChuaWQgIDEz IGluICAgMCk6IG11dGUKcGNtMTogCnBjbTE6IElucHV0IE1peCBMZXZlbCAoT1NTOiBtaXgpCnBj bTE6ICAgICstIGN0bCAxOCAobmlkICAxMyBpbiAgIDEpOiBtdXRlCnBjbTE6IApwY20xOiBJbnB1 dCBNb25pdG9yaW5nIExldmVsIChPU1M6IGlnYWluKTogMC8wZEIKcGNtMTogICAgKy0gY3RsIDE4 IChuaWQgIDEzIGluICAgMSk6IG11dGUKcGNtMTogCnBjbTE6IE1peGVyICJ2b2wiOgpwY20xOiBN aXhlciAicGNtIjoKcGNtMTogTWl4ZXIgImlnYWluIjoKcGNtMTogU29mdCBQQ00gbWl4ZXIgRU5B QkxFRApwY20xOiBQbGF5YmFjayBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmln aHQsIApwY20xOiBQbGF5YmFjayBjaGFubmVsIG1hdHJpeCBpczogMi4wICh1bmtub3duKQp1c2J1 czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVk IFVTQiB2Mi4wCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRh MjogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMAp1Z2VuMC4xOiA8blZpZGlh PiBhdCB1c2J1czAKdWh1YjA6IDxuVmlkaWEgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8blZpZGlhPiBhdCB1c2J1czEK dWh1YjE6IDxuVmlkaWEgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMQphdGEyOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0w eDAwCmF0YTI6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGEzOiBT QVRBIGNvbm5lY3QgdGltZT0wbXMgc3RhdHVzPTAwMDAwMTEzCmF0YTM6IHJlc2V0IHRwMSBtYXNr PTAxIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMzogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgx NCBtc2I9MHhlYgphdGEzOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDEw MDAwCnVodWIwOiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmF0YTQ6 IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGE1OiBTQVRBIGNvbm5lY3Qg dGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYWRhMCBhdCBhdGEyIGJ1cyAwIHNjYnVzMCB0YXJnZXQg MCBsdW4gMAphZGEwOiA8U1QzMTYwMzE4QVMgSFAzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFk YTA6IFNlcmlhbCBOdW1iZXIgNVZZMFdSUkIKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChT QVRBIDIueCwgVURNQTUsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IDE1MjYyN01CICgzMTI1ODE4MDgg NTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMDogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ0CnBhc3MwIGF0IGF0YTIgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCnBh c3MwOiA8U1QzMTYwMzE4QVMgSFAzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCnBhc3MwOiBTZXJp YWwgTnVtYmVyIDVWWTBXUlJCCnBhc3MwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54 LCBVRE1BNSwgUElPIDgxOTJieXRlcykKcGFzczEgYXQgYXRhMyBidXMgMCBzY2J1czEgdGFyZ2V0 IDAgbHVuIDAKcGFzczE6IDxocCBDRERWRFcgVFMtSDY1M1IgMEUwMD4gUmVtb3ZhYmxlIENELVJP TSBTQ1NJLTAgZGV2aWNlIApwYXNzMTogU2VyaWFsIE51bWJlciBSMDYyNkdDU0EwMzcxNjAwCnBh c3MxOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRl cywgUElPIDgxOTJieXRlcykKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KTmV0dnNjIGluaXRp YWxpemluZy4uLiBkb25lIQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJ RDogMHgwMTAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MSAoY2QwIGF0IGF0YTMgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCklTQSBJUlEgMWNkMDog KSB0byBsYXBpYyAxIHZlY3RvciA0OAo8aHAgQ0REVkRXIFRTLUg2NTNSIDBFMDA+IFJlbW92YWJs ZSBDRC1ST00gU0NTSS0wIGRldmljZSAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIgKGNkMDog U2VyaWFsIE51bWJlciBSMDYyNkdDU0EwMzcxNjAwCklTQSBJUlEgMTJjZDA6IDE1MC4wMDBNQi9z IHRyYW5zZmVycykgdG8gbGFwaWMgMSB2ZWN0b3IgNDkKIChTQVRBIDEueCwgVURNQTUsIEFUQVBJ IDEyYnl0ZXMsIGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQSU8gODE5MmJ5dGVzUENJIElS USAyMSkpIHRvIGxhcGljIDEgdmVjdG9yIDUwCgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMyAo Y2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRp dW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZApQQ0kgSVJRIDIzKSB0byBsYXBpYyAxIHZlY3Rv ciA1MQptc2k6IEFzc2lnbmluZyBNU0kgSVJRIDI1NyB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDU2 Cm1zaTogQXNzaWduaW5nIE1TSSBJUlEgMjU4IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTcKbXNp OiBBc3NpZ25pbmcgTVNJIElSUSAyNTkgdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA1OAptc2k6IEFz c2lnbmluZyBNU0kgSVJRIDI2MCB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDU5Cm1zaTogQXNzaWdu aW5nIE1TSSBJUlEgMjYxIHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNjAKbXNpOiBBc3NpZ25pbmcg TVNJIElSUSAyNjIgdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA2MQptc2k6IEFzc2lnbmluZyBNU0kg SVJRIDI2MyB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDYyCm1zaTogQXNzaWduaW5nIE1TSSBJUlEg MjY0IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNjMKVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxv d2VyIDEgYml0KHMpClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTEwNTA1MDIzMSBI eiBxdWFsaXR5IC0xMDAKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJl ZHVjZWQgcGVyZm9ybWFuY2UuCkdFT006IG5ldyBkaXNrIGFkYTAKR0VPTTogbmV3IGRpc2sgY2Qw ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1 c2J1czEKdWh1YjE6IDEwIHBvcnRzIHdpdGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9v dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz MQp1Z2VuMS4yOiA8V2VzdGVybiBEaWdpdGFsPiBhdCB1c2J1czEKdW1hc3MwOiA8V2VzdGVybiBE aWdpdGFsIFVTQiBIYXJkIERyaXZlLCBjbGFzcyAwLzAsIHJldiAyLjAwLzExLjA1LCBhZGRyIDI+ IG9uIHVzYnVzMQp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDQxMDAK dW1hc3MwOjQ6MDogQXR0YWNoZWQgdG8gc2NidXM0ClRyeWluZyB0byBtb3VudCByb290IGZyb20g dWZzOi9kZXYvZ3B0L2dwcm9vdCBbcnddLi4uCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IERv d24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/CnBhc3MyIGF0IHVtYXNzLXNp bTAgYnVzIDAgc2NidXM0IHRhcmdldCAwIGx1biAwCnBhc3MyOiA8V0RDIFdEODAgMEJCLTAwQ0FB MSAxNy4wPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCnBhc3MyOiBTZXJpYWwg TnVtYmVyIDBCMDAwMTIyMDQ0Q0VCRTMKcGFzczI6IDQwLjAwME1CL3MgdHJhbnNmZXJzCkdFT006 IG5ldyBkaXNrIGRhMApkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCBzY2J1czQgdGFyZ2V0IDAgbHVu IDAKZGEwOiA8V0RDIFdEODAgMEJCLTAwQ0FBMSAxNy4wPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktMCBkZXZpY2UgCmRhMDogU2VyaWFsIE51bWJlciAwQjAwMDEyMjA0NENFQkUzCmRhMDogNDAu MDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiA3NjMxOU1CICgxNTYzMDE0ODggNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCA5NzI5QykKZGEwOiBxdWlya3M9MHgyPE5PXzZfQllURT4KZGEwOiBEZWxl dGUgbWV0aG9kczogPE5PTkUoKik+CnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0Cg== ----==8bc01cd88383431337ce92a572cfb537-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 17:12:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5704A509 for ; Wed, 25 Feb 2015 17:12:44 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 15CC47AD for ; Wed, 25 Feb 2015 17:12:43 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6B08197A66 for ; Wed, 25 Feb 2015 17:12:37 +0000 (UTC) Message-ID: <54EE028C.8070609@freebsd.org> Date: Wed, 25 Feb 2015 12:12:44 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> In-Reply-To: <20150225182201.216f6fee@nonamehost.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ldQCWS3tlVSomNQ5srnEd8RqSD9kRqT7p" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 17:12:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ldQCWS3tlVSomNQ5srnEd8RqSD9kRqT7p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-02-25 11:22, Ivan Klymenko wrote: > =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 > Glen Barber =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: >>> I have clean svn tree with base/head branch. I try to build world, >>> but I have some mysterious bugs. The latest is yacc failed to make >>> c file on phase 4.3: >>> >>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) >>> m4 -P >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compile= r >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler= /aslparser.y >>>> aslcompiler.y >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y >>> yacc: 89 shift/reduce conflicts. >>> yacc: f - maximum table size exceeded >>> *** Error code 2 >>> >>> /etc/make.conf is /dev/null. >>> I've also tried empty /etc/src.conf with no luck. >>> >> >> Out of curiosity, is your src tree mounted via NFS? >> >> Glen >> >=20 > I have a similar problem on revision=20 > /usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279213 > Node Kind: directory > Schedule: normal > Last Changed Author: glebius > Last Changed Rev: 279213 > Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) >=20 > http://pastebin.com/FuAUkBmX >=20 > Source tree is on the zfs > /usr/src # zfs list zroot/usr/src > NAME USED AVAIL REFER MOUNTPOINT > zroot/usr/src 1.35G 408G 1.35G /usr/src >=20 > what is most surprising, the same revision successfully building for th= e > other 2 computers, including amd64|zfs and i386|ufs. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 I am having the same problem building r279268 on r269358 Revision: 279268 Last Changed Author: arybchik Last Changed Rev: 279268 Last Changed Date: 2015-02-25 06:20:42 +0000 (Wed, 25 Feb 2015) not over NFS or anything, local ZFS. =3D=3D=3D> usr.bin/dirname (depend) --- usr.sbin.depend__D --- yacc: f - maximum table size exceeded *** [aslcompilerparse.c] Error code 2 make[5]: stopped in /usr/src/usr.sbin/acpi/iasl 1 error --=20 Allan Jude --ldQCWS3tlVSomNQ5srnEd8RqSD9kRqT7p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJU7gKPAAoJEJrBFpNRJZKfph4P/0/rbjYT254CGIo7sDhbCIlm F68l713+z1bgChq0pM2Yh1Sbv2zgzCapcXlga4vspXKO6l9YKOgvm1U4CCLLKLSP uY+l7L7x1xyvQ1GIBXFwZfjG8yYNooYiI5Io2+YF34JstQ/pNW7DtyUBSg51QfQt cujRRcY9bbDDjKC1hwyTXPMVZZ+Iu7PSOqZjh4Dhrb/X678v6laxNRNgVFmj2i6W 9QxA14neMOtz9DRYOLXwSjuYl8a9zUKaM4wUMUzptQF3BrdfHGibyXvbZ+oU5qnp 567YNuXVIb6crqHtjCi2Ztdb8H2bBO9iMXBQgP18Q5jdcQOW1Jiq+dqwXXfLjI8V tVSiLQnh4+5JAzH9XHt5qAAaTsx7Me9GzY3cx8S6IXl+9lfIfQImz0lX8o9yPgmG bTPbueQKbnpUcZaOni0cn3hhh32wqHNzRyQA23i763ZLYZaVjMLLZ2DWNNWyI6mm vSBz8e/Je2kIjQN+CcQikaPx4uWqjTMD3N0yJx3Tb8Joc5tzzCd5t7eHuWfj2X1D HVzPPTz2Jj6vXxfdDqiyURzjTWyU/OsiBlMN3FUPBiN24Bwx5dNsyVmTXFXN78xe xyLBCKlvWnh3J67qMpijrEbYZfEroChj8fayQcMZGGnU1i2rhEVpA4sP0G3Evt5J UmncuR53ui1xEIaPbpM1 =ix8h -----END PGP SIGNATURE----- --ldQCWS3tlVSomNQ5srnEd8RqSD9kRqT7p-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 17:27:08 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93AE5EF6; Wed, 25 Feb 2015 17:27:08 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 3C9C81728; Wed, 25 Feb 2015 17:27:07 +0000 (UTC) Message-ID: <54EE05EA.3030509@FreeBSD.org> Date: Wed, 25 Feb 2015 12:27:06 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ivan Klymenko , Glen Barber , Arseny Nasokin , Allan Jude Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> In-Reply-To: <20150225182201.216f6fee@nonamehost.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 17:27:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 11:22, Ivan Klymenko wrote: > Ð’ Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber > пишет: > >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: >>> I have clean svn tree with base/head branch. I try to build >>> world, but I have some mysterious bugs. The latest is yacc >>> failed to make c file on phase 4.3: >>> >>> ===> usr.sbin/acpi/iasl (depend) m4 -P >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler >>> >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y >>>> aslcompiler.y >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: >>> 89 shift/reduce conflicts. yacc: f - maximum table size >>> exceeded *** Error code 2 >>> >>> /etc/make.conf is /dev/null. I've also tried empty >>> /etc/src.conf with no luck. >>> >> >> Out of curiosity, is your src tree mounted via NFS? >> >> Glen >> > > I have a similar problem on revision /usr/src # svn info Path: . > Working Copy Root Path: /usr/src URL: > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository > Root: svn://svn.freebsd.org/base Repository UUID: > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: > directory Schedule: normal Last Changed Author: glebius Last > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 > (Mon, 23 Feb 2015) > > http://pastebin.com/FuAUkBmX > > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME > USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G > /usr/src > > what is most surprising, the same revision successfully building > for the other 2 computers, including amd64|zfs and i386|ufs. Your installed yacc(1) is too old, i.e., your world was built from head before r274460. FYI, this commit fixes the above problem for building from stable: https://svnweb.freebsd.org/changeset/base/278975 For building from old head (pre-r274460), you have to manually bootstrap yacc first, e.g., something like this: cd /usr/src/usr.bin/yacc make clean cleandepend make all && make install make clean cleandepend cd /usr/src make buildworld Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU= =lpVt -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 17:42:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2C5F4CD for ; Wed, 25 Feb 2015 17:42:16 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 64043BDB for ; Wed, 25 Feb 2015 17:42:16 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PHgsfU038985 for ; Wed, 25 Feb 2015 09:42:54 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> From: "Chris H" Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 09:42:54 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 17:42:16 -0000 On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot-on-poweroff-td5989901.html But there was no reported resolution. --Chris > I just wiped a system last night to perform a fresh install > from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, > and choosing the "reboot system", resulted in a LOR. I wasn't > able to capture the output. But I'm still plagued with LOR's. > They almost always follow the halt(8) command, and almost > always occur during the final stages of the boot. But aren't > always restricted to those events. The LOR's output seem > indicative of fs related issues. This system has *always* > worked w/o fail, and prior to this install, has never > indicated hardware issues. > Aside from the dmesg(8) attached, here are 2 of the examples. > NOTE the numbers, and files are not always the same, from > LOR to LOR; > > lock order reversal: > 1st 0xfffff8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 > 2nd 0xfffff80004caf5f0 devfs (devfs) @ > /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame > 0xfffffe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame > 0xfffffe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe0120c27750 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120c27780 > _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120c277f0 > ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfffffe0120c27860 > softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfffffe0120c278d0 > ffs_unmount() at ffs_unmount+0x81/frame 0xfffffe0120c27930 > dounmount() at dounmount+0x42c/frame 0xfffffe0120c279b0 > sys_unmount() at sys_unmount+0x2ec/frame 0xfffffe0120c27ae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c27bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c27bf0 > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = > 0x7ffffff > fe348, rbp = 0x7fffffffe460 --- > > lock order reversal: > 1st 0xfffffe00f749ddc8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3097 > 2nd 0xfffff80004f28c00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 > 85 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame > 0xfffffe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0120c6d540 > ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe0120c6d580 > ufs_direnter() at ufs_direnter+0x641/frame 0xfffffe0120c6d640 > ufs_rename() at ufs_rename+0xffe/frame 0xfffffe0120c6d830 > VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe0120c6d860 > kern_renameat() at kern_renameat+0x4bc/frame 0xfffffe0120c6dae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c6dbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c6dbf0 > --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = > 0x7ffffff > fded8, rbp = 0x7fffffffdee0 --- > > and another > > lock order reversal: > 1st 0xfffff800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 > 2nd 0xfffffe00f72442e0 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > 3rd 0xfffff80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame > 0xfffffe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame > 0xfffffe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfffffe0120aea030 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120aea060 > _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120aea0d0 > vget() at vget+0x67/frame 0xfffffe0120aea110 > vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfffffe0120aea160 > ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0120aea1f0 > softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfffffe0120aea2d0 > ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfffffe0120aea350 > ffs_truncate() at ffs_truncate+0x671/frame 0xfffffe0120aea530 > ufs_direnter() at ufs_direnter+0x7d1/frame 0xfffffe0120aea5f0 > ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfffffe0120aea7b0 > ufs_create() at ufs_create+0x2d/frame 0xfffffe0120aea7d0 > VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe0120aea800 > vn_open_cred() at vn_open_cred+0x2c6/frame 0xfffffe0120aea960 > kern_openat() at kern_openat+0x257/frame 0xfffffe0120aeaae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120aeabf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120aeabf0 > --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp = > 0x7ffffff > fd598, rbp = 0x7fffffffd670 --- > > I *really* need to build/install world/kernel on this > box. But am fairly confident that there will be issues > as I LOR's to occur during the process. > > Any insight || help with this, greatly appreciated. > > Thanks! > > --Chris > > -- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 18:18:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70F4C417 for ; Wed, 25 Feb 2015 18:18:54 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 103FCF76 for ; Wed, 25 Feb 2015 18:18:53 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PIJWLG047584 for ; Wed, 25 Feb 2015 10:19:32 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net>, <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> From: "Chris H" Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 10:19:32 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 18:18:54 -0000 On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" wrote > On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" wrote > > I see somebody also reported something along these lines, recently; > http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot- > on-poweroff-td5989901.html > > But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? --Chris > > --Chris > > > I just wiped a system last night to perform a fresh install > > from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, > > and choosing the "reboot system", resulted in a LOR. I wasn't > > able to capture the output. But I'm still plagued with LOR's. > > They almost always follow the halt(8) command, and almost > > always occur during the final stages of the boot. But aren't > > always restricted to those events. The LOR's output seem > > indicative of fs related issues. This system has *always* > > worked w/o fail, and prior to this install, has never > > indicated hardware issues. > > Aside from the dmesg(8) attached, here are 2 of the examples. > > NOTE the numbers, and files are not always the same, from > > LOR to LOR; > > > > lock order reversal: > > 1st 0xfffff8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 > > 2nd 0xfffff80004caf5f0 devfs (devfs) @ > > /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame > > 0xfffffe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame > > 0xfffffe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame > > 0xfffffe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame > > 0xfffffe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120c277f0 > > ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfffffe0120c27860 > > softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfffffe0120c278d0 > > ffs_unmount() at ffs_unmount+0x81/frame 0xfffffe0120c27930 > > dounmount() at dounmount+0x42c/frame 0xfffffe0120c279b0 > > sys_unmount() at sys_unmount+0x2ec/frame 0xfffffe0120c27ae0 > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c27bf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c27bf0 > > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = > > 0x7ffffff > > fe348, rbp = 0x7fffffffe460 --- > > > > lock order reversal: > > 1st 0xfffffe00f749ddc8 bufwait (bufwait) @ > > /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xfffff80004f28c00 dirhash (dirhash) > > @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 > > 85 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame > > 0xfffffe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0120c6d540 > > ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe0120c6d580 > > ufs_direnter() at ufs_direnter+0x641/frame 0xfffffe0120c6d640 > > ufs_rename() at ufs_rename+0xffe/frame 0xfffffe0120c6d830 > > VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe0120c6d860 > > kern_renameat() at kern_renameat+0x4bc/frame 0xfffffe0120c6dae0 > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c6dbf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c6dbf0 > > --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = > > 0x7ffffff > > fded8, rbp = 0x7fffffffdee0 --- > > > > and another > > > > lock order reversal: > > 1st 0xfffff800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 > > 2nd 0xfffffe00f72442e0 bufwait (bufwait) @ > > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > > 3rd 0xfffff80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame > > 0xfffffe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame > > 0xfffffe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfffffe0120aea030 > > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120aea060 > > _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120aea0d0 > > vget() at vget+0x67/frame 0xfffffe0120aea110 > > vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfffffe0120aea160 > > ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0120aea1f0 > > softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfffffe0120aea2d0 > > ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfffffe0120aea350 > > ffs_truncate() at ffs_truncate+0x671/frame 0xfffffe0120aea530 > > ufs_direnter() at ufs_direnter+0x7d1/frame 0xfffffe0120aea5f0 > > ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfffffe0120aea7b0 > > ufs_create() at ufs_create+0x2d/frame 0xfffffe0120aea7d0 > > VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe0120aea800 > > vn_open_cred() at vn_open_cred+0x2c6/frame 0xfffffe0120aea960 > > kern_openat() at kern_openat+0x257/frame 0xfffffe0120aeaae0 > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120aeabf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120aeabf0 > > --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp = > > 0x7ffffff > > fd598, rbp = 0x7fffffffd670 --- > > > > I *really* need to build/install world/kernel on this > > box. But am fairly confident that there will be issues > > as I LOR's to occur during the process. > > > > Any insight || help with this, greatly appreciated. > > > > Thanks! > > > > --Chris > > > > -- > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Feb 25 18:51:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFC8F8F7; Wed, 25 Feb 2015 18:51:52 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A87AA639; Wed, 25 Feb 2015 18:51:52 +0000 (UTC) Received: by pabrd3 with SMTP id rd3so7369812pab.1; Wed, 25 Feb 2015 10:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KXmQO61zm8FTHip2rdy21aOlsiCwMpFXBLjO5dnqO4k=; b=0oa9gFLxlXwVP7/l5ji1MhZ6Et+ptqfCW30hyCoI7jPOHMHbVT7cMCL7K4iGIBHlTz 2DWGCKkUwlbOwLoZX/I3ur/hYGUvR8tzKziAfyya9uUZOiyHe7FjbmqTCI+ZDE3cwGbv VixTnqv68/bykqGD5vY/tOsejHAvUSY/hC7o4wmnWUHGcje9NzAYOMpkBG3PH8EeYwkh Yk9Ffy/12gSjwlL85m9kuSqbzMILrkYmcQD1/+DXsFKGaGlzRXULIJ7LTaXUf/Z8R53/ 2d/U/HTPRbAIhKispQSSoNutvMCfJAfZ5+X6aVO0QpG9nqBbTH3sG/8DhjWgpixLTR9w HuDA== X-Received: by 10.66.118.129 with SMTP id km1mr8037131pab.112.1424890312265; Wed, 25 Feb 2015 10:51:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.232.9 with HTTP; Wed, 25 Feb 2015 10:51:31 -0800 (PST) In-Reply-To: <54EE05EA.3030509@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> From: Arseny Nasokin Date: Wed, 25 Feb 2015 22:51:31 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , Glen Barber , freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 18:51:53 -0000 On 25 February 2015 at 20:27, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/25/2015 11:22, Ivan Klymenko wrote: > > =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber > > =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: > >>> I have clean svn tree with base/head branch. I try to build > >>> world, but I have some mysterious bugs. The latest is yacc > >>> failed to make c file on phase 4.3: > >>> > >>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P > >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compile= r > >>> > >>> > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslp= arser.y > >>>> aslcompiler.y > >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: > >>> 89 shift/reduce conflicts. yacc: f - maximum table size > >>> exceeded *** Error code 2 > >>> > >>> /etc/make.conf is /dev/null. I've also tried empty > >>> /etc/src.conf with no luck. > >>> > >> > >> Out of curiosity, is your src tree mounted via NFS? > >> > >> Glen > >> > > > > I have a similar problem on revision /usr/src # svn info Path: . > > Working Copy Root Path: /usr/src URL: > > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository > > Root: svn://svn.freebsd.org/base Repository UUID: > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: > > directory Schedule: normal Last Changed Author: glebius Last > > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 > > (Mon, 23 Feb 2015) > > > > http://pastebin.com/FuAUkBmX > > > > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME > > USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G > > /usr/src > > > > what is most surprising, the same revision successfully building > > for the other 2 computers, including amd64|zfs and i386|ufs. > > Your installed yacc(1) is too old, i.e., your world was built from > head before r274460. FYI, this commit fixes the above problem for > building from stable: > > https://svnweb.freebsd.org/changeset/base/278975 > > For building from old head (pre-r274460), you have to manually > bootstrap yacc first, e.g., something like this: > > cd /usr/src/usr.bin/yacc > make clean cleandepend > make all && make install > make clean cleandepend > cd /usr/src > make buildworld > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS > 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm > 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw > XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ > 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm > KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=3D > =3DlpVt > -----END PGP SIGNATURE----- > Hi, guys, I've found the fix by forcing to add yacc(1) to bootstrap build. Makefile.inc1, line 1277: if ${BOOTSTRAPPING} < 1001506 _yacc=3D lib/liby \ change to: if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! _yacc=3D lib/liby \ -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 18:54:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECD7CAF6; Wed, 25 Feb 2015 18:54:25 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC8D1659; Wed, 25 Feb 2015 18:54:25 +0000 (UTC) Received: by iecrl12 with SMTP id rl12so7581917iec.4; Wed, 25 Feb 2015 10:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nM5O6T1anFKHlF9McNiMk6lmhcEtRgiBtHj2Sqv9wtM=; b=W8vPIjbZtZttv96nizAhmWN55o1a3krQyd3nc+hnfsKSWAnq5PCsEH11FReLwnoz7K 5zcCPbq0Be1jdnrpCYBJJ1RETF9XfACuxOES8H2IlxoFVBJsnPk4Ypx2mbjOtJ537h0t nIcDGhWp/0g5u3Y84heP8R9oDYMpuTbRhsvSGHfZONiN/aCrbMV9JE6Jxj98WsSVKp8a Sg5QYBRrXtaPsQgwD+ea7wvS70Dq9txGYHVmYwHg1SdF+SGs6MK4upGxeh0QeiGwFWGe Oa0ixUwPXmTUb2cv1dRQrn/JfPscFIa4FKWGDFY3ATG82FqTxprcuj84m0a6aoDgf3mg H59w== MIME-Version: 1.0 X-Received: by 10.50.66.170 with SMTP id g10mr28963039igt.49.1424890465048; Wed, 25 Feb 2015 10:54:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.66 with HTTP; Wed, 25 Feb 2015 10:54:24 -0800 (PST) In-Reply-To: References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> Date: Wed, 25 Feb 2015 10:54:24 -0800 X-Google-Sender-Auth: tBVzTqIuGGjS-7AgJ8uNrbCeVhs Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) From: Adrian Chadd To: Arseny Nasokin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 18:54:26 -0000 should this be committed to -head? -a On 25 February 2015 at 10:51, Arseny Nasokin wrote: > On 25 February 2015 at 20:27, Jung-uk Kim wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 02/25/2015 11:22, Ivan Klymenko wrote: >> > =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber >> > =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> > >> >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: >> >>> I have clean svn tree with base/head branch. I try to build >> >>> world, but I have some mysterious bugs. The latest is yacc >> >>> failed to make c file on phase 4.3: >> >>> >> >>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P >> >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compil= er >> >>> >> >>> >> >> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/asl= parser.y >> >>>> aslcompiler.y >> >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: >> >>> 89 shift/reduce conflicts. yacc: f - maximum table size >> >>> exceeded *** Error code 2 >> >>> >> >>> /etc/make.conf is /dev/null. I've also tried empty >> >>> /etc/src.conf with no luck. >> >>> >> >> >> >> Out of curiosity, is your src tree mounted via NFS? >> >> >> >> Glen >> >> >> > >> > I have a similar problem on revision /usr/src # svn info Path: . >> > Working Copy Root Path: /usr/src URL: >> > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository >> > Root: svn://svn.freebsd.org/base Repository UUID: >> > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: >> > directory Schedule: normal Last Changed Author: glebius Last >> > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 >> > (Mon, 23 Feb 2015) >> > >> > http://pastebin.com/FuAUkBmX >> > >> > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME >> > USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G >> > /usr/src >> > >> > what is most surprising, the same revision successfully building >> > for the other 2 computers, including amd64|zfs and i386|ufs. >> >> Your installed yacc(1) is too old, i.e., your world was built from >> head before r274460. FYI, this commit fixes the above problem for >> building from stable: >> >> https://svnweb.freebsd.org/changeset/base/278975 >> >> For building from old head (pre-r274460), you have to manually >> bootstrap yacc first, e.g., something like this: >> >> cd /usr/src/usr.bin/yacc >> make clean cleandepend >> make all && make install >> make clean cleandepend >> cd /usr/src >> make buildworld >> >> Jung-uk Kim >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS >> 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm >> 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw >> XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ >> 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm >> KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=3D >> =3DlpVt >> -----END PGP SIGNATURE----- >> > > > Hi, guys, > > I've found the fix by forcing to add yacc(1) to bootstrap build. > > Makefile.inc1, line 1277: > > if ${BOOTSTRAPPING} < 1001506 > _yacc=3D lib/liby \ > > change to: > > if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > _yacc=3D lib/liby \ > > > -- Eir Nym > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Feb 25 18:55:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 149C4C0B; Wed, 25 Feb 2015 18:55:30 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C972366E; Wed, 25 Feb 2015 18:55:29 +0000 (UTC) Received: by pablj1 with SMTP id lj1so4938964pab.9; Wed, 25 Feb 2015 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/zFulhJcwApkdJ6FpxD2QJ+RazsbZhhD/alAKjo+tPI=; b=jFRfgoGHEccVlVk0yuQCvR17cpIn4iCvusrGd9VPGOClVUQObXtTf2QOP8jeOl3bi7 A7PoyHRYkuK6lrkdAAsmLJ8FVC5nz4f5eSmSDH/Wm9LdlNx1ByfxZ5MhjBuJo+5Upc9t ntPrxaMNci7mArKnfNKtqtONT0UiIebTuUnvrxm4IX2PeupSR/uj9EmKQVPVm1P7230h OOw5WvPFu95zF73LqdBEvJuxXmKg3HZmLlfIIV3PIgaNSe8xCat72pbHO2yPNfqA0fTg cpELsxmiE2x1FbiOBT4BxYPMfxhAKB3u+IqbUKIvacYgAH4oqYxkWVDllIxMnelf9vfi Ba5w== X-Received: by 10.66.144.36 with SMTP id sj4mr8277688pab.32.1424890529403; Wed, 25 Feb 2015 10:55:29 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id fz7sm14453400pbd.60.2015.02.25.10.55.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 10:55:28 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_816DCDEA-70F7-4663-9299-CF860D3CACF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) From: Garrett Cooper In-Reply-To: Date: Wed, 25 Feb 2015 10:55:27 -0800 Message-Id: <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> To: Arseny Nasokin X-Mailer: Apple Mail (2.1878.6) Cc: Ivan Klymenko , Glen Barber , freebsd-current@freebsd.org, Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 18:55:30 -0000 --Apple-Mail=_816DCDEA-70F7-4663-9299-CF860D3CACF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 25, 2015, at 10:51, Arseny Nasokin wrote: > On 25 February 2015 at 20:27, Jung-uk Kim wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >>=20 >> On 02/25/2015 11:22, Ivan Klymenko wrote: >>> =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber >>> =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>=20 >>>> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: >>>>> I have clean svn tree with base/head branch. I try to build >>>>> world, but I have some mysterious bugs. The latest is yacc >>>>> failed to make c file on phase 4.3: >>>>>=20 >>>>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P >>>>> = -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler >>>>>=20 >>>>>=20 >>=20 >> = /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslpa= rser.y >>>>>> aslcompiler.y >>>>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: >>>>> 89 shift/reduce conflicts. yacc: f - maximum table size >>>>> exceeded *** Error code 2 >>>>>=20 >>>>> /etc/make.conf is /dev/null. I've also tried empty >>>>> /etc/src.conf with no luck. >>>>>=20 >>>>=20 >>>> Out of curiosity, is your src tree mounted via NFS? >>>>=20 >>>> Glen >>>>=20 >>>=20 >>> I have a similar problem on revision /usr/src # svn info Path: . >>> Working Copy Root Path: /usr/src URL: >>> svn://svn.freebsd.org/base/head Relative URL: ^/head Repository >>> Root: svn://svn.freebsd.org/base Repository UUID: >>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: >>> directory Schedule: normal Last Changed Author: glebius Last >>> Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 >>> (Mon, 23 Feb 2015) >>>=20 >>> http://pastebin.com/FuAUkBmX >>>=20 >>> Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME >>> USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G >>> /usr/src >>>=20 >>> what is most surprising, the same revision successfully building >>> for the other 2 computers, including amd64|zfs and i386|ufs. >>=20 >> Your installed yacc(1) is too old, i.e., your world was built from >> head before r274460. FYI, this commit fixes the above problem for >> building from stable: >>=20 >> https://svnweb.freebsd.org/changeset/base/278975 >>=20 >> For building from old head (pre-r274460), you have to manually >> bootstrap yacc first, e.g., something like this: >>=20 >> cd /usr/src/usr.bin/yacc >> make clean cleandepend >> make all && make install >> make clean cleandepend >> cd /usr/src >> make buildworld >>=20 >> Jung-uk Kim >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >>=20 >> iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS >> 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm >> 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw >> XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ >> 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm >> KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=3D >> =3DlpVt >> -----END PGP SIGNATURE----- >>=20 >=20 >=20 > Hi, guys, >=20 > I've found the fix by forcing to add yacc(1) to bootstrap build. >=20 > Makefile.inc1, line 1277: >=20 > if ${BOOTSTRAPPING} < 1001506 > _yacc=3D lib/liby \ >=20 > change to: >=20 > if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > _yacc=3D lib/liby \ It takes a few seconds to build this on my laptop =E2=80=94 can we just = explicitly turn this on to be sure we=E2=80=99re using the right thing? % (cd lib/liby; time sh -c 'make obj; make depend; make all') real 0m0.326s user 0m0.031s sys 0m0.111s % (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all') real 0m3.431s user 0m2.631s sys 0m0.363s With me parallelizing bootstrap-tools on HEAD it should be less of an = issue stacking on items like this. Thanks! --Apple-Mail=_816DCDEA-70F7-4663-9299-CF860D3CACF7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7hqfAAoJEMZr5QU6S73eUcsH/Rgv9iGaWT7mUU4ICZABMbSA hhJab5iohrXB5H/I2KnMPyllMA2or5SpuNF7ZB/saKmWfQyF6Dd1DgG4MV3K6052 kee+MZ8TLckV4tRKdD3Xp3qnVPXZ/VwqB4pmkcyUx2mVaBEJOX6a88lfcQHoi2PQ izDJa9yLSB3DhJp1S8AEL+hIXipS6r+DvMGgDsEeaQFYPooHQXk3SnkCQ87HZd2g KrJSUQFn1p9UUw3lf52rOFqg88yhFgBUDYuAF/bvz7NC0+GWsLYVaGDccxZG6fyj rewvyX4A2HGX7L3A8bcWh4iF6zXKtbtxcKjXPZTCWFHABLLfU5FGmwEyVARgXJE= =0kgZ -----END PGP SIGNATURE----- --Apple-Mail=_816DCDEA-70F7-4663-9299-CF860D3CACF7-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 18:59:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09B4111E for ; Wed, 25 Feb 2015 18:59:13 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1C0C6A1 for ; Wed, 25 Feb 2015 18:59:12 +0000 (UTC) Received: by pdjp10 with SMTP id p10so6893773pdj.3 for ; Wed, 25 Feb 2015 10:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wKCMpYepBgH76uh9NwKfw+/8fLzHvFy/k5bsKha6Yag=; b=Ux0IK0Kj8YLOhylyJG3s1WoecACo87uLYCrFJA7HsbO+INxK31q3i3wExpyyVpLtGS SXLFXaUrnALwzlMNXODi7Sbwh5Kqk3XsER/Ji6qnYCKiXZRz4eyeg7tVu3T7SSkuDU3F 1xh21tu2nJSNwHxczIdcup4UTfJcwdNHHsx7ICcOOxTLy4H79NW7Q/hdc+prUx27d5VL zUI9QqMGI9svTkEvrctKhs3hfnvidGDnMiRMqlywZLT9IJw4lNq+WrIaSBCdlDF1HrCV Auz1DMkPaYCgcMyceLJihu305kBdPZDBG0UGugPACD/UZoK2UxFgPNrXvViqINTpK062 m9Uw== X-Received: by 10.68.239.102 with SMTP id vr6mr7992568pbc.35.1424890752275; Wed, 25 Feb 2015 10:59:12 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id l2sm41996077pbq.50.2015.02.25.10.59.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 10:59:11 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_75D604F8-2D17-4293-973F-1295646C403B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: bombarded with LOR's with recent install From: Garrett Cooper In-Reply-To: <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> Date: Wed, 25 Feb 2015 10:59:11 -0800 Message-Id: <3371C5BF-B482-4813-8707-FDB9F59FBA72@gmail.com> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net>, <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 18:59:13 -0000 --Apple-Mail=_75D604F8-2D17-4293-973F-1295646C403B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 25, 2015, at 10:19, Chris H wrote: > On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" = wrote >=20 >> On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" = wrote >>=20 >> I see somebody also reported something along these lines, recently; >> = http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu= ot- >> on-poweroff-td5989901.html=20 >>=20 >> But there was no reported resolution. > and again in January, as well. > = https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html >=20 > Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN > in the GENERIC that is installed, outside of building a new > kernel? debug.witness.watch=3D0 disables witness watching -1 turns it off = altogether (and according to the code requires a reboot, but I haven=92t = tested that assertion). As for all of the LORs reported, I=92ve seen them a lot running CURRENT = and at $work :(... I=92m working on printing out those stacks via log(9) though =97 I=92ll = publish my new diff on Phabricator soon: = https://reviews.freebsd.org/D1794 . Cheers! --Apple-Mail=_75D604F8-2D17-4293-973F-1295646C403B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7ht/AAoJEMZr5QU6S73eAMEH/igGsGNKqUFrec3KKDj/wisG 5jaRpw//iJkQERV9ok4O9/LumAQCXr0dzFIl/TRDC/k+RsQc8xUbffs8Kw3ZT4Oh XG1uUrBxb/8fb5oc2X1aWW/BHn3P+GDgaTjYULRJkqbW9LmkIsmR6GcXRDnB7r+t fxVgaw2POAxzxIUHv1mBqGsVJlM8X5ae8J7BtDRO7DiCiRDl4Gc7r7UuLtu2I2pt QWWppGbz6WiXXLZKfOpTFcfbuxPR4Fm9S/v0fkJW0DB7zInopbneO/C5FXJXjdTK JK2682rPkwCk/3gjJlH+0A0FI8QvXZ1u0xq57bbTkfv/sRlv1RHSARxKNwtgOLc= =k4UN -----END PGP SIGNATURE----- --Apple-Mail=_75D604F8-2D17-4293-973F-1295646C403B-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:02:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2CEA52B; Wed, 25 Feb 2015 19:02:09 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A487C1; Wed, 25 Feb 2015 19:02:09 +0000 (UTC) Received: by pdno5 with SMTP id o5so6871187pdn.8; Wed, 25 Feb 2015 11:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KCRY4A4gvBOsENgCNT3BqRUGqhgZ08A/wGgt6xfiDFQ=; b=Z7M8lbwJiVo6y0RqJX1chvUO8nsqzbxvhjO+32wxAdzzghRVl5uwAGgMlNJZ0A0Z43 s7XeW+KdzGSlPDThFbQB0AYL2D/sNm5xHX9T55e3iOtODRrjOjxnXEqctVYT/TJ/GBHp d1NhRMBhOhR/xVtOWJT7qAJPnpFvMZhchN2BqF5q7DszlVvvYKr/CICyU4tAcL62ywjJ KNxepPhwBTBT7kyByQBfS+ltouDdx+UGWSQu2lXzopfgNLb1kQqe/dn3C/oEOZYc8Kq5 cKvG6FOoi2p4gzu2Rfrg3e+VYcZ+taOWXYIizc1Zl8GamenHMF8+Akps8gBuBSzt0KAk gNSA== X-Received: by 10.69.1.7 with SMTP id bc7mr7715088pbd.121.1424890928790; Wed, 25 Feb 2015 11:02:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.232.9 with HTTP; Wed, 25 Feb 2015 11:01:48 -0800 (PST) In-Reply-To: References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> From: Arseny Nasokin Date: Wed, 25 Feb 2015 23:01:48 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:02:10 -0000 On 25 February 2015 at 21:54, Adrian Chadd wrote: > should this be committed to -head? > > > -a > > > On 25 February 2015 at 10:51, Arseny Nasokin wrote: > > On 25 February 2015 at 20:27, Jung-uk Kim wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> On 02/25/2015 11:22, Ivan Klymenko wrote: > >> > =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber > >> > =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > > >> >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: > >> >>> I have clean svn tree with base/head branch. I try to build > >> >>> world, but I have some mysterious bugs. The latest is yacc > >> >>> failed to make c file on phase 4.3: > >> >>> > >> >>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P > >> >>> > -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler > >> >>> > >> >>> > >> > >> > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslp= arser.y > >> >>>> aslcompiler.y > >> >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: > >> >>> 89 shift/reduce conflicts. yacc: f - maximum table size > >> >>> exceeded *** Error code 2 > >> >>> > >> >>> /etc/make.conf is /dev/null. I've also tried empty > >> >>> /etc/src.conf with no luck. > >> >>> > >> >> > >> >> Out of curiosity, is your src tree mounted via NFS? > >> >> > >> >> Glen > >> >> > >> > > >> > I have a similar problem on revision /usr/src # svn info Path: . > >> > Working Copy Root Path: /usr/src URL: > >> > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository > >> > Root: svn://svn.freebsd.org/base Repository UUID: > >> > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: > >> > directory Schedule: normal Last Changed Author: glebius Last > >> > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 > >> > (Mon, 23 Feb 2015) > >> > > >> > http://pastebin.com/FuAUkBmX > >> > > >> > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME > >> > USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G > >> > /usr/src > >> > > >> > what is most surprising, the same revision successfully building > >> > for the other 2 computers, including amd64|zfs and i386|ufs. > >> > >> Your installed yacc(1) is too old, i.e., your world was built from > >> head before r274460. FYI, this commit fixes the above problem for > >> building from stable: > >> > >> https://svnweb.freebsd.org/changeset/base/278975 > >> > >> For building from old head (pre-r274460), you have to manually > >> bootstrap yacc first, e.g., something like this: > >> > >> cd /usr/src/usr.bin/yacc > >> make clean cleandepend > >> make all && make install > >> make clean cleandepend > >> cd /usr/src > >> make buildworld > >> > >> Jung-uk Kim > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v2 > >> > >> iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS > >> 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm > >> 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw > >> XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ > >> 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm > >> KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=3D > >> =3DlpVt > >> -----END PGP SIGNATURE----- > >> > > > > > > Hi, guys, > > > > I've found the fix by forcing to add yacc(1) to bootstrap build. > > > > Makefile.inc1, line 1277: > > > > if ${BOOTSTRAPPING} < 1001506 > > _yacc=3D lib/liby \ > > > > change to: > > > > if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > > _yacc=3D lib/liby \ > > > > > > -- Eir Nym > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > Adrian, In this form this must not be committed, but this is good clue where to fix it. -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:05:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2BDE775; Wed, 25 Feb 2015 19:05:15 +0000 (UTC) Date: Wed, 25 Feb 2015 19:05:12 +0000 From: Glen Barber To: Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150225190512.GH1161@hub.FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gTtJ75FAzB1T2CN6" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ivan Klymenko , freebsd-current@freebsd.org, Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:05:16 -0000 --gTtJ75FAzB1T2CN6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > On 25 February 2015 at 20:27, Jung-uk Kim wrote: > > Your installed yacc(1) is too old, i.e., your world was built from > > head before r274460. FYI, this commit fixes the above problem for > > building from stable: > > > > https://svnweb.freebsd.org/changeset/base/278975 > > > > For building from old head (pre-r274460), you have to manually > > bootstrap yacc first, e.g., something like this: > > > > cd /usr/src/usr.bin/yacc > > make clean cleandepend > > make all && make install > > make clean cleandepend > > cd /usr/src > > make buildworld > > >=20 > Hi, guys, >=20 > I've found the fix by forcing to add yacc(1) to bootstrap build. >=20 > Makefile.inc1, line 1277: >=20 > if ${BOOTSTRAPPING} < 1001506 > _yacc=3D lib/liby \ >=20 > change to: >=20 > if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > _yacc=3D lib/liby \ >=20 This can be set to 1001507 now; __FreeBSD_version was bumped earlier today. Glen --gTtJ75FAzB1T2CN6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU7hzoAAoJEAMUWKVHj+KT40sP/3Xlb0t8/f0Sb69MMx2Z3uZ+ 2QQwFgBjADbIRjItEVxtj/SpMjAenAqCH/iVmpHbdHCCU65hjH9DUM+jSIS5PHM0 WRd7FWobXf8ZHCQPeDi1qPXcniOmL/YkbsoLMCF0MRX3ieKuQHTghQLDXQ/VEWvH MMLk+FNc8jv8y75fTAANmEVoaFlIui84ggM6z0dKPMp+XcDpz3XabFurj4cg4klh p+UJKz3KeOqft3/GuBXngpqSHCVFFcaaLbgSpTgJeuwydHvPHxdIR17JaxbrWpBS 3q0IRbpkB+f+JVUwP8+iqaY+WCxunaqtWtTiCb10DPmTZQKvpZvE4xjI5VY9I45e St5t2jcq61S2sOmo5sbE+bEPjX7Mp+uBbs5n1nSc7yF0IaUvutzP5I7I2Tc6/3DF W41BaGJ+Mk+sY5zDs0vQ/ErM+/CfoUIutUUvkUkIqADWbEJYo85m2vpsintIiGl8 LShoGgx/o99GPwl4lkqPrl0mSG9aBGuMb/kPf9oLIkuwHNXZljoScEg0goACyDVN SUN78F4596SS2+BZBj3eNVFXd6Mlp6vyvgDb8pPMUahkuRkawCUmm4AyCi9Q2YOu rcqrCLRZytJcdAgW29fkmbiwXRP7F14sxcjP7jK5aey1MNOUEaKblbkKb4MyFJ62 5+YCYrkfZEhsg4LCWqRo =OX0K -----END PGP SIGNATURE----- --gTtJ75FAzB1T2CN6-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:09:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D542A09 for ; Wed, 25 Feb 2015 19:09:38 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 2D177846 for ; Wed, 25 Feb 2015 19:09:38 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PJAGPt060263; Wed, 25 Feb 2015 11:10:16 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Garrett Cooper In-Reply-To: <3371C5BF-B482-4813-8707-FDB9F59FBA72@gmail.com> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net>, <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> <60a188b7861637d4bb7085b06f506a84@ultimatedns.net>, <3371C5BF-B482-4813-8707-FDB9F59FBA72@gmail.com> From: "Chris H" Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 11:10:16 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:09:38 -0000 On Wed, 25 Feb 2015 10:59:11 -0800 Garrett Cooper wrote > On Feb 25, 2015, at 10:19, Chris H wrote: > > > On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" wrote > > > >> On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" > >> wrote > >> I see somebody also reported something along these lines, recently; > >> > >> http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot- > >> on-poweroff-td5989901.html > >> > >> But there was no reported resolution. > > and again in January, as well. > > https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html > > > > Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN > > in the GENERIC that is installed, outside of building a new > > kernel? > > debug.witness.watch=0 disables witness watching -1 turns it off altogether > (and according to the code requires a reboot, but I haven’t tested that > assertion). Thank you, Garrett. That's great to know. > > As for all of the LORs reported, I’ve seen them a lot running CURRENT and at > $work :(... > > I’m working on printing out those stacks via log(9) though — I’ll publish my > new diff on Phabricator soon: https://reviews.freebsd.org/D1794 . I'll be watching this. Thanks! > > Cheers! --Chris -- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:10:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06030BF5; Wed, 25 Feb 2015 19:10:50 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 5F09B1660; Wed, 25 Feb 2015 19:10:49 +0000 (UTC) Message-ID: <54EE1E38.30106@FreeBSD.org> Date: Wed, 25 Feb 2015 14:10:48 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> In-Reply-To: <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Ivan Klymenko , Glen Barber , freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:10:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 13:55, Garrett Cooper wrote: > On Feb 25, 2015, at 10:51, Arseny Nasokin > wrote: > >> On 25 February 2015 at 20:27, Jung-uk Kim >> wrote: >> > On 02/25/2015 11:22, Ivan Klymenko wrote: >>>>> Ð’ Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber >>>>> пишет: >>>>> >>>>>> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin >>>>>> wrote: >>>>>>> I have clean svn tree with base/head branch. I try to >>>>>>> build world, but I have some mysterious bugs. The >>>>>>> latest is yacc failed to make c file on phase 4.3: >>>>>>> >>>>>>> ===> usr.sbin/acpi/iasl (depend) m4 -P >>>>>>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler >>>>>>> >>>>>>> > >>>>>>> > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y >>>>>>>> > aslcompiler.y >>>>>>> yacc -d -pAslCompiler -oaslcompilerparse.c >>>>>>> aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f >>>>>>> - maximum table size exceeded *** Error code 2 >>>>>>> >>>>>>> /etc/make.conf is /dev/null. I've also tried empty >>>>>>> /etc/src.conf with no luck. >>>>>>> >>>>>> >>>>>> Out of curiosity, is your src tree mounted via NFS? >>>>>> >>>>>> Glen >>>>>> >>>>> >>>>> I have a similar problem on revision /usr/src # svn info >>>>> Path: . Working Copy Root Path: /usr/src URL: >>>>> svn://svn.freebsd.org/base/head Relative URL: ^/head >>>>> Repository Root: svn://svn.freebsd.org/base Repository >>>>> UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 >>>>> Node Kind: directory Schedule: normal Last Changed Author: >>>>> glebius Last Changed Rev: 279213 Last Changed Date: >>>>> 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) >>>>> >>>>> http://pastebin.com/FuAUkBmX >>>>> >>>>> Source tree is on the zfs /usr/src # zfs list zroot/usr/src >>>>> NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G >>>>> 408G 1.35G /usr/src >>>>> >>>>> what is most surprising, the same revision successfully >>>>> building for the other 2 computers, including amd64|zfs and >>>>> i386|ufs. > > Your installed yacc(1) is too old, i.e., your world was built from > head before r274460. FYI, this commit fixes the above problem for > building from stable: > > https://svnweb.freebsd.org/changeset/base/278975 > > For building from old head (pre-r274460), you have to manually > bootstrap yacc first, e.g., something like this: > > cd /usr/src/usr.bin/yacc make clean cleandepend make all && make > install make clean cleandepend cd /usr/src make buildworld > > Jung-uk Kim >>> >> >> >> Hi, guys, >> >> I've found the fix by forcing to add yacc(1) to bootstrap build. >> >> Makefile.inc1, line 1277: >> >> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ >> >> change to: >> >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! >> _yacc= lib/liby \ > > It takes a few seconds to build this on my laptop — can we just > explicitly turn this on to be sure we’re using the right thing? > > % (cd lib/liby; time sh -c 'make obj; make depend; make all') > > real 0m0.326s user 0m0.031s sys 0m0.111s > > % (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all') > > real 0m3.431s user 0m2.631s sys 0m0.363s > > With me parallelizing bootstrap-tools on HEAD it should be less of > an issue stacking on items like this. Then, this argument also applies to other conditional bootstrap-tools, e.g., bin/cat. I know we have long tradition of painting bikesheds with different colors and it will probably never end. However, I will not participate in this one, sorry. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU7h4zAAoJEHyflib82/FGEPkH/0SoSYzFfCifBUS14JiSn6hC 0O544JmeJE4giPAfk6h/vbKzJ43Q/NTvPRrayj2XZHNLJzzwH4fZsInFlqdfirna Yqv0WTXHt2ZycsaP8ZxANF020eG8MV9L9q4r6xo1piiiWZMC9NlgbI8SQGC56Rbd nTSL4sKIcCBdfImpUMLnVBvIMFrP4FbxBdqAYNbc6JlwxWtIWPesJMdgpHJgg/5F tBJIHq3SgChOQjxxmIwwdiv/m25jx9b4247gxjdITpxUfaaUephsMa7qZ35RlURU AMsUWeINzZmvWbOORSnxHKCClxkDav+kPGVk105tzNv4P6FnyhWgoGm+cb1hlNI= =dSyP -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:14:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B60FFB9; Wed, 25 Feb 2015 19:14:38 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 173461BC8; Wed, 25 Feb 2015 19:14:38 +0000 (UTC) Message-ID: <54EE1F1D.8060807@FreeBSD.org> Date: Wed, 25 Feb 2015 14:14:37 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Glen Barber , Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> In-Reply-To: <20150225190512.GH1161@hub.FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Ivan Klymenko , freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:14:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 14:05, Glen Barber wrote: > On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: >> On 25 February 2015 at 20:27, Jung-uk Kim >> wrote: >>> Your installed yacc(1) is too old, i.e., your world was built >>> from head before r274460. FYI, this commit fixes the above >>> problem for building from stable: >>> >>> https://svnweb.freebsd.org/changeset/base/278975 >>> >>> For building from old head (pre-r274460), you have to manually >>> bootstrap yacc first, e.g., something like this: >>> >>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && >>> make install make clean cleandepend cd /usr/src make >>> buildworld >>> >> >> Hi, guys, >> >> I've found the fix by forcing to add yacc(1) to bootstrap build. >> >> Makefile.inc1, line 1277: >> >> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ >> >> change to: >> >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! >> _yacc= lib/liby \ >> > > This can be set to 1001507 now; __FreeBSD_version was bumped > earlier today. Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and __FreeBSD_version was bumped to reflect it. https://svnweb.freebsd.org/changeset/base/277087 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU7h8dAAoJEHyflib82/FGL9cH/A3wsEEjtUNGcmOfYHN2+l50 K9xCxRwLvioxOjFygnHoNTvxhSMxjMCvX7UtyLR3CWD/31FJEsGgv7uFoavAMUPq hk5vAUJgoAbue4FwF6Ow7Lmm59dl+4ukVqEawepYFlYn6njLgJt1itF74VD9aufi D1oRk72KhhPXe66DYJsXzybgq5ba2/eJy0/YLsheRnsb2zB7fEcHGGca1icAVgjm 794BQdk0kOG7+EkQcafIElY4HJb+mJCE4iFg3NCrhrs7wEYZZQXlqDUVKRd0R5kN U4u4EiXckiyDVPrzicnpVCtQD5vdxH5BBfWC1FQIFnzTJgLZuRihLpfmDZOeHS8= =+AsC -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:21:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2708C481; Wed, 25 Feb 2015 19:21:11 +0000 (UTC) Date: Wed, 25 Feb 2015 19:21:07 +0000 From: Glen Barber To: Jung-uk Kim Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150225192107.GJ1161@hub.FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="liqSWPDvh3eyfZ9k" Content-Disposition: inline In-Reply-To: <54EE1F1D.8060807@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ivan Klymenko , Arseny Nasokin , Allan Jude , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:21:12 -0000 --liqSWPDvh3eyfZ9k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2015 at 02:14:37PM -0500, Jung-uk Kim wrote: > On 02/25/2015 14:05, Glen Barber wrote: > > On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > >> On 25 February 2015 at 20:27, Jung-uk Kim > >> wrote: > >>> Your installed yacc(1) is too old, i.e., your world was built > >>> from head before r274460. FYI, this commit fixes the above > >>> problem for building from stable: > >>>=20 > >>> https://svnweb.freebsd.org/changeset/base/278975 > >>>=20 > >>> For building from old head (pre-r274460), you have to manually=20 > >>> bootstrap yacc first, e.g., something like this: > >>>=20 > >>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && > >>> make install make clean cleandepend cd /usr/src make > >>> buildworld > >>>=20 > >>=20 > >> Hi, guys, > >>=20 > >> I've found the fix by forcing to add yacc(1) to bootstrap build. > >>=20 > >> Makefile.inc1, line 1277: > >>=20 > >> if ${BOOTSTRAPPING} < 1001506 _yacc=3D lib/liby \ > >>=20 > >> change to: > >>=20 > >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!!=20 > >> _yacc=3D lib/liby \ > >>=20 > >=20 > > This can be set to 1001507 now; __FreeBSD_version was bumped > > earlier today. >=20 > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and > __FreeBSD_version was bumped to reflect it. >=20 > https://svnweb.freebsd.org/changeset/base/277087 >=20 Ah, right. Thank you for the correction. Glen --liqSWPDvh3eyfZ9k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU7iCjAAoJEAMUWKVHj+KTth8P/jv9bSFVYgHUrlYfT6OBkPdV oGZfdCP2yt/eza/jxxJzwHJbrMdaZEwqGZjCr9O8EYAEhvrsC2p6pTer/ESbrXPR i3JS1nxP9dsaJlWn7FZ+qdxOrxt92J85r8ggDsRQhPG6JAM7BfhsRkQfD86Z3frR rymucuymP8CjJJ6BRWW2hnlNt8OE+eRLS5+ewY0CcTU4dn0hapzcS1fhJn3KXW9F 1Qy3GmF2uDh/84K/HqDRlpUBKA2QlcRziXFgPLeqBV8KD9x6QKF/oiMCSVWBwKSB CMaPpQNyDcWRg06AbApUa2TCn+sNdPqD+1+i9oRxFFUNT/wWMNUi0LVLqjZiDic9 0dJClD4JI/qm+ORpdAM++r0c8hsleg8bAU2ewvdHEY/Q5htPAofnxAehrO4a6eSW ZCa9UD94RFQGNegpd5NP5i8r9Sbp9lu7EdvDOh865gzj/lRike2Vgg/MsXNxovK4 nilVxOoQ6a7EDa32MCvkT7cXCLdreznLdL6dEquk4nUVXf1d16OOX1Wv19PHNqLu fRtBwX3ZwMSorLHIyhYmjFkSSHISvEuy0KDiRfHn6xiNxlpOQWrolibzzO+/Drhe BZe0VowYRiUEtmXrbNlv3pV4xgm4kYI1hVXI4+3F58DFrY7tlPwRT2lYMyoZmmW1 2e4LaIMObF12YCqtTULZ =6i7B -----END PGP SIGNATURE----- --liqSWPDvh3eyfZ9k-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:48:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08CFADAD; Wed, 25 Feb 2015 19:48:48 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDE69C9F; Wed, 25 Feb 2015 19:48:47 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so39034852igb.0; Wed, 25 Feb 2015 11:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1xdtZqUfYLnk3lAIvmSSdKdZvbR0WP5O42bPUdgC8F0=; b=c5mVVJJXnjfaaJNHlA5Ppxk0PUX40DMU5pJ2XcU6z9XMosdGH2Z6oIgOVTx6Zjoyqg re2x8d/fKN330Lh/8N397xmKJZunKOWBcZ21h4vVJ5YvGO4VqsDlsu+WrzimDN+ciBFE 8phwe5JFa7LGkhgSPFB+Z57Gfc4Xof1RnLAf+tL+028jFrB4SOMq4Ouzczdp11vjlo/u MUEvP0jz0xtSQtkSZD7nzH7xMcpHT1vAom5FlySoqSNxm+sB9G4BQUMlsZwtmRwSPYqE YVXEUMTjBkmBCsiE0Fyyz+jpqIA5uyLDq9bzLTHpi5CIzm9wtUF4uG1eCo5ExOVogqFT 8IQA== MIME-Version: 1.0 X-Received: by 10.42.201.78 with SMTP id ez14mr5870350icb.22.1424893727181; Wed, 25 Feb 2015 11:48:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.66 with HTTP; Wed, 25 Feb 2015 11:48:47 -0800 (PST) In-Reply-To: <54EE1E38.30106@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> <54EE1E38.30106@FreeBSD.org> Date: Wed, 25 Feb 2015 11:48:47 -0800 X-Google-Sender-Auth: TSRLZTz7I8PbQDlKuWKZh-8lfjE Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Cc: Ivan Klymenko , freebsd-current , Glen Barber , Arseny Nasokin , Allan Jude , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:48:48 -0000 There's no bikeshed to be had. Either the tool meets some specific version / API requirement in order to be used how it's used, or something has to be built in its place. Since tools are now getting backported during a stable branch in order to grow new features, we can't just assume "oh stable/10 cat will always support these options". So, checking some version string to see if the utility meets the requirements is fine. The only bikeshed I'd introduce is having each tool take a --version style option to print out its own "program API" version, so we can match on things as appropriate. But BOOTSTRAPPING is fine. -adrian From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 19:59:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 023A721F; Wed, 25 Feb 2015 19:59:48 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE025DD1; Wed, 25 Feb 2015 19:59:47 +0000 (UTC) Received: by pdjz10 with SMTP id z10so7159671pdj.12; Wed, 25 Feb 2015 11:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gyuDA0P1YpEOCbUzUJY46p73GQIoeidRsI0XnpMSpQc=; b=M6QLExe8ou5q1L92LQQ9iblqURRkK+qba7wPilmE3c/huCNKmdRrvy7co7ftZDkzsJ ZdNBSZyDMEshlglOntlOpPeUQ4OwuQHOeQ5wziaZpS6BLgNyGUrfXWmbyg0T/ZgY/NYB AMuH008Vw7cDi5+Syp7Jr9gkuMiOklaJ9+ZuHu4YlXK05+JTqWF12e9pbtneIJE4mYP9 p0RBaojquwTQLoUG+wjq7F5IhmHnw5iMk+qBRfsjYw3Brkh22lIso0P49otZIOOlMvFn wLhkoxvPQ9OSh9AQyHGPYGzW6xVqZrBK6A8Kv/y+lNl5T/v8IF47B5srAziPZPvw0z9j 4Tfw== X-Received: by 10.70.26.100 with SMTP id k4mr8325173pdg.125.1424894387264; Wed, 25 Feb 2015 11:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.232.9 with HTTP; Wed, 25 Feb 2015 11:59:27 -0800 (PST) In-Reply-To: <54EE1F1D.8060807@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> From: Arseny Nasokin Date: Wed, 25 Feb 2015 23:59:27 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 19:59:48 -0000 On 25 February 2015 at 22:14, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/25/2015 14:05, Glen Barber wrote: > > On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > >> On 25 February 2015 at 20:27, Jung-uk Kim > >> wrote: > >>> Your installed yacc(1) is too old, i.e., your world was built > >>> from head before r274460. FYI, this commit fixes the above > >>> problem for building from stable: > >>> > >>> https://svnweb.freebsd.org/changeset/base/278975 > >>> > >>> For building from old head (pre-r274460), you have to manually > >>> bootstrap yacc first, e.g., something like this: > >>> > >>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && > >>> make install make clean cleandepend cd /usr/src make > >>> buildworld > >>> > >> > >> Hi, guys, > >> > >> I've found the fix by forcing to add yacc(1) to bootstrap build. > >> > >> Makefile.inc1, line 1277: > >> > >> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ > >> > >> change to: > >> > >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > >> _yacc= lib/liby \ > >> > > > > This can be set to 1001507 now; __FreeBSD_version was bumped > > earlier today. > > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and > __FreeBSD_version was bumped to reflect it. > > https://svnweb.freebsd.org/changeset/base/277087 > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJU7h8dAAoJEHyflib82/FGL9cH/A3wsEEjtUNGcmOfYHN2+l50 > K9xCxRwLvioxOjFygnHoNTvxhSMxjMCvX7UtyLR3CWD/31FJEsGgv7uFoavAMUPq > hk5vAUJgoAbue4FwF6Ow7Lmm59dl+4ukVqEawepYFlYn6njLgJt1itF74VD9aufi > D1oRk72KhhPXe66DYJsXzybgq5ba2/eJy0/YLsheRnsb2zB7fEcHGGca1icAVgjm > 794BQdk0kOG7+EkQcafIElY4HJb+mJCE4iFg3NCrhrs7wEYZZQXlqDUVKRd0R5kN > U4u4EiXckiyDVPrzicnpVCtQD5vdxH5BBfWC1FQIFnzTJgLZuRihLpfmDZOeHS8= > =+AsC > -----END PGP SIGNATURE----- > Jung, I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and invalid YACC. So This conditional expression must be fixed to check if this 11.x and yacc is not changed. In my hypothetical "patch" I set OSRELDATE to invalid abstract future version, because it's only concept and I have no time to fix it correctly now. From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 20:11:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D21F7AE; Wed, 25 Feb 2015 20:11:32 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D98351; Wed, 25 Feb 2015 20:11:32 +0000 (UTC) Received: by padfa1 with SMTP id fa1so7859702pad.2; Wed, 25 Feb 2015 12:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=elG1Wl+FD9QYxM/aK9MlE5bI5NX6Us6mTB+Q8xr6KTs=; b=Mkwfs/8vty+v/x+787ul3y3IeCVgxx6j4VLXvW+UHYZpmcQuO0nkR+RKLRecbY1R9R Sv1sAWRjwYJlQeOCU0dh7zwx8iYfva6fyc29zFbEI0HMWzbREfbIw16E7SbTT5deUnTD j3VWyhqNag9JVB5O/cpi/QVC7Qs2lic94LKDNLRo9grY7768Mt6a2ntjqLa0e5kI2mmj eZT3d32Uq4Atqp3Rb7Z3vtXv4i+mwedg/rlMksMKgtJnri+PPtJCPJD4dmCFUGVv1wQb QHLD7HYbJAu4n2bJFrlsEddKE5FwsHscqlx26oCojlZkWnWNWjVGPyh5JZcg62KWIkT0 DkZA== X-Received: by 10.66.124.227 with SMTP id ml3mr8715099pab.28.1424895091616; Wed, 25 Feb 2015 12:11:31 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:3176:ea27:1ad4:219b? ([2601:8:ab80:7d6:3176:ea27:1ad4:219b]) by mx.google.com with ESMTPSA id pm12sm24482853pdb.75.2015.02.25.12.11.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 12:11:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1C5F7134-B97F-42BF-B72B-E50955C0869B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) From: Garrett Cooper In-Reply-To: <54EE1E38.30106@FreeBSD.org> Date: Wed, 25 Feb 2015 12:11:29 -0800 Message-Id: <95891DFC-786D-4064-A9F9-7A8E434EC568@gmail.com> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> <54EE1E38.30106@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1878.6) Cc: Ivan Klymenko , Glen Barber , Arseny Nasokin , Allan Jude , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 20:11:32 -0000 --Apple-Mail=_1C5F7134-B97F-42BF-B72B-E50955C0869B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 25, 2015, at 11:10, Jung-uk Kim wrote: > Signed PGP part > On 02/25/2015 13:55, Garrett Cooper wrote: > > On Feb 25, 2015, at 10:51, Arseny Nasokin > > wrote: > > > >> On 25 February 2015 at 20:27, Jung-uk Kim > >> wrote: > >> > > On 02/25/2015 11:22, Ivan Klymenko wrote: > >>>>> =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber > >>>>> =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>> > >>>>>> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin > >>>>>> wrote: > >>>>>>> I have clean svn tree with base/head branch. I try to > >>>>>>> build world, but I have some mysterious bugs. The > >>>>>>> latest is yacc failed to make c file on phase 4.3: > >>>>>>> > >>>>>>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P > >>>>>>> = -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler > >>>>>>> > >>>>>>> > > > >>>>>>> > > = /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslpa= rser.y > >>>>>>>> > > > aslcompiler.y > >>>>>>> yacc -d -pAslCompiler -oaslcompilerparse.c > >>>>>>> aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f > >>>>>>> - maximum table size exceeded *** Error code 2 > >>>>>>> > >>>>>>> /etc/make.conf is /dev/null. I've also tried empty > >>>>>>> /etc/src.conf with no luck. > >>>>>>> > >>>>>> > >>>>>> Out of curiosity, is your src tree mounted via NFS? > >>>>>> > >>>>>> Glen > >>>>>> > >>>>> > >>>>> I have a similar problem on revision /usr/src # svn info > >>>>> Path: . Working Copy Root Path: /usr/src URL: > >>>>> svn://svn.freebsd.org/base/head Relative URL: ^/head > >>>>> Repository Root: svn://svn.freebsd.org/base Repository > >>>>> UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 > >>>>> Node Kind: directory Schedule: normal Last Changed Author: > >>>>> glebius Last Changed Rev: 279213 Last Changed Date: > >>>>> 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) > >>>>> > >>>>> http://pastebin.com/FuAUkBmX > >>>>> > >>>>> Source tree is on the zfs /usr/src # zfs list zroot/usr/src > >>>>> NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G > >>>>> 408G 1.35G /usr/src > >>>>> > >>>>> what is most surprising, the same revision successfully > >>>>> building for the other 2 computers, including amd64|zfs and > >>>>> i386|ufs. > > > > Your installed yacc(1) is too old, i.e., your world was built from > > head before r274460. FYI, this commit fixes the above problem for > > building from stable: > > > > https://svnweb.freebsd.org/changeset/base/278975 > > > > For building from old head (pre-r274460), you have to manually > > bootstrap yacc first, e.g., something like this: > > > > cd /usr/src/usr.bin/yacc make clean cleandepend make all && make > > install make clean cleandepend cd /usr/src make buildworld > > > > Jung-uk Kim > >>> > >> > >> > >> Hi, guys, > >> > >> I've found the fix by forcing to add yacc(1) to bootstrap build. > >> > >> Makefile.inc1, line 1277: > >> > >> if ${BOOTSTRAPPING} < 1001506 _yacc=3D lib/liby \ > >> > >> change to: > >> > >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!! > >> _yacc=3D lib/liby \ > > > > It takes a few seconds to build this on my laptop =E2=80=94 can we = just > > explicitly turn this on to be sure we=E2=80=99re using the right = thing? > > > > % (cd lib/liby; time sh -c 'make obj; make depend; make all') > > > > real 0m0.326s user 0m0.031s sys 0m0.111s > > > > % (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all') > > > > real 0m3.431s user 0m2.631s sys 0m0.363s > > > > With me parallelizing bootstrap-tools on HEAD it should be less of > > an issue stacking on items like this. >=20 > Then, this argument also applies to other conditional bootstrap-tools, > e.g., bin/cat. >=20 > I know we have long tradition of painting bikesheds with different > colors and it will probably never end. However, I will not > participate in this one, sorry. I was going to propose something a bit more radical =E2=80=94 I can = remove the BOOTSTRAPPING conditionals and simplify the code on 10-STABLE = / 11-CURRENT. Maintaining BOOTSTRAPPING is error prone and it=E2=80=99s not saving = much time in the long run in builds (it's taking longer to diagnose = issues, test them, and commit fixes which will break at a later date). = I=E2=80=99ve been bitten by this once because I don=E2=80=99t run = ancient CURRENT/STABLE (r279198) and here are a couple follow up commits = bumping tools versions in the past (e.g. r278975, r269662, etc). Just a thought. --Apple-Mail=_1C5F7134-B97F-42BF-B72B-E50955C0869B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7ixyAAoJEMZr5QU6S73ei5kIALCuBD8MD1Lui/ZZ+mYXniEd XNSfptMmwZoFPZPWQkCYoBuwi0toli2BkQuybp9o4cMpSWkaFjCsJRMrpco8iUw7 yqMDTxMfGxjdVP9IE9trCaAJbT46lyxM4h84pbeMo0+AF3kDgT7TNhFvght5RNoc F4r9hqLkbSEnvP9GUmg1Y+mQOe6jZmdS5UyMFflZoOMG0LEdDYFlOuc6YNf/pe9z nzqMlBEMrBjPLRlT1goDNmNULOUjP7TioiCdHAc5JaFyxjuNn5X/qyIgCyixsCNi /aFX0qEytUvAkMXNJUZeRj8aEjVFqYi7xEYxX4F8C1mT88wj4lcypSfL5WZWNHg= =vSjg -----END PGP SIGNATURE----- --Apple-Mail=_1C5F7134-B97F-42BF-B72B-E50955C0869B-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 20:15:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F0E6A23; Wed, 25 Feb 2015 20:15:39 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 9854C20A3; Wed, 25 Feb 2015 20:15:37 +0000 (UTC) Message-ID: <54EE2D68.9050209@FreeBSD.org> Date: Wed, 25 Feb 2015 15:15:36 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 20:15:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 14:59, Arseny Nasokin wrote: > On 25 February 2015 at 22:14, Jung-uk Kim > wrote: > > On 02/25/2015 14:05, Glen Barber wrote: >> On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: >>> On 25 February 2015 at 20:27, Jung-uk Kim > >>> wrote: >>>> Your installed yacc(1) is too old, i.e., your world was >>>> built from head before r274460. FYI, this commit fixes the >>>> above problem for building from stable: >>>> >>>> https://svnweb.freebsd.org/changeset/base/278975 >>>> >>>> For building from old head (pre-r274460), you have to >>>> manually bootstrap yacc first, e.g., something like this: >>>> >>>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && >>>> make install make clean cleandepend cd /usr/src make >>>> buildworld >>>> >>> >>> Hi, guys, >>> >>> I've found the fix by forcing to add yacc(1) to bootstrap >>> build. >>> >>> Makefile.inc1, line 1277: >>> >>> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ >>> >>> change to: >>> >>> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes >>> only!!! _yacc= lib/liby \ >>> > >> This can be set to 1001507 now; __FreeBSD_version was bumped >> earlier today. > > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 > and __FreeBSD_version was bumped to reflect it. > > https://svnweb.freebsd.org/changeset/base/277087 > > Jung-uk Kim > > > Jung, > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > invalid YACC. So This conditional expression must be fixed to check > if this 11.x and yacc is not changed. Wow, that's more than 9-month old now. > In my hypothetical "patch" I set OSRELDATE to invalid abstract > future version, because it's only concept and I have no time to fix > it correctly now. If you insist, you can try this: - --- Makefile.inc1 +++ Makefile.inc1 @@ -1274,7 +1274,8 @@ _awk= usr.bin/awk .endif - -.if ${BOOTSTRAPPING} < 1001506 +.if ${BOOTSTRAPPING} < 1001506 || \ + (${BOOTSTRAPPING} >= 1100000 && ${BOOTSTRAPPING} < 1100046) _yacc= lib/liby \ usr.bin/yacc (but I won't commit it.) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897 7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF 1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4= =3xA9 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 20:38:28 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 201D53D5; Wed, 25 Feb 2015 20:38:28 +0000 (UTC) Received: from frv27.fwdcdn.com (frv158.fwdcdn.com [212.42.77.158]) (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 CE27F3D9; Wed, 25 Feb 2015 20:38:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=7v7BQC/4iohbiuxo6ShTc789OjKpXdQsKZgaZ58tWr4=; b=cqsTk0ZWtKULoywiP08nERW1bWr3jjYEAlS7Ub9PFyJuoV81zziVlw0q5VfGdhld47HqvzpE2DnjIiD44qjw5aKTnRosgPVutmGNzyL0mAmzGpfUdG29c/PtJG1T1qohHXwUPx3neoM3oyxe6kqFWGohkpv6KTi8X+WbYttXk0I=; Received: from [5.248.241.121] (helo=nonamehost.local) by frv27.fwdcdn.com with esmtpsa ID 1YQiit-000LmY-6V ; Wed, 25 Feb 2015 22:38:23 +0200 Date: Wed, 25 Feb 2015 22:38:22 +0200 From: Ivan Klymenko To: Jung-uk Kim Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150225223822.586b7571@nonamehost.local> In-Reply-To: <54EE05EA.3030509@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=5.248.241.121; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net Cc: Glen Barber , Arseny Nasokin , Allan Jude , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 20:38:28 -0000 =D0=92 Wed, 25 Feb 2015 12:27:06 -0500 Jung-uk Kim =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 02/25/2015 11:22, Ivan Klymenko wrote: > > =D0=92 Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber > > =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: > >>> I have clean svn tree with base/head branch. I try to build > >>> world, but I have some mysterious bugs. The latest is yacc > >>> failed to make c file on phase 4.3: > >>>=20 > >>> =3D=3D=3D> usr.sbin/acpi/iasl (depend) m4 -P=20 > >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler > >>> > >>>=20 > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslp= arser.y > >>>> aslcompiler.y > >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: > >>> 89 shift/reduce conflicts. yacc: f - maximum table size > >>> exceeded *** Error code 2 > >>>=20 > >>> /etc/make.conf is /dev/null. I've also tried empty > >>> /etc/src.conf with no luck. > >>>=20 > >>=20 > >> Out of curiosity, is your src tree mounted via NFS? > >>=20 > >> Glen > >>=20 > >=20 > > I have a similar problem on revision /usr/src # svn info Path: .=20 > > Working Copy Root Path: /usr/src URL: > > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository > > Root: svn://svn.freebsd.org/base Repository UUID: > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: > > directory Schedule: normal Last Changed Author: glebius Last > > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 > > (Mon, 23 Feb 2015) > >=20 > > http://pastebin.com/FuAUkBmX > >=20 > > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME > > USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G > > /usr/src > >=20 > > what is most surprising, the same revision successfully building > > for the other 2 computers, including amd64|zfs and i386|ufs. >=20 > Your installed yacc(1) is too old, i.e., your world was built from > head before r274460. FYI, this commit fixes the above problem for > building from stable: >=20 > https://svnweb.freebsd.org/changeset/base/278975 >=20 > For building from old head (pre-r274460), you have to manually > bootstrap yacc first, e.g., something like this: >=20 > cd /usr/src/usr.bin/yacc > make clean cleandepend > make all && make install > make clean cleandepend > cd /usr/src > make buildworld >=20 Thank you - it solved the problem. From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 20:47:21 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E61A651; Wed, 25 Feb 2015 20:47:21 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4477C6B8; Wed, 25 Feb 2015 20:47:21 +0000 (UTC) Received: by pabkx10 with SMTP id kx10so8092247pab.0; Wed, 25 Feb 2015 12:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1DHlB7f1+d/Rx3cOiPFLa0WcOyKsfWeui+6qaFwG+TM=; b=aXW1C1Tzh2GWmbT2zoHrXW1+2d065ezJv9Ox4NoBJF0Vjkw53EsyLQ64rJd3fQgD2i UQ25y1di/2ax/Ba1wsD/7GbyFMVxPxJEe36KdPvEtr+4O741mXuIgOXr12DOfe8F4uDR czrLJpHWRpCbhdMp81ipN/8HbzyuJrehzJwauwPSqS3FEqOVcKB4Z5vANm657eAMOZgS ZZsEMMlM6XIvuu8ihNCcQYRdQXzkg7th86/4exoVVZxdoArUWoDHK/NR81KCeT/2PK+P xkTeg4rHxdIxFrbXtFLqeuBrg2f1l1CeNyqR9/252wF5tnqTHCdcHkaeeoI21TWQ3D2p RcOw== X-Received: by 10.66.55.104 with SMTP id r8mr8458752pap.75.1424897240641; Wed, 25 Feb 2015 12:47:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.232.9 with HTTP; Wed, 25 Feb 2015 12:47:00 -0800 (PST) In-Reply-To: <54EE2D68.9050209@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> <54EE2D68.9050209@FreeBSD.org> From: Arseny Nasokin Date: Thu, 26 Feb 2015 00:47:00 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 20:47:21 -0000 On 25 February 2015 at 23:15, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/25/2015 14:59, Arseny Nasokin wrote: > > On 25 February 2015 at 22:14, Jung-uk Kim > > wrote: > > > > On 02/25/2015 14:05, Glen Barber wrote: > >> On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > >>> On 25 February 2015 at 20:27, Jung-uk Kim > > > >>> wrote: > >>>> Your installed yacc(1) is too old, i.e., your world was > >>>> built from head before r274460. FYI, this commit fixes the > >>>> above problem for building from stable: > >>>> > >>>> https://svnweb.freebsd.org/changeset/base/278975 > >>>> > >>>> For building from old head (pre-r274460), you have to > >>>> manually bootstrap yacc first, e.g., something like this: > >>>> > >>>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && > >>>> make install make clean cleandepend cd /usr/src make > >>>> buildworld > >>>> > >>> > >>> Hi, guys, > >>> > >>> I've found the fix by forcing to add yacc(1) to bootstrap > >>> build. > >>> > >>> Makefile.inc1, line 1277: > >>> > >>> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ > >>> > >>> change to: > >>> > >>> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes > >>> only!!! _yacc= lib/liby \ > >>> > > > >> This can be set to 1001507 now; __FreeBSD_version was bumped > >> earlier today. > > > > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 > > and __FreeBSD_version was bumped to reflect it. > > > > https://svnweb.freebsd.org/changeset/base/277087 > > > > Jung-uk Kim > > > > > > Jung, > > > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > > invalid YACC. So This conditional expression must be fixed to check > > if this 11.x and yacc is not changed. > > Wow, that's more than 9-month old now. > > > In my hypothetical "patch" I set OSRELDATE to invalid abstract > > future version, because it's only concept and I have no time to fix > > it correctly now. > > If you insist, you can try this: > > - --- Makefile.inc1 > +++ Makefile.inc1 > @@ -1274,7 +1274,8 @@ > _awk= usr.bin/awk > .endif > > - -.if ${BOOTSTRAPPING} < 1001506 > +.if ${BOOTSTRAPPING} < 1001506 || \ > + (${BOOTSTRAPPING} >= 1100000 && ${BOOTSTRAPPING} < 1100046) > _yacc= lib/liby \ > usr.bin/yacc > > (but I won't commit it.) > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b > G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b > RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897 > 7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj > A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF > 1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4= > =3xA9 > -----END PGP SIGNATURE----- > Thank you, It works well for me. -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:50:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1721708; Wed, 25 Feb 2015 21:50:10 +0000 (UTC) Received: from bigwig.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 84EABE1B; Wed, 25 Feb 2015 21:50:10 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0A32B945; Wed, 25 Feb 2015 16:50:08 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Date: Wed, 25 Feb 2015 16:12:24 -0500 Message-ID: <2780435.L8le27hzJU@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54EE2D68.9050209@FreeBSD.org> References: <54EE2D68.9050209@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:09 -0500 (EST) Cc: Ivan Klymenko , Glen Barber , Arseny Nasokin , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 21:50:10 -0000 On Wednesday, February 25, 2015 03:15:36 PM Jung-uk Kim wrote: > On 02/25/2015 14:59, Arseny Nasokin wrote: > > On 25 February 2015 at 22:14, Jung-uk Kim > > wrote: > > > > On 02/25/2015 14:05, Glen Barber wrote: > >> On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > >>> On 25 February 2015 at 20:27, Jung-uk Kim > > > > > > > >>> wrote: > >>>> Your installed yacc(1) is too old, i.e., your world was > >>>> built from head before r274460. FYI, this commit fixes the > >>>> above problem for building from stable: > >>>> > >>>> https://svnweb.freebsd.org/changeset/base/278975 > >>>> > >>>> For building from old head (pre-r274460), you have to > >>>> manually bootstrap yacc first, e.g., something like this: > >>>> > >>>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && > >>>> make install make clean cleandepend cd /usr/src make > >>>> buildworld > >>> > >>> Hi, guys, > >>> > >>> I've found the fix by forcing to add yacc(1) to bootstrap > >>> build. > >>> > >>> Makefile.inc1, line 1277: > >>> > >>> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ > >>> > >>> change to: > >>> > >>> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes > >>> only!!! _yacc= lib/liby \ > >> > >> This can be set to 1001507 now; __FreeBSD_version was bumped > >> earlier today. > > > > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 > > and __FreeBSD_version was bumped to reflect it. > > > > https://svnweb.freebsd.org/changeset/base/277087 > > > > Jung-uk Kim > > > > > > Jung, > > > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > > invalid YACC. So This conditional expression must be fixed to check > > if this 11.x and yacc is not changed. > > Wow, that's more than 9-month old now. > > > In my hypothetical "patch" I set OSRELDATE to invalid abstract > > future version, because it's only concept and I have no time to fix > > it correctly now. > > If you insist, you can try this: > > --- Makefile.inc1 > +++ Makefile.inc1 > @@ -1274,7 +1274,8 @@ > _awk= usr.bin/awk > .endif > > -.if ${BOOTSTRAPPING} < 1001506 > +.if ${BOOTSTRAPPING} < 1001506 || \ > + (${BOOTSTRAPPING} >= 1100000 && ${BOOTSTRAPPING} < 1100046) > _yacc= lib/liby \ > usr.bin/yacc > > (but I won't commit it.) Maybe just make the check always be < 1100046? It doesn't really hurt to build yacc on more recent 10 stable does it? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:50:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAFFE70C for ; Wed, 25 Feb 2015 21:50:10 +0000 (UTC) Received: from bigwig.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 A2E31E1E for ; Wed, 25 Feb 2015 21:50:10 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7AD91B98D; Wed, 25 Feb 2015 16:50:09 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 16:09:50 -0500 Message-ID: <2325330.KVXNRWzZVg@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:09 -0500 (EST) Cc: Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 21:50:10 -0000 On Wednesday, February 25, 2015 10:19:32 AM Chris H wrote: > On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" wrote > > > On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" > > wrote > > > > I see somebody also reported something along these lines, recently; > > http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu > > ot- on-poweroff-td5989901.html > > > > But there was no reported resolution. > > and again in January, as well. > https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html > > Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN > in the GENERIC that is installed, outside of building a new > kernel? The VFS ones are more complicated. You can add options 'WITNESS_NO_VNODE' to your kernel config to limit the noise. (Someone should turn that into a sysctl/tunable so it can be enabled in a stock kernel.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:50:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDEBB70D for ; Wed, 25 Feb 2015 21:50:11 +0000 (UTC) Received: from bigwig.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 9619BE2A for ; Wed, 25 Feb 2015 21:50:11 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93F56B990; Wed, 25 Feb 2015 16:50:10 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: msk0 watchdog timeout Marvel 88E8071 Date: Wed, 25 Feb 2015 15:57:48 -0500 Message-ID: <2913526.jiKDxkEzQI@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54EADE18.3030804@gmail.com> References: <54EADE18.3030804@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:10 -0500 (EST) Cc: David Demelier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 21:50:11 -0000 On Monday, February 23, 2015 09:00:24 AM David Demelier wrote: > Le 21/02/2015 23:46, Roosevelt Littleton a =E9crit : > > My msk0 is not even functional and my wifi is my only usable connec= tion to > > the internet. >=20 > I have the same problem with my Marvell Yukon 2. Working fine in 10.0= , > now broken in 10.1. Can you narrow down the commit that broke it for you? I know there wer= e some=20 msk(4) changes merged between 10.0 and 10.1 that fixed msk(4) for some = other=20 folks. --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:50:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A33579A; Wed, 25 Feb 2015 21:50:12 +0000 (UTC) Received: from bigwig.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 6032BE2B; Wed, 25 Feb 2015 21:50:12 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5269AB9A5; Wed, 25 Feb 2015 16:50:11 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC] load network config file from netif init script Date: Wed, 25 Feb 2015 15:34:43 -0500 Message-ID: <2035871.YPhCQEXjlG@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54CF6BBF.9050906@FreeBSD.org> References: <54CF6BBF.9050906@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:11 -0500 (EST) Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 21:50:12 -0000 On Monday, February 02, 2015 12:21:19 PM Roger Pau Monn=E9 wrote: > Hello, >=20 > r272959 broke compatibility with mfsBSD that stores the default netwo= rk > config file in /etc/rc.conf.d/network. In order to fix that load the > network config file from netif also. >=20 > I'm attaching a patch to restore previous functionality, but since I'= m > not an expert on rc.d init scripts I would like some feedback on whet= her > this is the right approach or not. >=20 > Thanks, Roger. If you are still looking for review, you can try freebsd-rc@ perhaps? --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:58:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52BF778 for ; Wed, 25 Feb 2015 21:58:54 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06B88F0D for ; Wed, 25 Feb 2015 21:58:54 +0000 (UTC) Received: by iecar1 with SMTP id ar1so9021936iec.0 for ; Wed, 25 Feb 2015 13:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4iLpyUCfmk8Oc8Gx1x4bczBLtrUUahEmYdP8c1It1zE=; b=ahJn0ejhDHk2XWNXCd8MbfRtPlmKjbc7Drr1lxNMCs8/K39VnxUSQHcZtCQXrbn1iI pyJ9TGOZwbPJ2A1GzstbdG8uLHYxYY/5n05VFpm472c+Q04zzROw8pPi2RVurkCoIJ+D 1jWWmZ+v2NhkBisYmKeOHt/VMQQ/1eTGihDGI7gEktIuGbbpoxhPywtF7q1NPndUAdSY y5KK/SAg2fJZsRQx4dZLYY6+KVqBnnvR30XjLgz1yrTpFYd9hX/T5gOor0vTbad42Bum rz86ZMNimrGNORXgJoKmS2OHmDbSiT0Wp+sHiKvfCnXGeW3m1JRuY+FZq3HtESC10Kao NCUA== MIME-Version: 1.0 X-Received: by 10.107.25.72 with SMTP id 69mr7941791ioz.44.1424901533301; Wed, 25 Feb 2015 13:58:53 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 25 Feb 2015 13:58:53 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> Date: Wed, 25 Feb 2015 13:58:53 -0800 X-Google-Sender-Auth: wJxIgpJRA5xzl7SLGBTrTVZwDm8 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 21:58:54 -0000 On Tue, Feb 24, 2015 at 6:05 PM, Miguel Clara wrote: > > > On Wed, Feb 25, 2015 at 1:58 AM, Miguel Clara > wrote: > >> >> On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara >> wrote: >> >>> >>> On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman >>> wrote: >>> >>>> On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara >>>> wrote: >>>> >>>>> On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper >>>> > >>>>> wrote: >>>>> >>>>> > On Feb 24, 2015, at 6:35, Miguel Clara >>>>> wrote: >>>>> > >>>>> > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null >>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>> provision >>>>> > `kerberos' >>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>> provision >>>>> > `named' >>>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before >>>>> unknown >>>>> > provision `unbound' >>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd= '. >>>>> > > rcorder: Circular dependency on provision `dbus' in file >>>>> > `/usr/local/etc/rc.d/webcamd'. >>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/devfs'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/mdconfig2'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/newsyslog'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/syslogd'. >>>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>>> > `/etc/rc.d/kdc'. >>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>> > `/etc/rc.d/SERVERS'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/archdep'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/SERVERS'. >>>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' ha= s >>>>> no >>>>> > providers. >>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' ha= s >>>>> no >>>>> > providers. >>>>> > > >>>>> > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk >>>>> > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80=99 >>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>> provision >>>>> > `kerberos' >>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>> provision >>>>> > `named' >>>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before >>>>> unknown >>>>> > provision `unbound' >>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd= '. >>>>> > > rcorder: Circular dependency on provision `dbus' in file >>>>> > `/usr/local/etc/rc.d/webcamd'. >>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/devfs'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/mdconfig2'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/newsyslog'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/syslogd'. >>>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>>> > `/etc/rc.d/kdc'. >>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>> > `/etc/rc.d/SERVERS'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/archdep'. >>>>> > > rcorder: Circular dependency on provision `mountcritremote' in fi= le >>>>> > `/etc/rc.d/SERVERS'. >>>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' ha= s >>>>> no >>>>> > providers. >>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' ha= s >>>>> no >>>>> > providers. >>>>> > > cleanvar: Command not found. >>>>> > > dbus/: Command not found. >>>>> > > >>>>> > > Note that this is still with the change to dnscrypt-ptoxy REQUIRE >>>>> > (adding ldconfig) >>>>> > >>>>> > Your rcorder is 50 shades of broken :(. Please remove all local >>>>> > modifications to scripts, then repost the output of the rcorder >>>>> commands >>>>> > again. I suspect what=E2=80=99s going wrong is the result of some o= f my >>>>> changes to >>>>> > remove etc/rc.d based on build knobs=E2=80=A6 >>>>> > Cheers, >>>>> > >>>>> >>>>> So much like the movies them... damn.... :X >>>>> >>>>> I don't recall any changes to the rc.d scripts except the one to >>>>> dnscrypt-proxy (adding the ldconfig REQUIRE) >>>>> >>>>> I also don't really know what to make of the output... expect this >>>>> part: >>>>> >>>>> "Circular dependency on provision", but the man says: >>>>> A set of files has a circular dependency which was detected while >>>>> processing the stated condition. >>>>> >>>>> So it should mean that 'A' requires 'B' but 'B' requires 'A'... but >>>>> this >>>>> does not seem to be the case... >>>>> >>>>> I guess I'll have to go one by one and see if I can identify issue. B= ut >>>>> first I'll make sure the ports that use those rc.d scripts are up to >>>>> date. >>>>> >>>> >>>> Just to save a bit of time, many RC scripts are messed up at install >>>> time. >>>> >>>> One of the worst I have is for security/trousers-tddl. It is a mess. I= t >>>> wants kerberos and named, but most FreeBSD systems no longer run named= or >>>> kerberos. As far as I can tell, no FreeBSD port provides a tpmd, so I = have >>>> no idea where the heck that comes from. >>>> >>>> hald wants usbd which has been obsolete for some years. Certainly no >>>> providers any longer. I don't think that any supported version of Free= BSD >>>> still has usbd, so any port requiring it should be fixed. >>>> >>>> Also, webcamd and dbus have a circular dependency. It really needs to >>>> be fixed some time, but does not break anything. >>>> >>>> I suspect that whatever is causing the multiple circular dependencies >>>> on mountcritremote might be tied to the issue. I don't see the obvious >>>> problem here and I don't have it. Circular dependencies are a real pai= n to >>>> track down as they are often not direct. A required E and G and B requ= ires >>>> A. But the rcorder only knows that. It does not report that E does req= uire >>>> B and just reports that A is a circular dependency. (I hope that makes= some >>>> sense.) >>>> >>>> Normally mountcritremote should be very soon after NETWORKING...usuall= y >>>> after NETWORKING and netwait. This means it should run right after the >>>> network starts and before anything that depends on the network. >>>> rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this with >>>> ldconfig right after mountcritremote. There is no reason that devfs, >>>> syslogd or any of the others listed should precede mountcritremote! Th= e >>>> errors indicate that SOMETHING before NETWORKING and netwait is causin= g all >>>> of these other things to run and, BOOM, your script is firing off befo= re >>>> ldconfig is run. >>>> >>>> Good luck! It will likely be tedious, but looking at the output of >>>> rcorder should point the finger in at least the right direction. Hete = is an >>>> exerpt from mine in the area where these things belong: >>>> /etc/rc.d/NETWORKING >>>> /etc/rc.d/netwait >>>> /etc/rc.d/mountcritremote >>>> /etc/rc.d/ldconfig >>>> /etc/rc.d/accounting >>>> /etc/rc.d/newsyslog >>>> /etc/rc.d/syslogd >>>> /etc/rc.d/ntpdate >>>> /etc/rc.d/rpcbind >>>> /etc/rc.d/nfsclient >>>> /etc/rc.d/devfs >>>> /etc/rc.d/ipmon >>>> /etc/rc.d/mdconfig2 >>>> /etc/rc.d/kdc >>>> >>> >>> Kevin... many thanks, for this I was really thinking the same... "I jus= t >>> installed the ports and the system was upgrade properly WTH did I do wr= ong". >>> >>> I've reinstalled the the ports of the affected scripts to be sure I'm >>> running the most updated version, I still see the issues so now I'lll h= ave >>> to go one by one and see if I can fix them, or maybe start by moving th= em >>> elsewhere and run rcorder until its happy and then move back one by one= and >>> rcorder should start complaining... >>> >>> But just so I try to understand this better.... dbus and webcamd have a >>> circular dependency... is this beacause: >>> webcamd requires "FILESYSTEMS netif dbus" >>> dbus requires "DAEMON ldconfig" >>> >>> And then ldconfig also requires FILESYSTEMS? >>> >>> >>> >> Acctaully dnscrypt-proxy is running just after SERVERS and this requires >> ldconfig but does not run it before... Example: >> >> etc/rc.d/netif >> /etc/rc.d/devd >> /etc/rc.d/ipsec >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/devfs'. >> /etc/rc.d/devfs >> /etc/rc.d/ipmon >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/mdconfig2'. >> /etc/rc.d/mdconfig2 >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/newsyslog'. >> /etc/rc.d/newsyslog >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/syslogd'. >> /etc/rc.d/syslogd >> rcorder: Circular dependency on provision `NETWORKING' in file >> `/etc/rc.d/kdc'. >> /etc/rc.d/kdc >> /etc/rc.d/watchdogd >> /etc/rc.d/savecore >> rcorder: Circular dependency on provision `ldconfig' in file >> `/etc/rc.d/SERVERS'. >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/archdep'. >> /etc/rc.d/archdep >> /etc/rc.d/abi >> rcorder: Circular dependency on provision `mountcritremote' in file >> `/etc/rc.d/SERVERS'. >> /etc/rc.d/SERVERS >> /usr/local/etc/rc.d/dnscrypt-proxy >> /etc/rc.d/resolv >> /etc/rc.d/local_unbound >> /etc/rc.d/atm2 >> /etc/rc.d/pfsync >> /etc/rc.d/pflog >> /etc/rc.d/pf >> /etc/rc.d/stf >> /etc/rc.d/ppp >> /etc/rc.d/routing >> /etc/rc.d/mroute6d >> /etc/rc.d/nsswitch >> /etc/rc.d/rtsold >> /etc/rc.d/static_ndp >> /etc/rc.d/static_arp >> /etc/rc.d/bridge >> /etc/rc.d/route6d >> /etc/rc.d/routed >> /etc/rc.d/defaultroute >> /etc/rc.d/ipfw >> /etc/rc.d/NETWORKING >> >> >> If I just leave SERVERS out of dnscrypt-proxy the order seems ok (not >> sure if perfect). >> SERVERS now runs after NETWORKING, and still runs because DEAMON require= s >> SERVERS and a bunch of the rc.d's require DEAMON ofc... >> >> Now its more like this (just shoing some to proof dnscrypt-proxy is >> better placed now: >> % rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | egrep >> "SERVERS|ldconfig|dnscrypt|DAEMON|NETWORKING|FILESYSTEMS|sshd" >> rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> `kerberos' >> rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >> `named' >> rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >> rcorder: Circular dependency on provision `dbus' in file >> `/usr/local/etc/rc.d/webcamd'. >> rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >> rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no >> providers. >> /etc/rc.d/FILESYSTEMS >> /etc/rc.d/NETWORKING >> /etc/rc.d/ldconfig >> /etc/rc.d/SERVERS >> /etc/rc.d/DAEMON >> /etc/rc.d/sshd >> /usr/local/etc/rc.d/dnscrypt-proxy >> >> >> So basically if SERVERS is required by dnscrypt-proxy ldconfig (and >> others) complain about "Circular dependency" issues and don't run, I hav= e >> no idea why, but could somebody try to replicate the issue in freebsd >> current (by installing dnscrypt-proxy I mean)? >> >> thanks >> >> > Actually I have another box with Current: > > I can not reproduce the issue, dnscrypt and SERVERS have the same in > "REQUIRE" > > The order machine as a older kernel/world version: > > FreeBSD hpbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #7 b6a4dfa(master)-dirty: > Tue Feb 10 22:21:46 WET 2015 root@hpbsd:/usr/obj/usr/src/sys/GENERIC-= NODEBUG > amd > > > FreeBSD r2d2 11.0-CURRENT FreeBSD 11.0-CURRENT #9 > r279098+c2ec8fb(master)-dirty <--- this is the one where I see the issue! > Sorry for being slow to respond. I've been a bit busy. Oddly, being retired does not seem to give me much more free time.) I see a clear issue in the devfs startup. It comes innediately after ipsec which has: # BEFORE: DAEMON mountcritremote while devfs has: # REQUIRE: mountcritremote I can't figure out why devfs is being started here, but it is wrong! Clearly, mountcritremote is not provided at this point. Still, thi is a side issue. I can say that dns/dnscrypt-proxy is broken as it has: # REQUIRE: SERVERS cleanvar # BEFORE: named local_unbound unbound dnscrypt-proxy -->SERVERS -->mountcritremote -->NETWORKING -->local_unbound (but dnscrypt-proxy must be before local_unbound! ("-->" means requires) So it has to come after SERVERS but before local_unbound. But NETWORKING depends on local_unbound they are both dependent on NEWORKING which has to be after SERVERS. Can you say fubar! Clearly broken. And this means that removing SERVERS will re-shuffle the order more appropriately. It seems that the behavior of rcorder is not as documented as well as being undefined when circular dependencies occur. The man page says that rcorder aborts when it encounters a circular dependency, but that is not the case. It probably is best that it not die, but that leaves things in an unknown and inconsistant state, which is also a very bad idea. I guess when a circular dependency is encountered, a dichotomy occurs. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 22:19:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02FEF249 for ; Wed, 25 Feb 2015 22:19:52 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB50B218 for ; Wed, 25 Feb 2015 22:19:51 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id l13so39499842iga.5 for ; Wed, 25 Feb 2015 14:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ukSPhy/IUfHQzI3oMK9BE50Zk4z/JrEG4/qZjZH9B18=; b=C7ja/bTPW9+riCU2LD6L6dyYNVTocsTXuVR/RwiKhxClccwNOevOHRr1GnbjvmYtUn QsQ4uDq/sVwOcizvCDvhQH3LcToVAIp/5vGTj+Wb+KE0tl9X9pELjHvKNd9Gby4uo4bS KTAAc/J8NDRiPgMDDmRu1MRDdb1JWIh4mJHBJBwVXipn/YBhd1ZJimmSL3sNxG5IbnE4 +KKSK2GdU+2G5VK0wXUc+UnALaBK/7gyvBPohI/ovAzucChXzq5i42ULQveUebEdYdPE vsWzYZRvec04J0I9TrlyCJ9OcMep2mQK99hFBkDIF+m6X11xumDXcuZp33KjWaT5+6WF qTGw== X-Received: by 10.42.229.10 with SMTP id jg10mr6432909icb.62.1424902791137; Wed, 25 Feb 2015 14:19:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.120.35 with HTTP; Wed, 25 Feb 2015 14:19:30 -0800 (PST) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> From: Miguel Clara Date: Wed, 25 Feb 2015 22:19:30 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 22:19:52 -0000 On Wed, Feb 25, 2015 at 9:58 PM, Kevin Oberman wrote: > On Tue, Feb 24, 2015 at 6:05 PM, Miguel Clara > wrote: > >> >> >> On Wed, Feb 25, 2015 at 1:58 AM, Miguel Clara >> wrote: >> >>> >>> On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara >>> wrote: >>> >>>> >>>> On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman >>>> wrote: >>>> >>>>> On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara >>>> > wrote: >>>>> >>>>>> On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper < >>>>>> yaneurabeya@gmail.com> >>>>>> wrote: >>>>>> >>>>>> > On Feb 24, 2015, at 6:35, Miguel Clara >>>>>> wrote: >>>>>> > >>>>>> > > ]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* >/dev/null >>>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>>> provision >>>>>> > `kerberos' >>>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>>> provision >>>>>> > `named' >>>>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before >>>>>> unknown >>>>>> > provision `unbound' >>>>>> > > rcorder: Circular dependency on file >>>>>> `/usr/local/etc/rc.d/webcamd'. >>>>>> > > rcorder: Circular dependency on provision `dbus' in file >>>>>> > `/usr/local/etc/rc.d/webcamd'. >>>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/devfs'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/mdconfig2'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/newsyslog'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/syslogd'. >>>>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>>>> > `/etc/rc.d/kdc'. >>>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>>> > `/etc/rc.d/SERVERS'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/archdep'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/SERVERS'. >>>>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' >>>>>> has no >>>>>> > providers. >>>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'= . >>>>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' >>>>>> has no >>>>>> > providers. >>>>>> > > >>>>>> > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk >>>>>> > =E2=80=98/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }=E2=80= =99 >>>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>>> provision >>>>>> > `kerberos' >>>>>> > > rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown >>>>>> provision >>>>>> > `named' >>>>>> > > rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before >>>>>> unknown >>>>>> > provision `unbound' >>>>>> > > rcorder: Circular dependency on file >>>>>> `/usr/local/etc/rc.d/webcamd'. >>>>>> > > rcorder: Circular dependency on provision `dbus' in file >>>>>> > `/usr/local/etc/rc.d/webcamd'. >>>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>>> > `/usr/local/etc/rc.d/dnscrypt-proxy'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/devfs'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/mdconfig2'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/newsyslog'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/syslogd'. >>>>>> > > rcorder: Circular dependency on provision `NETWORKING' in file >>>>>> > `/etc/rc.d/kdc'. >>>>>> > > rcorder: Circular dependency on provision `ldconfig' in file >>>>>> > `/etc/rc.d/SERVERS'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/archdep'. >>>>>> > > rcorder: Circular dependency on provision `mountcritremote' in >>>>>> file >>>>>> > `/etc/rc.d/SERVERS'. >>>>>> > > rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' >>>>>> has no >>>>>> > providers. >>>>>> > > rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'= . >>>>>> > > rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' >>>>>> has no >>>>>> > providers. >>>>>> > > cleanvar: Command not found. >>>>>> > > dbus/: Command not found. >>>>>> > > >>>>>> > > Note that this is still with the change to dnscrypt-ptoxy REQUIR= E >>>>>> > (adding ldconfig) >>>>>> > >>>>>> > Your rcorder is 50 shades of broken :(. Please remove all local >>>>>> > modifications to scripts, then repost the output of the rcorder >>>>>> commands >>>>>> > again. I suspect what=E2=80=99s going wrong is the result of some = of my >>>>>> changes to >>>>>> > remove etc/rc.d based on build knobs=E2=80=A6 >>>>>> > Cheers, >>>>>> > >>>>>> >>>>>> So much like the movies them... damn.... :X >>>>>> >>>>>> I don't recall any changes to the rc.d scripts except the one to >>>>>> dnscrypt-proxy (adding the ldconfig REQUIRE) >>>>>> >>>>>> I also don't really know what to make of the output... expect this >>>>>> part: >>>>>> >>>>>> "Circular dependency on provision", but the man says: >>>>>> A set of files has a circular dependency which was detected while >>>>>> processing the stated condition. >>>>>> >>>>>> So it should mean that 'A' requires 'B' but 'B' requires 'A'... but >>>>>> this >>>>>> does not seem to be the case... >>>>>> >>>>>> I guess I'll have to go one by one and see if I can identify issue. >>>>>> But >>>>>> first I'll make sure the ports that use those rc.d scripts are up to >>>>>> date. >>>>>> >>>>> >>>>> Just to save a bit of time, many RC scripts are messed up at install >>>>> time. >>>>> >>>>> One of the worst I have is for security/trousers-tddl. It is a mess. >>>>> It wants kerberos and named, but most FreeBSD systems no longer run n= amed >>>>> or kerberos. As far as I can tell, no FreeBSD port provides a tpmd, s= o I >>>>> have no idea where the heck that comes from. >>>>> >>>>> hald wants usbd which has been obsolete for some years. Certainly no >>>>> providers any longer. I don't think that any supported version of Fre= eBSD >>>>> still has usbd, so any port requiring it should be fixed. >>>>> >>>>> Also, webcamd and dbus have a circular dependency. It really needs to >>>>> be fixed some time, but does not break anything. >>>>> >>>>> I suspect that whatever is causing the multiple circular dependencies >>>>> on mountcritremote might be tied to the issue. I don't see the obviou= s >>>>> problem here and I don't have it. Circular dependencies are a real pa= in to >>>>> track down as they are often not direct. A required E and G and B req= uires >>>>> A. But the rcorder only knows that. It does not report that E does re= quire >>>>> B and just reports that A is a circular dependency. (I hope that make= s some >>>>> sense.) >>>>> >>>>> Normally mountcritremote should be very soon after >>>>> NETWORKING...usually after NETWORKING and netwait. This means it shou= ld run >>>>> right after the network starts and before anything that depends on th= e >>>>> network. >>>>> rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | less should show this wit= h >>>>> ldconfig right after mountcritremote. There is no reason that devfs, >>>>> syslogd or any of the others listed should precede mountcritremote! T= he >>>>> errors indicate that SOMETHING before NETWORKING and netwait is causi= ng all >>>>> of these other things to run and, BOOM, your script is firing off bef= ore >>>>> ldconfig is run. >>>>> >>>>> Good luck! It will likely be tedious, but looking at the output of >>>>> rcorder should point the finger in at least the right direction. Hete= is an >>>>> exerpt from mine in the area where these things belong: >>>>> /etc/rc.d/NETWORKING >>>>> /etc/rc.d/netwait >>>>> /etc/rc.d/mountcritremote >>>>> /etc/rc.d/ldconfig >>>>> /etc/rc.d/accounting >>>>> /etc/rc.d/newsyslog >>>>> /etc/rc.d/syslogd >>>>> /etc/rc.d/ntpdate >>>>> /etc/rc.d/rpcbind >>>>> /etc/rc.d/nfsclient >>>>> /etc/rc.d/devfs >>>>> /etc/rc.d/ipmon >>>>> /etc/rc.d/mdconfig2 >>>>> /etc/rc.d/kdc >>>>> >>>> >>>> Kevin... many thanks, for this I was really thinking the same... "I >>>> just installed the ports and the system was upgrade properly WTH did I= do >>>> wrong". >>>> >>>> I've reinstalled the the ports of the affected scripts to be sure I'm >>>> running the most updated version, I still see the issues so now I'lll = have >>>> to go one by one and see if I can fix them, or maybe start by moving t= hem >>>> elsewhere and run rcorder until its happy and then move back one by on= e and >>>> rcorder should start complaining... >>>> >>>> But just so I try to understand this better.... dbus and webcamd have = a >>>> circular dependency... is this beacause: >>>> webcamd requires "FILESYSTEMS netif dbus" >>>> dbus requires "DAEMON ldconfig" >>>> >>>> And then ldconfig also requires FILESYSTEMS? >>>> >>>> >>>> >>> Acctaully dnscrypt-proxy is running just after SERVERS and this require= s >>> ldconfig but does not run it before... Example: >>> >>> etc/rc.d/netif >>> /etc/rc.d/devd >>> /etc/rc.d/ipsec >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/devfs'. >>> /etc/rc.d/devfs >>> /etc/rc.d/ipmon >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/mdconfig2'. >>> /etc/rc.d/mdconfig2 >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/newsyslog'. >>> /etc/rc.d/newsyslog >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/syslogd'. >>> /etc/rc.d/syslogd >>> rcorder: Circular dependency on provision `NETWORKING' in file >>> `/etc/rc.d/kdc'. >>> /etc/rc.d/kdc >>> /etc/rc.d/watchdogd >>> /etc/rc.d/savecore >>> rcorder: Circular dependency on provision `ldconfig' in file >>> `/etc/rc.d/SERVERS'. >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/archdep'. >>> /etc/rc.d/archdep >>> /etc/rc.d/abi >>> rcorder: Circular dependency on provision `mountcritremote' in file >>> `/etc/rc.d/SERVERS'. >>> /etc/rc.d/SERVERS >>> /usr/local/etc/rc.d/dnscrypt-proxy >>> /etc/rc.d/resolv >>> /etc/rc.d/local_unbound >>> /etc/rc.d/atm2 >>> /etc/rc.d/pfsync >>> /etc/rc.d/pflog >>> /etc/rc.d/pf >>> /etc/rc.d/stf >>> /etc/rc.d/ppp >>> /etc/rc.d/routing >>> /etc/rc.d/mroute6d >>> /etc/rc.d/nsswitch >>> /etc/rc.d/rtsold >>> /etc/rc.d/static_ndp >>> /etc/rc.d/static_arp >>> /etc/rc.d/bridge >>> /etc/rc.d/route6d >>> /etc/rc.d/routed >>> /etc/rc.d/defaultroute >>> /etc/rc.d/ipfw >>> /etc/rc.d/NETWORKING >>> >>> >>> If I just leave SERVERS out of dnscrypt-proxy the order seems ok (not >>> sure if perfect). >>> SERVERS now runs after NETWORKING, and still runs because DEAMON >>> requires SERVERS and a bunch of the rc.d's require DEAMON ofc... >>> >>> Now its more like this (just shoing some to proof dnscrypt-proxy is >>> better placed now: >>> % rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | egrep >>> "SERVERS|ldconfig|dnscrypt|DAEMON|NETWORKING|FILESYSTEMS|sshd" >>> rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >>> `kerberos' >>> rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision >>> `named' >>> rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'. >>> rcorder: Circular dependency on provision `dbus' in file >>> `/usr/local/etc/rc.d/webcamd'. >>> rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'. >>> rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has no >>> providers. >>> /etc/rc.d/FILESYSTEMS >>> /etc/rc.d/NETWORKING >>> /etc/rc.d/ldconfig >>> /etc/rc.d/SERVERS >>> /etc/rc.d/DAEMON >>> /etc/rc.d/sshd >>> /usr/local/etc/rc.d/dnscrypt-proxy >>> >>> >>> So basically if SERVERS is required by dnscrypt-proxy ldconfig (and >>> others) complain about "Circular dependency" issues and don't run, I ha= ve >>> no idea why, but could somebody try to replicate the issue in freebsd >>> current (by installing dnscrypt-proxy I mean)? >>> >>> thanks >>> >>> >> Actually I have another box with Current: >> >> I can not reproduce the issue, dnscrypt and SERVERS have the same in >> "REQUIRE" >> >> The order machine as a older kernel/world version: >> >> FreeBSD hpbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #7 b6a4dfa(master)-dirty= : >> Tue Feb 10 22:21:46 WET 2015 root@hpbsd:/usr/obj/usr/src/sys/GENERIC= -NODEBUG >> amd >> >> >> FreeBSD r2d2 11.0-CURRENT FreeBSD 11.0-CURRENT #9 >> r279098+c2ec8fb(master)-dirty <--- this is the one where I see the issue= ! >> > > Sorry for being slow to respond. I've been a bit busy. Oddly, being > retired does not seem to give me much more free time.) > > I see a clear issue in the devfs startup. It comes innediately after ipse= c > which has: > # BEFORE: DAEMON mountcritremote > while devfs has: > # REQUIRE: mountcritremote > I can't figure out why devfs is being started here, but it is wrong! > Clearly, mountcritremote is not provided at this point. Still, thi is a > side issue. > > I can say that dns/dnscrypt-proxy is broken as it has: > # REQUIRE: SERVERS cleanvar > # BEFORE: named local_unbound unbound > > dnscrypt-proxy -->SERVERS -->mountcritremote -->NETWORKING > -->local_unbound (but dnscrypt-proxy must be before local_unbound! ("-->" > means requires) > I noticed this too, but in that case why doesn't it affect all users? (or all the ones using dnscrypt+local_unbound) maybe something changed in "NETWORKING" recently? Hum: https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2=3D2= 78704 Interesting, as I am using the most recent version which does not REQUIRE local_unbound I'm even more confused now :| > So it has to come after SERVERS but before local_unbound. But NETWORKING > depends on local_unbound they are both dependent on NEWORKING which has t= o > be after SERVERS. Can you say fubar! Clearly broken. And this means that > removing SERVERS will re-shuffle the order more appropriately. > > It seems that the behavior of rcorder is not as documented as well as > being undefined when circular dependencies occur. The man page says that > rcorder aborts when it encounters a circular dependency, but that is not > the case. It probably is best that it not die, but that leaves things in = an > unknown and inconsistant state, which is also a very bad idea. I guess wh= en > a circular dependency is encountered, a dichotomy occurs. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 22:30:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 969EF7FB for ; Wed, 25 Feb 2015 22:30:58 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F00C5F6 for ; Wed, 25 Feb 2015 22:30:58 +0000 (UTC) Received: by padfa1 with SMTP id fa1so8694651pad.2 for ; Wed, 25 Feb 2015 14:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pcpv29xiQoySprX39P4VeEEpE2zmEuB9NTUW9x2BMVY=; b=NYvUDqpx6PWVbdRkEL87+1R+9jv/otH5g4ix/Vudhq3nhFs2tGtHyJLRbeKDb29fSb pDSYHZKy/3UJBf/RWfIfajSDu5789FXQDLGiCwfWNPqN+xAsVEfdv4vWAkZVAfL/EYRg na8hENAgXnRDyBZqyO8kAIuOx9kC3fVtLZ7MfGpUhVlAsnJIseqB19Ck6zoTtv7mYh6B zhT+4+WTW4rb2bsaSc3jNNRH8Svnp/yGddxse+cD8GshAP0ypz+Cq9L8dcbKdDj+eyGK oHFVz3KTX65o28UzDyAIM6qSsq2JUZxXMK2DETS3/38O+4FUrAmkqYlYW1JYykjxRlvb z8GQ== X-Received: by 10.66.63.106 with SMTP id f10mr9607237pas.0.1424903457814; Wed, 25 Feb 2015 14:30:57 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id g11sm43463573pat.24.2015.02.25.14.30.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 14:30:53 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8EF2C81B-252A-4E59-85EB-19D97258E75E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Garrett Cooper In-Reply-To: Date: Wed, 25 Feb 2015 14:30:14 -0800 Message-Id: <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> To: Miguel Clara X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 22:30:58 -0000 --Apple-Mail=_8EF2C81B-252A-4E59-85EB-19D97258E75E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 25, 2015, at 14:19, Miguel Clara wrote: ... > I noticed this too, but in that case why doesn't it affect all users? = (or all the ones using dnscrypt+local_unbound) maybe something changed = in "NETWORKING" recently? >=20 > Hum: > = https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2=3D= 278704 >=20 > Interesting, as I am using the most recent version which does not = REQUIRE local_unbound=20 >=20 > I'm even more confused now :| >=20 >=20 > So it has to come after SERVERS but before local_unbound. But = NETWORKING depends on local_unbound they are both dependent on NEWORKING = which has to be after SERVERS. Can you say fubar! Clearly broken. And = this means that removing SERVERS will re-shuffle the order more = appropriately.=20 >=20 > It seems that the behavior of rcorder is not as documented as well as = being undefined when circular dependencies occur. The man page says that = rcorder aborts when it encounters a circular dependency, but that is not = the case. It probably is best that it not die, but that leaves things in = an unknown and inconsistant state, which is also a very bad idea. I = guess when a circular dependency is encountered, a dichotomy occurs. Now you know why I=92m so curious about all of this stuff. When I was working on ^/projects/building-blocks, I was able to move = most of these pieces around by changing REQUIRE: to BEFORE:, but I = noticed that it changes the rcorder a bit, so I haven=92t been super = gung ho in implementing my change. I think there are a couple bugs present on = 9-STABLE/10-STABLE/11-CURRENT: - Things go awry if named is removed/not installed. - Things go awry if local_unbound is removed (which would have been the = case if the rc.d script was removed from your system, which existed = before my changes). - Other rc.d scripts not being present might break assumptions. I need to create dummy providers for certain logical stages (DNS is one = of them) to solve part of this problem and provide third parties with a = mechanism that can be depended on (I wish applications were written in a = more robust manner to fail gracefully and retry instead of failing flat = on their face, but as I=92ve seen at several jobs, getting developers to = fail, then retry is hard :(=85). Another short-term hack: Install dummy/no-op providers so the ordering is preserved, then remove = the hacks after all of the bugs have been shaken out. Thanks! --Apple-Mail=_8EF2C81B-252A-4E59-85EB-19D97258E75E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7kz2AAoJEMZr5QU6S73eeZQH/1JxWeI2gjWjXs8IvcRQXEU9 JHehb2dlThJTe0gkvqyWlauTlZlIvNN3kHC337hqEKp2IxUNL5Byj8k/R8YC/G6w /L9yDpz0h0f72jOh7iJxFFdUvWIpLofqlIe4HNQfzuOeql+QaENIjraNoQNQeXIh 1U+y4ecoeUVDUoGgBxiSZfWQEPbtV2c+QpCzo6bw9wuU9CzvxXTw+fNEqicaLfaT yUHTbMgBurCjZ4dXxESO513stwAarS8zHRT8PNd4+PQSJzfAB4RGck/78B7IS7LI KzNEELp8l3vAQyjtF1TokStoHqmu83J1HKyqJ6pj/+3yyIYQ8hkx7my2GcZtuKc= =jzyU -----END PGP SIGNATURE----- --Apple-Mail=_8EF2C81B-252A-4E59-85EB-19D97258E75E-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 23:39:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D84B2A86; Wed, 25 Feb 2015 23:39:00 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 86662D12; Wed, 25 Feb 2015 23:39:00 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PNdd58028482; Wed, 25 Feb 2015 15:39:39 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <2325330.KVXNRWzZVg@ralph.baldwin.cx> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> <60a188b7861637d4bb7085b06f506a84@ultimatedns.net>, <2325330.KVXNRWzZVg@ralph.baldwin.cx> From: "Chris H" Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 15:39:39 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Feb 2015 23:39:00 -0000 On Wed, 25 Feb 2015 16:09:50 -0500 John Baldwin wrote > On Wednesday, February 25, 2015 10:19:32 AM Chris H wrote: > > On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" wrote > > > > > On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" > > > wrote > > > > > > I see somebody also reported something along these lines, recently; > > > > > > http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu > > > ot- on-poweroff-td5989901.html > > > > > > But there was no reported resolution. > > > > and again in January, as well. > > https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html > > > > Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN > > in the GENERIC that is installed, outside of building a new > > kernel? > > The VFS ones are more complicated. You can add options 'WITNESS_NO_VNODE' to > your kernel config to limit the noise. (Someone should turn that into a > sysctl/tunable so it can be enabled in a stock kernel.) Aside from my own concerns, I thought it might be useful for others to know, as the LOR's were produced by the kernel installed from the distribution media (disk 1). Also, in the event I'm not the *only* one experiencing these LOR's. It might be nice replace the kernel that's currently on the media, with one that won't do this. As I imagine many who install FreeBSD from the media, might never build their own. The sysctl/tunable sounds like a real winner. :) Thanks for taking the time to respond, John. --Chris > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 02:08:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8ECC9F1 for ; Thu, 26 Feb 2015 02:08:22 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C94E361 for ; Thu, 26 Feb 2015 02:08:22 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id h15so11129648igd.3 for ; Wed, 25 Feb 2015 18:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a0TePGq2700qz+CvCkPTkXjlcKKqOgIMEliPsKgBkgc=; b=caqW2koXB6RfUtmEY7+dROYc1aDkTwdpi+yHYZSm85d5QB64wUwyZmCh7L7ydYcF4p JR2LyFGzVT7J09iGVKTMoaOUdczyXdQ2uosytmTMEtn4UfpP6B7ylCc2UqOwloHCQDYE qNRQtYgzLTLCSRDShcVLiAE9VmT6LkCMTl2hx8Bxmu/GZg1cHoR1v1Sp8xwmLk4WLC0W uZIyv/XqcVm/5Hh7vCOejfFWT092qbcRDUgFSxqryJoNUDQ5pBwT2b/J536nNtnozP5o EpSNu0ntD4I8/d3iVNyRhW2TVtIsGdqLxA4TCkKFc6f6y8dyOpII2sbux4r3dylrnyUG Dr5Q== MIME-Version: 1.0 X-Received: by 10.42.170.200 with SMTP id g8mr7275577icz.5.1424916501977; Wed, 25 Feb 2015 18:08:21 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 25 Feb 2015 18:08:21 -0800 (PST) In-Reply-To: <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> Date: Wed, 25 Feb 2015 18:08:21 -0800 X-Google-Sender-Auth: vaiKkwoH-2Jp3589op52bGiWBYk Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 02:08:22 -0000 On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper wrote: > On Feb 25, 2015, at 14:19, Miguel Clara wrote: > > ... > > > I noticed this too, but in that case why doesn't it affect all users? > (or all the ones using dnscrypt+local_unbound) maybe something changed in > "NETWORKING" recently? > > > > Hum: > > > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2= =3D278704 > > > > Interesting, as I am using the most recent version which does not > REQUIRE local_unbound > > > > I'm even more confused now :| > > > > > > So it has to come after SERVERS but before local_unbound. But NETWORKIN= G > depends on local_unbound they are both dependent on NEWORKING which has t= o > be after SERVERS. Can you say fubar! Clearly broken. And this means that > removing SERVERS will re-shuffle the order more appropriately. > > > > It seems that the behavior of rcorder is not as documented as well as > being undefined when circular dependencies occur. The man page says that > rcorder aborts when it encounters a circular dependency, but that is not > the case. It probably is best that it not die, but that leaves things in = an > unknown and inconsistant state, which is also a very bad idea. I guess wh= en > a circular dependency is encountered, a dichotomy occurs. > > Now you know why I=E2=80=99m so curious about all of this stuff. > > When I was working on ^/projects/building-blocks, I was able to move most > of these pieces around by changing REQUIRE: to BEFORE:, but I noticed tha= t > it changes the rcorder a bit, so I haven=E2=80=99t been super gung ho in > implementing my change. > > I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: > > - Things go awry if named is removed/not installed. > - Things go awry if local_unbound is removed (which would have been the > case if the rc.d script was removed from your system, which existed befor= e > my changes). > - Other rc.d scripts not being present might break assumptions. > > I need to create dummy providers for certain logical stages (DNS is one o= f > them) to solve part of this problem and provide third parties with a > mechanism that can be depended on (I wish applications were written in a > more robust manner to fail gracefully and retry instead of failing flat o= n > their face, but as I=E2=80=99ve seen at several jobs, getting developers = to fail, > then retry is hard :(=E2=80=A6). > > Another short-term hack: > > Install dummy/no-op providers so the ordering is preserved, then remove > the hacks after all of the bugs have been shaken out. > > Thanks! > Garret, Also undocumented (except in rcorder.c) is that the lack of a provider is not an error. This effectively makes a list of providers into an OR. So, for name service the normal list is "named local_unbound unbound" and any will work for ordering and having none is a no-op, so if you don't run any nameserver (or kerberos or whatever provider), it is not an issue. As long as rcorder finds a provider, it will be used to set the order, but the lack of any or all providers just means that the specified provider is ignored and if a REQUIRES or BEFORE lists no existing providers, the statement is simply ignored. The real problem is that there is no defined rule for behavior in the event of a circular dependency and any change to any decision point in the ordering process may change the way the ordering flips. That is why these things are such a royal pain to debug. A change in any rc.d script may cause the ordering of seemingly unrelated scripts to change, perhaps drastically, and the error messages, while not misleading, is only a starting point in tracking this down. This means there may be time bombs that break working ports without their being touched or even re-installed. And the triggering change my, itself be correct. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 02:52:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48A2C134 for ; Thu, 26 Feb 2015 02:52:41 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3CDC9B6 for ; Thu, 26 Feb 2015 02:52:40 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so9512395pdb.5 for ; Wed, 25 Feb 2015 18:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=6LusFs6idnaZ3i3UNm7zCcaFUC8TAaPjNywSWUd4Ae0=; b=WuOpoN29fVaNF+D89HcQPr9Rrw20ji3K+ndpTnmWWIgidPJ9rUEWI9kjdxf3Tw9QxH r8KgpsDOOMFP2k29ZXZOSnWnZiMjS07kiYWsEWrgi4dy0WvrbqK8uRBWiz8utxlqrsLS 9HZefrJ83fA4+V6nothBu444LGowfJTmJKxtpq1Z3aBUklK4AmY/2Drr8v+deLG80AJB 6wEvMYUbnAp61zJzLx046aNuQSGJvjnqpsfgYqhEtNpOhcYUTod0jiI/88x161AR/KiD twh/79QeuFI8vBj9oW4Zo/UaaIp59s9/UEadKK4LD8WV1HIqRfXKlhJgZOql65vPSy10 rpdg== X-Received: by 10.70.90.80 with SMTP id bu16mr10982625pdb.88.1424919160421; Wed, 25 Feb 2015 18:52:40 -0800 (PST) Received: from [10.184.57.98] (mobile-166-171-123-224.mycingular.net. [166.171.123.224]) by mx.google.com with ESMTPSA id gi3sm42562967pbc.83.2015.02.25.18.52.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 18:52:39 -0800 (PST) References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> X-Mailer: iPhone Mail (12B466) From: Garrett Cooper Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Date: Wed, 25 Feb 2015 18:52:35 -0800 To: Kevin Oberman Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 02:52:41 -0000 > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >=20 >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper w= rote: >> On Feb 25, 2015, at 14:19, Miguel Clara wrote: >>=20 >> ... >>=20 >> > I noticed this too, but in that case why doesn't it affect all users? (= or all the ones using dnscrypt+local_unbound) maybe something changed in "NE= TWORKING" recently? >> > >> > Hum: >> > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2= =3D278704 >> > >> > Interesting, as I am using the most recent version which does not REQUI= RE local_unbound >> > >> > I'm even more confused now :| >> > >> > >> > So it has to come after SERVERS but before local_unbound. But NETWORKIN= G depends on local_unbound they are both dependent on NEWORKING which has to= be after SERVERS. Can you say fubar! Clearly broken. And this means that re= moving SERVERS will re-shuffle the order more appropriately. >> > >> > It seems that the behavior of rcorder is not as documented as well as b= eing undefined when circular dependencies occur. The man page says that rcor= der aborts when it encounters a circular dependency, but that is not the cas= e. It probably is best that it not die, but that leaves things in an unknown= and inconsistant state, which is also a very bad idea. I guess when a circu= lar dependency is encountered, a dichotomy occurs. >>=20 >> Now you know why I=81fm so curious about all of this stuff. >>=20 >> When I was working on ^/projects/building-blocks, I was able to move most= of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that i= t changes the rcorder a bit, so I haven=81ft been super gung ho in implement= ing my change. >>=20 >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:= >>=20 >> - Things go awry if named is removed/not installed. >> - Things go awry if local_unbound is removed (which would have been the c= ase if the rc.d script was removed from your system, which existed before my= changes). >> - Other rc.d scripts not being present might break assumptions. >>=20 >> I need to create dummy providers for certain logical stages (DNS is one o= f them) to solve part of this problem and provide third parties with a mecha= nism that can be depended on (I wish applications were written in a more rob= ust manner to fail gracefully and retry instead of failing flat on their fac= e, but as I=81fve seen at several jobs, getting developers to fail, then ret= ry is hard :(=81c). >>=20 >> Another short-term hack: >>=20 >> Install dummy/no-op providers so the ordering is preserved, then remove t= he hacks after all of the bugs have been shaken out. >>=20 >> Thanks! >=20 > Garret,=20 >=20 > Also undocumented (except in rcorder.c) is that the lack of a provider is n= ot an error. This effectively makes a list of providers into an OR. So, for n= ame service the normal list is "named local_unbound unbound" and any will wo= rk for ordering and having none is a no-op, so if you don't run any nameserv= er (or kerberos or whatever provider), it is not an issue. As long as rcorde= r finds a provider, it will be used to set the order, but the lack of any or= all providers just means that the specified provider is ignored and if a RE= QUIRES or BEFORE lists no existing providers, the statement is simply ignore= d. >=20 > The real problem is that there is no defined rule for behavior in the even= t of a circular dependency and any change to any decision point in the order= ing process may change the way the ordering flips. That is why these things a= re such a royal pain to debug. A change in any rc.d script may cause the ord= ering of seemingly unrelated scripts to change, perhaps drastically, and the= error messages, while not misleading, is only a starting point in tracking t= his down. This means there may be time bombs that break working ports withou= t their being touched or even re-installed. And the triggering change my, it= self be correct. Or etc/rc.d/named... PROVIDES: DNS I'm going to post a fix up for this on arch@/rc@ because it needs to be solv= ed in a saner way -- especially for systems that are pedantic about rcorder,= like our version at $work. From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 09:22:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05D96E37 for ; Thu, 26 Feb 2015 09:22:58 +0000 (UTC) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5CC064F for ; Thu, 26 Feb 2015 09:22:57 +0000 (UTC) Received: by ykp9 with SMTP id 9so3513534ykp.5 for ; Thu, 26 Feb 2015 01:22:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ye8b5/U1PkV7JGTkYfjkA+W3vQUec68pV1NJKhpgFnU=; b=DH09ngpafCaU0oG89ylchiM44WXQrLiNK+AivKJ2pO6ziRTGPwMcfOneL3DJvvcnQW Wq9t1Hb8Yduy4Qx4UeOFMbe8Ybkc22xIbhXAF9Y6jvtZTf8bICOrz6aX+jE7doPgbIsT xP2FO3HAiwmVVGKrjTyu1kGcgORCoiCEFp3JQTUFW7Bm/J2fxZv7HQkBAJ2EmaegwZH+ 0u8xU0pT50Ia5NMHtYac2YyjjrhG+pgD4OxokUYV2WlegvgiafWpVeS71LJav2HSfYjW ohPZZPNoVyLXH2+CYpchd0QWCTKGNEJCxNz0Y805pmJyxREV04LQ8wltlqiaBgZqZqyf 8xzQ== X-Gm-Message-State: ALoCoQktTBhSWsI5td/rgbycWBN5yHCfSrGmOwMf+MRPGEOKijX2/V4/eJAzGKFhakN9Kx7pwrmd MIME-Version: 1.0 X-Received: by 10.170.143.2 with SMTP id k2mr6488727ykc.61.1424940961089; Thu, 26 Feb 2015 00:56:01 -0800 (PST) Received: by 10.170.56.134 with HTTP; Thu, 26 Feb 2015 00:56:01 -0800 (PST) In-Reply-To: <2035871.YPhCQEXjlG@ralph.baldwin.cx> References: <54CF6BBF.9050906@FreeBSD.org> <2035871.YPhCQEXjlG@ralph.baldwin.cx> Date: Thu, 26 Feb 2015 09:56:01 +0100 Message-ID: Subject: Re: [RFC] load network config file from netif init script From: Oliver Pinter To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 09:22:58 -0000 On Wed, Feb 25, 2015 at 9:34 PM, John Baldwin wrote: > On Monday, February 02, 2015 12:21:19 PM Roger Pau Monn=C3=A9 wrote: >> Hello, >> >> r272959 broke compatibility with mfsBSD that stores the default network >> config file in /etc/rc.conf.d/network. In order to fix that load the >> network config file from netif also. >> >> I'm attaching a patch to restore previous functionality, but since I'm >> not an expert on rc.d init scripts I would like some feedback on whether >> this is the right approach or not. >> >> Thanks, Roger. > > If you are still looking for review, you can try freebsd-rc@ perhaps? This patch was already committed to CURRENT. > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 09:58:01 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DBE1A08; Thu, 26 Feb 2015 09:58:01 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 ACB1AA0E; Thu, 26 Feb 2015 09:58:00 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1Q9vvuB030369; Thu, 26 Feb 2015 10:57:57 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 854E9F77; Thu, 26 Feb 2015 10:57:56 +0100 (CET) Message-ID: <54EEEE1E.7020007@omnilan.de> Date: Thu, 26 Feb 2015 10:57:50 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) driver changes available for test References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E78B2249C957722F57BABFD" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 26 Feb 2015 10:57:57 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 09:58:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E78B2249C957722F57BABFD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime= ): > I have updated the patches. > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, si= nce > I committed those separately. > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) > > Rough draft commit message: > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > The patches against FreeBSD/head as of SVN revision 278975: > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278= 974: > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Ken, thank you very much for your work! Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly appreciate your work on tape support for FreeBSD! I compiled your 10-stable patchset for one machine with LTO2 and DDS5 drives, but haven't done much testing since I'll replace the adaptec (39160) because it's maxio is limited to 64k (while 53c1020 has 128k). sa(4) seems to work just fine with both drives, mt(1) showing "Reported File/Record Number" :-) No EOM tests done so far=85 I'll archive zfs streams, therefore I needed some kind of forward error correction. Probably people following this thread also have found to need this, therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197950 Perhaps someone want's to take this bug report. Thanks, -Harry --------------enig6E78B2249C957722F57BABFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTu7iQACgkQLDqVQ9VXb8jEPgCgqYR8ygdo6bd/TKHIP+zY2Wpi Em4AnjRWCX9eScULaqyqvrnf4+K+BPb8 =EIKD -----END PGP SIGNATURE----- --------------enig6E78B2249C957722F57BABFD-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 14:13:07 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D445AD29; Thu, 26 Feb 2015 14:13:07 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBA9EB88; Thu, 26 Feb 2015 14:13:07 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id 2B17B1C8CF2; Thu, 26 Feb 2015 09:06:36 -0500 (EST) Received: from [127.0.0.1] (vnat004.nandomedia.com [166.108.31.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 8AAA81A7B2B; Thu, 26 Feb 2015 09:06:35 -0500 (EST) Message-ID: <54EF286A.5030006@mail.lifanov.com> Date: Thu, 26 Feb 2015 09:06:34 -0500 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-x11@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call for testers] DRM device-independent code update to Linux 3.8 References: <54E3D2A0.2090903@FreeBSD.org> In-Reply-To: <54E3D2A0.2090903@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 14:13:07 -0000 On 02/17/15 18:45, Jean-Sébastien Pédron wrote: > Hi! > > An update to the DRM subsystem, not including the drivers, is ready for > wider testing! > > The patch against HEAD is here: > https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch > > I'm interested in success/failure reports for amd64, powerpc and > powerpc64 users, for i915 and Radeon GPUs. I already know there is a > build issue on i386, please wait for the next patch if you are in this case. > > The changes brought by this patch are explained in a blog post: > http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ > > This is working well for some Radeon users for more than a year. > However, it only started to work with i915 a month ago, when the i915 > refresh was committed. > > Try your day-to-day applications, try suspend/resume, try all output > connectors, try OpenGL stuff, try backlight controls, everything :) > > Thank you! > I tried the -h version of the patch with an Nvidia card. I didn't notice any changes in behavior. - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 14:55:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CE0927B for ; Thu, 26 Feb 2015 14:55:28 +0000 (UTC) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAED3F9 for ; Thu, 26 Feb 2015 14:55:27 +0000 (UTC) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1YQzWg-0001lv-Tx for freebsd-current@freebsd.org; Thu, 26 Feb 2015 15:34:54 +0100 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1YQzWg-0006m2-Ta for freebsd-current@freebsd.org; Thu, 26 Feb 2015 15:34:54 +0100 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 ; Thu, 26 Feb 2015 14:34:54 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "freebsd-current" Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Date: Thu, 26 Feb 2015 06:34:54 -0800 (PST) X-Mailer: RMM6 In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 14:55:28 -0000 On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper = wrote: >=20 > > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: > >=20 > >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara wrote: > >>=20 > >> ... > >>=20 > >> > I noticed this too, but in that case why doesn't it affect all users= ? (or all the ones using dnscrypt+local_unbound) maybe something changed in= "NETWORKING" recently? > >> > > >> > Hum: > >> > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299= &r2=3D278704 > >> > > >> > Interesting, as I am using the most recent version which does not RE= QUIRE local_unbound > >> > > >> > I'm even more confused now :| > >> > > >> > > >> > So it has to come after SERVERS but before local_unbound. But NETWOR= KING depends on local_unbound they are both dependent on NEWORKING which ha= s to be after SERVERS. Can you say fubar! Clearly broken. And this means th= at removing SERVERS will re-shuffle the order more appropriately. > >> > > >> > It seems that the behavior of rcorder is not as documented as well a= s being undefined when circular dependencies occur. The man page says that = rcorder aborts when it encounters a circular dependency, but that is not th= e case. It probably is best that it not die, but that leaves things in an u= nknown and inconsistant state, which is also a very bad idea. I guess when = a circular dependency is encountered, a dichotomy occurs. > >>=20 > >> Now you know why I=E2=80=99m so curious about all of this stuff. > >>=20 > >> When I was working on ^/projects/building-blocks, I was able to move m= ost of these pieces around by changing REQUIRE: to BEFORE:, but I noticed t= hat it changes the rcorder a bit, so I haven=E2=80=99t been super gung ho i= n implementing my change. > >>=20 > >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRE= NT: > >>=20 > >> - Things go awry if named is removed/not installed. > >> - Things go awry if local_unbound is removed (which would have been th= e case if the rc.d script was removed from your system, which existed befor= e my changes). > >> - Other rc.d scripts not being present might break assumptions. > >>=20 > >> I need to create dummy providers for certain logical stages (DNS is on= e of them) to solve part of this problem and provide third parties with a m= echanism that can be depended on (I wish applications were written in a mor= e robust manner to fail gracefully and retry instead of failing flat on the= ir face, but as I=E2=80=99ve seen at several jobs, getting developers to fa= il, then retry is hard :(=E2=80=A6). > >>=20 > >> Another short-term hack: > >>=20 > >> Install dummy/no-op providers so the ordering is preserved, then remov= e the hacks after all of the bugs have been shaken out. > >>=20 > >> Thanks! > >=20 > > Garret,=20 > >=20 > > Also undocumented (except in rcorder.c) is that the lack of a provider = is not an error. This effectively makes a list of providers into an OR. So,= for name service the normal list is "named local_unbound unbound" and any = will work for ordering and having none is a no-op, so if you don't run any = nameserver (or kerberos or whatever provider), it is not an issue. As long = as rcorder finds a provider, it will be used to set the order, but the lack= of any or all providers just means that the specified provider is ignored = and if a REQUIRES or BEFORE lists no existing providers, the statement is s= imply ignored. > >=20 > > The real problem is that there is no defined rule for behavior in the e= vent of a circular dependency and any change to any decision point in the o= rdering process may change the way the ordering flips. That is why these th= ings are such a royal pain to debug. A change in any rc.d script may cause = the ordering of seemingly unrelated scripts to change, perhaps drastically,= and the error messages, while not misleading, is only a starting point in = tracking this down. This means there may be time bombs that break working p= orts without their being touched or even re-installed. And the triggering c= hange my, itself be correct. >=20 > Or etc/rc.d/named... >=20 > PROVIDES: DNS >=20 I don't know if this is adding not-relevancy to this thread or not... I've = a long persistent "dbus-daemon*" "*uuid*" (names approximate, not saved during boot) two "start ..." failures during = rc... despite reinstalling the ports and dependencies, particularly the .so. files mentioned (not included here.= ..=20=20 uuidd_enable=3D"YES" (e2fsprogs* ) dbus_enable=3D"YES" (*dbus*)=20 beginning v9 OR v10 ( not recollecting enough...) and persisting thencefort= h. Maybe those two could also be similarly fixed to this thread's one Despite not being in use day-to-day... nor particularly relevant... install= ed only conventionally. From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 19:55:43 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1010DE67; Thu, 26 Feb 2015 19:55:43 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C438DC7D; Thu, 26 Feb 2015 19:55:42 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E78871FE022; Thu, 26 Feb 2015 20:55:39 +0100 (CET) Message-ID: <54EF7A6A.30305@selasky.org> Date: Thu, 26 Feb 2015 20:56:26 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dervishe , "freebsd-current@FreeBSD.org" Subject: Re: [Call for testers] DRM device-independent code update to Linux 3.8 References: <20150220221246.661f2d01@shibato> <1227462529.6746581.1424602457182.JavaMail.yahoo@mail.yahoo.com> <54EDBC3F.1030302@selasky.org> In-Reply-To: <54EDBC3F.1030302@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-x11@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 19:55:43 -0000 On 02/25/15 13:12, Hans Petter Selasky wrote: > The -h patch Works for me, tested on a mac book pro. > > --HPS On another box the -h patch causes infinite HDMI hotplug events to be sent, causing alot of xorg CPU usage. This dmesg is w/o the -h patch. info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0x0 iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0x0 iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0x0 iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0x0 iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0x0 iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0x0 iic12: on iicbus12 iic13: on iicbus13 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector HDMI-A-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.HDMI-A-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DP-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DP-1 info: [drm] - kern.vt.fb.default_mode --HPS From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 22:42:05 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 859A11E4; Thu, 26 Feb 2015 22:42:05 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2719331B; Thu, 26 Feb 2015 22:42:04 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t1QMg2hW014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Feb 2015 15:42:02 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1QMg2sb014158; Thu, 26 Feb 2015 15:42:02 -0700 (MST) (envelope-from ken) Date: Thu, 26 Feb 2015 15:42:02 -0700 From: "Kenneth D. Merry" To: Harald Schmalzbauer Subject: Re: sa(4) driver changes available for test Message-ID: <20150226224202.GA14015@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EEEE1E.7020007@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Thu, 26 Feb 2015 15:42:03 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Feb 2015 22:42:05 -0000 On Thu, Feb 26, 2015 at 10:57:50 +0100, Harald Schmalzbauer wrote: > Bez?glich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime): > > I have updated the patches. > > > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > > I committed those separately. > > > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > > dependencies. (One of them mav did for me, thanks!) > > > > Rough draft commit message: > > > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > > > The patches against FreeBSD/head as of SVN revision 278975: > > > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > > > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt > > Ken, > > thank you very much for your work! > Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly > appreciate your work on tape support for FreeBSD! > I compiled your 10-stable patchset for one machine with LTO2 and DDS5 > drives, but haven't done much testing since I'll replace the adaptec > (39160) because it's maxio is limited to 64k (while 53c1020 has 128k). > sa(4) seems to work just fine with both drives, mt(1) showing "Reported > File/Record Number" :-) No EOM tests done so far? I'm glad it is working well for you! You can do larger I/O sizes with the Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config file. e.g.: options MAXPHYS=(1024*1024) options DFLTPHYS=(1024*1024) If you set those values larger, you won't be able to do more than 132K with the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 segments * PAGE_SIZE.) > I'll archive zfs streams, therefore I needed some kind of forward error > correction. Probably people following this thread also have found to > need this, therefore I'd like to point to the new port misc/vdmfec > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 > Perhaps someone want's to take this bug report. That looks cool. :) I'm not a ports committer, but hopefully one of them will pick it up. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 03:08:45 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E8FB2BF; Fri, 27 Feb 2015 03:08:45 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 54B0131F; Fri, 27 Feb 2015 03:08:45 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 39A671CC12; Thu, 26 Feb 2015 22:08:43 -0500 (EST) Message-ID: <54EFDFB8.6020404@protected-networks.net> Date: Thu, 26 Feb 2015 22:08:40 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff , current@FreeBSD.org, ports@FreeBSD.org Subject: removing _WANT_IFADDR breaks net-snmp OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6robXlSsvuiGwImOPUEQsoPf0NMlgDCJI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 03:08:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6robXlSsvuiGwImOPUEQsoPf0NMlgDCJI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The recent changes which served to hide "struct ifaddr" have broken net-snmp: imb@toshi:/usr/ports/net-mgmt/net-snmp> sudo make =3D=3D=3D> Building for net-snmp-5.7.3_5 making all in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/snmplib making all in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent making all in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/help= ers making all in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/mibgroup /bin/sh ../../libtool --mode=3Dcompile cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=3Dcore2 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -std=3Dc99 -Ufreebsd11 -Dfreebsd11=3Dfreebsd11 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -c -o mibII/ipv6.lo mibII/ipv6.c libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=3Dcore2 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -std=3Dc99 -Ufreebsd11 -Dfreebsd11=3Dfreebsd11 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -c mibII/ipv6.c -fPIC -DPIC -o mibII/.libs/ipv6.o mibII/ipv6.c:806:20: warning: returning 'char *' from a function with result type 'u_char *' (aka 'unsigned char *') converts between pointers to integer types with different sign [-Wpointer-sign] return p; ^ mibII/ipv6.c:848:29: error: variable has incomplete type 'struct ifaddr' struct ifaddr ifaddr; ^ /usr/include/net/if_var.h:89:24: note: forward declaration of 'struct ifaddr' TAILQ_HEAD(ifaddrhead, ifaddr); /* instantiation is preserved in the list= */ ^ /usr/include/sys/queue.h:493:9: note: expanded from macro 'TAILQ_HEAD' struct type *tqh_first; /* first element */ \= ^ 1 warning and 1 error generated. *** Error code 1 --6robXlSsvuiGwImOPUEQsoPf0NMlgDCJI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTv37gACgkQQv9rrgRC1JK1KgCgxIvfkOqDrqogdPWNvrVC8L9R Vn8An38lYXDhQbwwPwwLe+VyFytOuZAl =ok7l -----END PGP SIGNATURE----- --6robXlSsvuiGwImOPUEQsoPf0NMlgDCJI-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 07:41:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BC7097F for ; Fri, 27 Feb 2015 07:41:36 +0000 (UTC) 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 E1D0A128 for ; Fri, 27 Feb 2015 07:41:35 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t1R7CYTV078027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 26 Feb 2015 23:12:35 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54F018DD.30800@freebsd.org> Date: Thu, 26 Feb 2015 23:12:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD FUSE calls truncate() on read-only files References: <6676D082-5C06-4E59-B22C-5C00D1FD229F@netapp.com> In-Reply-To: <6676D082-5C06-4E59-B22C-5C00D1FD229F@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 07:41:36 -0000 On 2/25/15 5:34 AM, Eggert, Lars wrote: > Hi, > > this came up when trying to port tup (https://github.com/gittup/tup) to FreeBSD. > > Even though we are opening the file read-only with cat, FUSE calls truncate() on it, which modifies its mtime and this screws up tup. See https://github.com/gittup/tup/issues/198 > > Anyone know why FreeBSD's FUSE is doing this? nope but it has lots of other bugs.. for example it caches information when it shouldn't, even from 'dynamic' file systems We had to change the code to disable it as our data is synthetic and might change between reads. fstat info is also cached and confused our apps mightily. > > Thanks, > Lars From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 09:20:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C016B90A for ; Fri, 27 Feb 2015 09:20:54 +0000 (UTC) Received: from nm7-vm2.bullet.mail.sg3.yahoo.com (nm7-vm2.bullet.mail.sg3.yahoo.com [106.10.148.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ECABD5E for ; Fri, 27 Feb 2015 09:20:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425028491; bh=neQc+RgBn/kIxsqzVwLEFomvIOlff3IH+L8YZNqzQrM=; h=Date:From:Reply-To:To:Subject:From:Subject; b=tZasWmP3FuyRbHbUqWGRtjPLnTx+Wp0+z5iUc+9KswomEHXoiFubRIIi0dkhskwG2Mowoh4+dKZ8JHrUTcvN0t7gWb8cHTHYpP32WIeN1Jxf+w9mm4XjywT74nMFbfINiwrFRb9Pf1rxQ2rY0P1dgKzZtPIU+iY8UCmfRXoPSZkSZItzMMl4SVsu8xLXK6+kT6WPkGTpLlxtHCaWqYUbH7quixOBzDckRtuI3DqztvYbSZeZ2X3SdZG2wTcED97N7KwiDXTYmhbnuF1AtqKHoZ76bjCIG/2kJRKBTyOC007zbnVggfhMo2ILxTEzMwVKRhx1OyigtdeBQnNUPnOJNg== Received: from [106.10.166.115] by nm7.bullet.mail.sg3.yahoo.com with NNFMP; 27 Feb 2015 09:14:51 -0000 Received: from [106.10.151.218] by tm4.bullet.mail.sg3.yahoo.com with NNFMP; 27 Feb 2015 09:14:51 -0000 Received: from [127.0.0.1] by omp1016.mail.sg3.yahoo.com with NNFMP; 27 Feb 2015 09:14:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 446620.64876.bm@omp1016.mail.sg3.yahoo.com X-YMail-OSG: 7nL_bwMVM1ly39EhhN1MP9FVCNpxtcTmcqT3Dwe9b8xHgR9NFxJhb.2QzWGfsxP uBtdyo5R45TTUq0Tu.PAZash5DTMzXHJuaATZQakuugKqzVeuRnkkBZYjbLBlexmJPjPEoyg2AA4 rsHoLNtq3GV9lImJPrVXynE2CjPYtmns1GqbBkPjFA79Mcpyo.amDjB9OzvZvbkTNZpmstO4CFtv LfAI4F3g1axLRECn4pfyAO.yDGTsjdDuuMfvcMNzzipndHSNLIFtFHfS.LzxB5fQHqQ._rVBz8Zu 6UyQw57nRINc1YWJDC6IlVPoQSY2gzOHQad_xReCR.TjRJW3llHwGpgsK0M0oq7BF5wrRCZXAAYM zvC9qCTCL5xwG1HS_XDCmuXY0MNaV.dpZLgWDsYx.0grae_ANYFcPLfudZueKSeuK74OoqsDXJrb Nz6UJo9dWHqbgKK7f8NDhZo7mYiYENNvyjnTaEVb6BzPk8jxfqHqnYN22fnnOlKXEI9AlU1_52Bn g4g-- Received: by 106.10.197.98; Fri, 27 Feb 2015 09:14:51 +0000 Date: Fri, 27 Feb 2015 09:14:50 +0000 (UTC) From: Bhaskar Singhal Reply-To: Bhaskar Singhal To: "freebsd-current@freebsd.org" , "freebsd-questions@freebsd.org" Message-ID: <1624063012.777081.1425028490663.JavaMail.yahoo@mail.yahoo.com> Subject: ggatec: ioctl(/dev/ggctl): Invalid argument MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 09:20:54 -0000 Hi, I am trying to use ggatec to mount a device from another host running the same FreeBSD version (8.1) and I am seeing the following error: freebsd-2% ggatec create -vo rw hostname /dev/xbd7 info: Connected to the server: hostname:3080. debug: Sending version packet. debug: Sending initial packet. debug: Receiving initial packet. debug: Received initial packet. info: Connected to the server: hostname:3080. debug: Sending version packet. debug: Sending initial packet. debug: Receiving initial packet. debug: Received initial packet. error: ggatec: ioctl(/dev/ggctl): Invalid argument. error: Exiting. If I use ggatec to mount the device from the same host (i.e. ggated and ggatec on same host), than it works, but for remote host it doesn't. Any ideas? Regards,Bhaskar From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 11:52:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 406CA696 for ; Fri, 27 Feb 2015 11:52:10 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05207F2A for ; Fri, 27 Feb 2015 11:52:10 +0000 (UTC) Received: by padet14 with SMTP id et14so22131974pad.11 for ; Fri, 27 Feb 2015 03:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TlKs3jilEStce02E0HxHMF2uG47KCbA+y5g9Jqk6ViE=; b=Nz/TDbUL39RfHrZtG4huYuRLu9UCPCzdiZiUtYUmbzSEupbNNC2F20u0drom/tWPZH MKTXw2i0Zdag912JYdTnFPss32mopf9ZiPEsR8skCbFZbBARVCTAhxzk64ozdHeAx2ST LKPhCDSc/rKGITtfFgEwIBvYVV98afWHlVwtTOyqvcrT5cKXnJ/cct5NwfqHFE+ilrOQ /KiAOCZ/c6XBdDn6xrehh9lr62wkYyVpSMZoscc1UVaBHcAzCnYaPf9wuPCbGUp50GVw Scxu8CW05KhSLTQMc9ONtxRO82Cl/KoqZtCdxl9sVR/O4r1qxaNIN4Nn7POKigtuWJIt kRiA== X-Received: by 10.70.64.163 with SMTP id p3mr23670913pds.118.1425037929504; Fri, 27 Feb 2015 03:52:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.237.39 with HTTP; Fri, 27 Feb 2015 03:51:49 -0800 (PST) In-Reply-To: References: <19E33DDA-E850-466F-9BD9-EB7ED257E428@gmail.com> From: Arseny Nasokin Date: Fri, 27 Feb 2015 15:51:49 +0400 Message-ID: Subject: Re: Current build world failed: bsdxml is missing? To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 11:52:10 -0000 On 17 February 2015 at 01:10, Arseny Nasokin wrote: > On 16 February 2015 at 17:04, Arseny Nasokin wrote: > >> On 16 February 2015 at 15:34, Garrett Cooper >> wrote: >> >>> On Feb 16, 2015, at 4:28, Arseny Nasokin wrote: >>> >>> > Geom XML output is failed to build. >>> > >>> > Build box SVN version is: CURRENT-r265265. >>> > >>> > Related log output is: >>> > >>> > --- sbin.all__D --- >>> > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function >>> > `geom_xml2tree': >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x5e): undefined referenc= e >>> to >>> > `XML_ParserCreate' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa2): undefined referenc= e >>> to >>> > `XML_SetUserData' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xb4): undefined referenc= e >>> to >>> > `XML_SetElementHandler' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc1): undefined referenc= e >>> to >>> > `XML_SetCharacterDataHandler' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xdb): undefined referenc= e >>> to >>> > `XML_Parse' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xfd): undefined referenc= e >>> to >>> > `XML_ParserFree' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x373): undefined >>> reference to >>> > `XML_ParserFree' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x37d): undefined >>> reference to >>> > `XML_GetErrorCode' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x397): undefined >>> reference to >>> > `XML_ParserFree' >>> > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function >>> > `StartElement': >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x3eb): undefined >>> reference to >>> > `sbuf_new' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x735): undefined >>> reference to >>> > `XML_StopParser' >>> > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function >>> > `EndElement': >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7bb): undefined >>> reference to >>> > `sbuf_finish' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7d0): undefined >>> reference to >>> > `sbuf_data' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7e9): undefined >>> reference to >>> > `sbuf_delete' >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa25): undefined >>> reference to >>> > `XML_StopParser' >>> > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function >>> > `CharData': >>> > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc62): undefined >>> reference to >>> > `sbuf_bcat=E2=80=99 >>> >>> I think the fact that it=E2=80=99s missing sbuf* is the underlying caus= e for the >>> failures seen here. Can you please post more context in a pastebin or >>> something (what phase did buildworld fail, what options did you pass to >>> make, i.e. -DNO_CLEAN, etc?)? >>> >>> Thanks! >>> >> >> Thank you for fast reply, >> >> I remove /usr/obj/usr and $TMPDIR explicitly with rm(1) and >> chflags(1) and only then build world. (I use separate $TMPDIR for that >> process) >> >> # make toolchain 'SRCCONF=3D/path/to/src.conf' -DNO_CLEAN >> '__MAKE_CONF=3D/dev/null' 'TARGET=3Damd64' >> # make buildworld 'SRCCONF=3D/path/to/src.conf' -DNO_CLEAN >> '__MAKE_CONF=3D/dev/null' 'TARGET=3Damd64' >> ... >> >> The stage is: 4.4 (building everything) >> >> Build script is here: >> https://bitbucket.org/eirnym/bsd/src/9822ba9b1ed54414a79d5a632b3857f8b67= 1c769/builder/mkw.sh?at=3Ddefault >> >> -- Eir Nym >> > > > Full log is here http://eroese.org/_/_/pub/bsd/world.amd64.278844.log > (~23 Mb) > > Recent part is: > > gzip -cn /usr/src/sbin/atm/atmconfig/atmconfig.8 > atmconfig.8.gz > =3D=3D=3D> sbin/badsect (all) > cc -O2 -pipe -DNDEBUG -std=3Dgnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-bod= y > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Qunused-arguments -c > /usr/src/sbin/badsect/badsect.c > ctfconvert -L VERSION badsect.o > ERROR: ctfconvert: badsect.o doesn't have type data to convert > cc -O2 -pipe -DNDEBUG -std=3Dgnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-bod= y > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Qunused-arguments -static -o badsect > badsect.o -lufs > ctfmerge -L VERSION -o badsect badsect.o > ERROR: ctfmerge: No ctf sections found to merge > gzip -cn /usr/src/sbin/badsect/badsect.8 > badsect.8.gz > =3D=3D=3D> sbin/bsdlabel (all) > cc -O2 -pipe -DNDEBUG -std=3Dgnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/sbin/bsdlabel/bsdlabel.c > ctfconvert -L VERSION bsdlabel.o > ERROR: ctfconvert: bsdlabel.o doesn't have type data to convert > cc -O2 -pipe -DNDEBUG -std=3Dgnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/sbin/bsdlabel/../../sys/geom/geom_bsd_enc.c > ctfconvert -L VERSION geom_bsd_enc.o > ERROR: ctfconvert: geom_bsd_enc.o doesn't have type data to convert > cc -O2 -pipe -DNDEBUG -std=3Dgnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Qunused-arguments -static -o bsdlabel > bsdlabel.o geom_bsd_enc.o -lgeom > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function > `geom_xml2tree': > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x5e): undefined reference to > `XML_ParserCreate' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa2): undefined reference to > `XML_SetUserData' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xb4): undefined reference to > `XML_SetElementHandler' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc1): undefined reference to > `XML_SetCharacterDataHandler' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xdb): undefined reference to > `XML_Parse' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xfd): undefined reference to > `XML_ParserFree' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x373): undefined reference t= o > `XML_ParserFree' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x37d): undefined reference t= o > `XML_GetErrorCode' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x397): undefined reference t= o > `XML_ParserFree' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function > `StartElement': > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x3eb): undefined reference t= o > `sbuf_new' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x735): undefined reference t= o > `XML_StopParser' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function > `EndElement': > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7bb): undefined reference t= o > `sbuf_finish' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7d0): undefined reference t= o > `sbuf_data' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7e9): undefined reference t= o > `sbuf_delete' > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa25): undefined reference t= o > `XML_StopParser' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function > `CharData': > /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc62): undefined reference t= o > `sbuf_bcat' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/sbin/bsdlabel > *** Error code 1 > > > -- Eir Nym > Hi guys, I've found the reason and I've fixed it. The reason is I build world with WITHOUT_DYNAMIC_ROOT option. The library libgeom depends on libbsdxml and libsbuf which will not linked to target program in this case. I have the patch for several programs in sbin and usr.sbin to fix this problem. -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 15:14:46 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 985CCF88 for ; Fri, 27 Feb 2015 15:14:46 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 56E4B972 for ; Fri, 27 Feb 2015 15:14:46 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.9/8.14.9) with ESMTP id t1RF4gLR008333 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Fri, 27 Feb 2015 07:04:42 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201502271504.t1RF4gLR008333@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Feb 2015 07:04:42 -0800 To: Arseny Nasokin , Garrett Cooper From: Manfred Antar Subject: Re: Current build world failed: bsdxml is missing? In-Reply-To: References: <19E33DDA-E850-466F-9BD9-EB7ED257E428@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-102.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID,TW_DX,TW_SD,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0, No X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: t1RF4gLR008333 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 15:14:46 -0000 At 03:51 AM 2/27/2015, Arseny Nasokin wrote: >Hi guys, > >I've found the reason and I've fixed it. > >The reason is I build world with WITHOUT_DYNAMIC_ROOT option. The library >libgeom depends on libbsdxml and libsbuf which will not linked to target >program in this case. > >I have the patch for several programs in sbin and usr.sbin to fix this >problem. > > >-- Eir Nym It would be nice if someone fixed this, it's been broken for quit awhile The WITHOUT_DYNAMIC_ROOT option. If I want static root, have to patch a few makefiles in bin and sbin. Thanks ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 15:37:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E69F912; Fri, 27 Feb 2015 15:37:23 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 F0D82BFF; Fri, 27 Feb 2015 15:37:22 +0000 (UTC) X-AuditID: 12074423-f79066d0000058b8-14-54f08dfc2be3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 02.2A.22712.DFD80F45; Fri, 27 Feb 2015 10:32:13 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1RFWCd1000770; Fri, 27 Feb 2015 10:32:12 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1RFWALk000897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Feb 2015 10:32:12 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1RFWA3B015267; Fri, 27 Feb 2015 10:32:10 -0500 (EST) Date: Fri, 27 Feb 2015 10:32:10 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Julian Elischer Subject: Re: FreeBSD FUSE calls truncate() on read-only files In-Reply-To: <54F018DD.30800@freebsd.org> Message-ID: References: <6676D082-5C06-4E59-B22C-5C00D1FD229F@netapp.com> <54F018DD.30800@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT1/3b+yHEYMdrNos5bz4wWVyd+5PZ gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZs9t3sBZ0MVccenKeuYFxC1MXIyeHhICJxL4Ve5kh bDGJC/fWs3UxcnEICSxmkjh39D0rhLORUaJx2VmozCGgzJWL7BBOA6NE/8Q5LCD9LALaEtve rGIDsdkE1CQe721mhZirKLH51CSwHSICGhLXd8wAizMLyEv8v3IZ6A4ODmEBW4n/221AwpwC mhJ71i8DK+EVcJDoOzKbHcQWEoiSuPNpPVhcVEBHYvX+KSwQNYISJ2c+YYEYqSWxfPo2lgmM QrOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mil5pSuokRHLguyjsY/xxU OsQowMGoxMNrwPwhRIg1say4MvcQoyQHk5Io7+ocoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3sIqoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSvZw9Qo2BRanpq RVpmTglCmomDE2Q4D9DwIJAa3uKCxNzizHSI/ClGXY4F7ftnMgmx5OXnpUqJ81qBFAmAFGWU 5sHNgSWcV4ziQG8J8zaCVPEAkxXcpFdAS5iAlhy4+w5kSUkiQkqqgbEqfrLrqXPivFXSy252 sTE4HA81qTn1Wt2o8dRZUy6PVVlLX8fzPDglMv3q1yt9tbqZekHnFrHfFdMtaJz5anPG1nWL I+ZFzyi4xlaY+HKvkC2Pstsf/YPu5xc9TKlxuf15a9Hrj73Zro7MGxd0b55tJlQ+b7/Y7oeG SjIzBM41S/xKvzjD4ZESS3FGoqEWc1FxIgBLTzAGEwMAAA== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 15:37:23 -0000 On Fri, 27 Feb 2015, Julian Elischer wrote: > for example it caches information when it shouldn't, even from 'dynamic' file > systems > We had to change the code to disable it as our data is synthetic and might > change between reads. > fstat info is also cached and confused our apps mightily. You are of course planning to file bug reports about these issues, I presume? -Ben From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 16:31:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 493699F6 for ; Fri, 27 Feb 2015 16:31:48 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3355209 for ; Fri, 27 Feb 2015 16:31:47 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id id10so6763046vcb.5 for ; Fri, 27 Feb 2015 08:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=0+am/A3CC6Z7LcjQp9xrxwLtCOAb38I9wmoNDXO6dsg=; b=RjZvBV4SM/3if5Lx+hZJSCnXYMzkzvEla5L2QjcTNwEHcYadB/L89YRhN5I+HVldcl Gg689ysKV6Bv/Z3KhJOC9FkDWVQqM9jZl7rKb2tGQZ2Il+GdK/dpHne8oG5nhvxcErT4 qK1/tEcyqy0E+s0BKuG4Lnba/X1PNwTJnMHaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-transfer-encoding; bh=0+am/A3CC6Z7LcjQp9xrxwLtCOAb38I9wmoNDXO6dsg=; b=NIPaZX4CuzVKc6V86gwZyPFG5pDdiNcRJrvmH7CqdxZHy4VmsEPVMg5ZOLThhMXVip 99sV/WVv/vqyF8UUw82K/2TUcRfaqtPr1eKUa5fMdiOjdREahzr9X7Tf+Kdcx/r204Oh QKFSoWM64RFrQoGVWIuI6hBg1wDo786PVu1XMDZj+rS0S0lL1r+BZAbtUv/0cSV7lJyi 12X0XLC/FV5Kp4d6zeSJGlU9tQsRZp3P4kTqpWyIDrxjSOoXIRh9HMxcTPf05HjiOSDx 9cbnFbM4+jhdfvjnGG9buHa48WzfZKy3QBzechbqAFVhobFJllrPZgfgsr7sZlAyy1K1 UYZA== X-Gm-Message-State: ALoCoQn2k3tJwOdOVrfqkBn5XKQLZ9DQOSndfyMh0i0E/kNqikfRaqcDFhdEqIXpgq80twk5N/pm X-Received: by 10.52.120.83 with SMTP id la19mr11593115vdb.34.1425054706932; Fri, 27 Feb 2015 08:31:46 -0800 (PST) Received: from rsbsd.rsb ([31.200.11.109]) by mx.google.com with ESMTPSA id k10sm798558vdi.18.2015.02.27.08.31.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 08:31:46 -0800 (PST) Date: Fri, 27 Feb 2015 18:31:43 +0200 From: Beeblebrox To: freebsd-current@freebsd.org Subject: system failure: cannot kill webkit-gtk3 if using dumbell/radeon Message-ID: <20150227183143.708a0656@rsbsd.rsb> 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.18-1 Precedence: 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, 27 Feb 2015 16:31:48 -0000 I just hit a major kernel bug with the new Radeon code * I'm on dumbbell's patch_38 for world/kernel (11.0-CURRENT #2 45116d3(mast= er)-dirty) * I started www/midori and was getting segfaults with URL that start with "= h". I re-built midori using WITH_DEBUG=3Dyes, got no output, then re-built = without DEBUG enabled because I was having image display problems. Reported= the problem as port issue: http://freebsd.1045724.n5.nabble.com/www-midori= -dislikes-the-letter-h-td5992424.html * At some point while using Midori (and right after I logged into Facebook)= sytem started to hiccup and slow down, so I swithced to tty*. I start X.or= g with "startx", so I tried to kill X with "ctr+c" > no response. Here's where it gets interesting. Each step indicated with "*" was done on = different tty, all tty's were logged in as root: * issue "# top" > tty froze, does not exit. * Several other simple root-level commands from different TTY result in TTY= freeze. * Let's free some RAM: "# service kill xyz" > nothing, no result kill -9 process-name > ok jail -r aa bb cc > tty freeze * jls > jails still running, previous command obviously could not kill let's kill processes: kill -9 process_num_for_midori > ok kill -9 process_num_for_several others > ok kill -9 process_num_for_WebKitWeb > NOPE, DOES NOT KILL * "# shutdown now" > hangs for ever * On TTY1: shows signal 15, but does not proceed. Seems to have difficulty killing jails. "ctl+alt+del" helps a bit. Shuts down eventually, after appx 10 mins. After restart and in xorg, one cycle of start/stop for Midori does not prod= uce any of symptoms above. When killing WebKitWeb, the higher process_numbers died, but the lower proc= ess_numbers resisted. So the spawned processes could be killed, but the mas= ter process could not. --=20 FreeBSD_amd64_11-Current_RadeonKMS From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 17:49:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A51DD49B for ; Fri, 27 Feb 2015 17:49:57 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CA3CD02 for ; Fri, 27 Feb 2015 17:49:57 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so22572416pdb.5 for ; Fri, 27 Feb 2015 09:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MVhk/Ro8VsOnTuLjcorI5hiPt5HG1oPhCpX9FVy4Sx0=; b=wpDpGpyZh6pU0MqsEP33TgzZ9UHd0dgBtBGB8yzlWJlEXPTPLApbmJgg4cyMb8rEXy gPIwOCq1F3fzxMsc0kZMBGuE9AgWQwDMliRmxJb1XmyhHGB2q5ajCc61Tm/UMGozy9Vy v/UnmTCKEhM5v8VQJC8S3+G3OKzIxxFL2V1n/z3ZzrCXH43VeUFM3f+cXl1gQIp657+4 VNhDWxTrxBUCR3K069ogk95m+iYdhEp3i91WacO85JqDKvDe31a1fLZWD5Y7amKEBqZ6 rVq0Ep7RWuSTrA/2zS51KIVUx05qfRFotJaY2sZqZlfbFRQcoqIA7srHJXxN4Wn29uVN NQkQ== X-Received: by 10.66.118.129 with SMTP id km1mr26058050pab.112.1425059396928; Fri, 27 Feb 2015 09:49:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.237.39 with HTTP; Fri, 27 Feb 2015 09:49:36 -0800 (PST) In-Reply-To: <201502271504.t1RF4gLR008333@pozo.com> References: <19E33DDA-E850-466F-9BD9-EB7ED257E428@gmail.com> <201502271504.t1RF4gLR008333@pozo.com> From: Arseny Nasokin Date: Fri, 27 Feb 2015 21:49:36 +0400 Message-ID: Subject: Re: Current build world failed: bsdxml is missing? To: Manfred Antar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 17:49:57 -0000 On 27 February 2015 at 18:04, Manfred Antar wrote: > At 03:51 AM 2/27/2015, Arseny Nasokin wrote: > > > >Hi guys, > > > >I've found the reason and I've fixed it. > > > >The reason is I build world with WITHOUT_DYNAMIC_ROOT option. The library > >libgeom depends on libbsdxml and libsbuf which will not linked to target > >program in this case. > > > >I have the patch for several programs in sbin and usr.sbin to fix this > >problem. > > > > > >-- Eir Nym > > It would be nice if someone fixed this, it's been broken for quit awhile > The WITHOUT_DYNAMIC_ROOT option. > If I want static root, have to patch a few makefiles in bin and sbin. > Thanks > > ======================== > || null@pozo.com || > || || > ======================== > > > > Hi, I've created PR 198078 for this particular bug and PR 198079 to add Jenkins target to build WITHOUT_DYNAMIC_ROOT option. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198078 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198079 -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 17:53:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C9595DB for ; Fri, 27 Feb 2015 17:53:51 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20F1EDBF for ; Fri, 27 Feb 2015 17:53:51 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id kv19so6933455vcb.0 for ; Fri, 27 Feb 2015 09:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=6+T8e6xQE0GCtXYMEKw6tRKCf/5guz8Wyfva0/AKCmE=; b=KBaHIbROOhCHiSb5aRHJp2T30WbfIgn6Q0fKvQQXWZjjAff6H/jCgSUIXlheRWnTpH 0UQs7+m2ENBlyexXcCvgh25LHc/1ErMMIcIP/A6feGvx0VyzFqmggbCmGT3YOYGj2LpM YIE71fNlnWuyX568mHq+YrcHjJrxegNM6SQPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=6+T8e6xQE0GCtXYMEKw6tRKCf/5guz8Wyfva0/AKCmE=; b=huL9iuXQ9X6h91y2evRA8OsvfFtBtSMuzr+Jkrc+U7zsvTF6wht6p/epWnqNyuXBb4 2FEcm49sYpGxZL8nkvqzm/OK/gg1vQXglVEJX7H7uXymIhHC5JRe8oHGc3BWx0imr1R7 KZsU95/87VF9HaWL9IZs5sYqbDfP04q/KbA390EyrjZXYtxsKLkehrIEvYFvZSA9kuak tuMnxR9lX3AOPNCrwaoJFh8ZCCuQG+9x1EHUP5sPTyTDV2xiS7/hoZHEJR9fKGRhNUap 9dPTVWAoN29Y2GA7T0Q0ZA0UFFNvU1THo7bnqqvMR8o1+8sUoFw+skbTVWmt8DCWpcqC yskQ== X-Gm-Message-State: ALoCoQmC1wTGrEcGNce6PNR9bwbJHFxML+PJgnHmH1e/r/p4zQsAOBZQTLaX8C2bYueL2UVCnCcr X-Received: by 10.52.254.2 with SMTP id ae2mr14052434vdd.33.1425059630116; Fri, 27 Feb 2015 09:53:50 -0800 (PST) Received: from rsbsd.rsb ([31.200.11.109]) by mx.google.com with ESMTPSA id vp20sm835640vdb.22.2015.02.27.09.53.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 09:53:49 -0800 (PST) Date: Fri, 27 Feb 2015 19:53:46 +0200 From: Beeblebrox To: freebsd-current@freebsd.org Subject: Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon Message-ID: <20150227195346.78dbbca9@rsbsd.rsb> In-Reply-To: <20150227183143.708a0656@rsbsd.rsb> References: <20150227183143.708a0656@rsbsd.rsb> 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.18-1 Precedence: 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, 27 Feb 2015 17:53:51 -0000 I see some errors in my last post, correcting: I used "# service onestop xyz" and NOT "# service kill xyz" One of the TTY freezes occurred when exiting nano: "ctrl+x, y" (exit & save) --=20 FreeBSD_amd64_11-Current_RadeonKMS Please include my email when responding (use Reply To All) From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 18:07:53 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B869B97; Fri, 27 Feb 2015 18:07:53 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F046CF18; Fri, 27 Feb 2015 18:07:52 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t1RI7lbh036508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 21:07:47 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t1RI7k9f036507; Fri, 27 Feb 2015 21:07:46 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 27 Feb 2015 21:07:46 +0300 From: Gleb Smirnoff To: Michael Butler Subject: Re: removing _WANT_IFADDR breaks net-snmp Message-ID: <20150227180746.GP17947@glebius.int.ru> References: <54EFDFB8.6020404@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EFDFB8.6020404@protected-networks.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 18:07:53 -0000 On Thu, Feb 26, 2015 at 10:08:40PM -0500, Michael Butler wrote: M> The recent changes which served to hide "struct ifaddr" have broken M> net-snmp: I know and slowly working on that: https://lists.freebsd.org/pipermail/svn-src-head/2015-February/068674.html -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 19:05:19 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2590DFD0; Fri, 27 Feb 2015 19:05:19 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 A68229BD; Fri, 27 Feb 2015 19:05:15 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1RJ5Cli046303; Fri, 27 Feb 2015 20:05:12 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 7186D30D; Fri, 27 Feb 2015 20:05:11 +0100 (CET) Message-ID: <54F0BFE1.4000000@omnilan.de> Date: Fri, 27 Feb 2015 20:05:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) driver changes available for test References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> <20150226224202.GA14015@mithlond.kdm.org> In-Reply-To: <20150226224202.GA14015@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA4CCF1FDF8A51EB47916334" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 27 Feb 2015 20:05:12 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 19:05:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA4CCF1FDF8A51EB47916334 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime= ): =85 >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 2= 78974: >>> >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt =85 > I'm glad it is working well for you! You can do larger I/O sizes with = the > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel con= fig > file. e.g.: > > options MAXPHYS=3D(1024*1024) > options DFLTPHYS=3D(1024*1024) > > If you set those values larger, you won't be able to do more than 132K = with > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33= > segments * PAGE_SIZE.) Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver limitations corresponding to systems MAX/DFLTPHYS. I thought only silicon limitations define it's value. But in order to have a best matching pre-production test-environment, I nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge= ). Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, LTO3 and DDS5) With DDS5, densitiy is reported as "unknown". If I remember correctly, you have your DDS4 reporting "DDS4"? > > therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197950 > That looks cool. :) I'm not a ports committer, but hopefully one of th= em > will pick it up. Cool it is indeed, but whether it's really usefull or not is beyond my expertise. I couldn't collect much MT experience yet. I know that LTO and similar "modern" MT technology do their own ECC (in the meaning of erasure code, mostly Reed-Solomon). What I don't know (but wanting to be best prepared for) is how arbitrary LTO drives behave, if the one (1) in 10^17 bits was detected to be uncorrectable. If it wasn't detected, the post erasure code (vdmfec in that case) would help for sure. But If the drive just cuts the output, or stops streaming at all, vdmfec was useless=85 According to excerpts of "Study of Perpendicular AME Media in a Linear Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So with DDS, _every_ single block pax(1) writes to tape needs to be internally corrected! Of course, nobody wants zfs' send output stream to DDS, it's much too slow/small, but just to mention. For archives of zfs streams, I don't feel safe relying on the tape drives' FEC, which was designed for backup solutions which do their own blocking+cheksumming, so the very seldom to expect uncorrectable read error would at worst lead to some/single unrecoverable files =96 even in case of database files most likely post-recoverable. But with one flipped bit in the zfs stream, you'd loose hundred of gigabytes, completely unrecoverable! As long as the tape keeps spitting complete blocks, even in the case when the tape knows that the output is not correct, vdmfec ought to be the holy grail :-) Going slightly more off topic: One hot candidate for beeing another holy grail, is mbuffer(1) for me. I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's no problem to stream LTO-4 native rate with a tape-transport-blocksize of 32k. Btw, besides the FIFO-buffering, I'm missing star(1) also for it's multi-volume support. tar(1) in base isn't really useful for tape buddies =96 IMHO it's hardly adequate for any purpose and I don't understand it's widespread usage=85 Most likely the absence of dump(8) fo= r zfs misleads to tar(1) ;-) Were there ever thoughts about implementing FIFO-buffering into sa(4)? We don't have mbuffer(1) in base, but I think, to complete FreeBSD's tape support, users should find all technology/tools, needed for using modern tape drives, in base. If sa(4) could provide sysctl-controlled FIFO-buffering, some base tools were a bit more apropriate for tape usage, I think. Thanks, -Harry --------------enigDA4CCF1FDF8A51EB47916334 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTwv+YACgkQLDqVQ9VXb8iCnwCfXXu0XGD4ukaQRuDFIqD+5T9A bxwAoMehRAjJVEAx1LXBp9Z36sjRqHsf =KhWc -----END PGP SIGNATURE----- --------------enigDA4CCF1FDF8A51EB47916334-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 20:18:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD733B05; Fri, 27 Feb 2015 20:18:54 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73DB7274; Fri, 27 Feb 2015 20:18:54 +0000 (UTC) Received: by padfa1 with SMTP id fa1so25302033pad.2; Fri, 27 Feb 2015 12:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K41COovImQhfsSADswkUp8ZT8Q6vQ8pzAu1Ggi32NDc=; b=EczqHfdRZ2s2PSQtuSTEXvJX0slIZRHxAkEeYk5fkFRMe9pThEG4tbzqyKQXnUBxns tFYgySkmyLOhdAsmPX4Oyk5+rpmlhJovPJ09u41xnFgQIU2Wu9KQ/9V4HbAh5qITOxpO GZeBQt/HghSOMXhPBlHBc7FIcf3ZFu1O8G+3SoDoknYmchbN8Ra62riKOUVje7G2BGnf OjqoiosrjeuzwcLluYvUOTjiC1N+S44j8i1EpTMCRiC0jnfWyaDIOQ3iSPhg3Xjd5diX wcCShTiJfOxi4LeBQAVYysGDBOoQbXolIrEbQ/Q4xihot8jaH4ZQ/pfMebxGS2A3sUYb XfOA== X-Received: by 10.66.139.135 with SMTP id qy7mr26706709pab.144.1425068334134; Fri, 27 Feb 2015 12:18:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.237.39 with HTTP; Fri, 27 Feb 2015 12:18:33 -0800 (PST) In-Reply-To: <54EE2D68.9050209@FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> <54EE2D68.9050209@FreeBSD.org> From: Arseny Nasokin Date: Sat, 28 Feb 2015 00:18:33 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , Glen Barber , freebsd-current , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 20:18:54 -0000 On 25 February 2015 at 23:15, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/25/2015 14:59, Arseny Nasokin wrote: > > On 25 February 2015 at 22:14, Jung-uk Kim > > wrote: > > > > On 02/25/2015 14:05, Glen Barber wrote: > >> On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote: > >>> On 25 February 2015 at 20:27, Jung-uk Kim > > > >>> wrote: > >>>> Your installed yacc(1) is too old, i.e., your world was > >>>> built from head before r274460. FYI, this commit fixes the > >>>> above problem for building from stable: > >>>> > >>>> https://svnweb.freebsd.org/changeset/base/278975 > >>>> > >>>> For building from old head (pre-r274460), you have to > >>>> manually bootstrap yacc first, e.g., something like this: > >>>> > >>>> cd /usr/src/usr.bin/yacc make clean cleandepend make all && > >>>> make install make clean cleandepend cd /usr/src make > >>>> buildworld > >>>> > >>> > >>> Hi, guys, > >>> > >>> I've found the fix by forcing to add yacc(1) to bootstrap > >>> build. > >>> > >>> Makefile.inc1, line 1277: > >>> > >>> if ${BOOTSTRAPPING} < 1001506 _yacc= lib/liby \ > >>> > >>> change to: > >>> > >>> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes > >>> only!!! _yacc= lib/liby \ > >>> > > > >> This can be set to 1001507 now; __FreeBSD_version was bumped > >> earlier today. > > > > Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 > > and __FreeBSD_version was bumped to reflect it. > > > > https://svnweb.freebsd.org/changeset/base/277087 > > > > Jung-uk Kim > > > > > > Jung, > > > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > > invalid YACC. So This conditional expression must be fixed to check > > if this 11.x and yacc is not changed. > > Wow, that's more than 9-month old now. > > > In my hypothetical "patch" I set OSRELDATE to invalid abstract > > future version, because it's only concept and I have no time to fix > > it correctly now. > > If you insist, you can try this: > > - --- Makefile.inc1 > +++ Makefile.inc1 > @@ -1274,7 +1274,8 @@ > _awk= usr.bin/awk > .endif > > - -.if ${BOOTSTRAPPING} < 1001506 > +.if ${BOOTSTRAPPING} < 1001506 || \ > + (${BOOTSTRAPPING} >= 1100000 && ${BOOTSTRAPPING} < 1100046) > _yacc= lib/liby \ > usr.bin/yacc > > (but I won't commit it.) > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b > G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b > RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897 > 7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj > A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF > 1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4= > =3xA9 > -----END PGP SIGNATURE----- > Should I fill PR for? -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 20:21:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC5BBFB2; Fri, 27 Feb 2015 20:21:36 +0000 (UTC) Date: Fri, 27 Feb 2015 20:21:31 +0000 From: Glen Barber To: Arseny Nasokin Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150227202131.GJ28569@hub.FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> <54EE2D68.9050209@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VSaCG/zfRnOiPJtU" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ivan Klymenko , freebsd-current , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 20:21:38 -0000 --VSaCG/zfRnOiPJtU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 28, 2015 at 12:18:33AM +0400, Arseny Nasokin wrote: > On 25 February 2015 at 23:15, Jung-uk Kim wrote: > > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > > > invalid YACC. So This conditional expression must be fixed to check > > > if this 11.x and yacc is not changed. > > > > Wow, that's more than 9-month old now. > > > > > In my hypothetical "patch" I set OSRELDATE to invalid abstract > > > future version, because it's only concept and I have no time to fix > > > it correctly now. > > > > If you insist, you can try this: > > > > - --- Makefile.inc1 > > +++ Makefile.inc1 > > @@ -1274,7 +1274,8 @@ > > _awk=3D usr.bin/awk > > .endif > > > > - -.if ${BOOTSTRAPPING} < 1001506 > > +.if ${BOOTSTRAPPING} < 1001506 || \ > > + (${BOOTSTRAPPING} >=3D 1100000 && ${BOOTSTRAPPING} < 1100046) > > _yacc=3D lib/liby \ > > usr.bin/yacc > > > > (but I won't commit it.) > > >=20 > Should I fill PR for? >=20 Yes, please do. Glen --VSaCG/zfRnOiPJtU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU8NHGAAoJEAMUWKVHj+KTV9YQAI/4E0uolFSGQOkRGjf9aFtC Rf0Fna5IS8PVQAMIFKhcgITIouW5rjG0Ex6JIU7QKPD3QkxJlNUx+wDrXL73DRtM 2vFxnpkJbQdKxPTQ/0nZRtqEkKyvsAjGiw0rdBCnL3lVoYMdtuUUwmoNVzyYDEnP StKRbO4nC/BbanElDMQcx7ZvvQ+JAxoDnb6Zm6Zj6QIdi5eweZpfq5DjShlYBF00 dBjHZ/U6gFhoIgTbO4w/593mWGuPf8A2LmzZXR2pSCF+0izGPXrfIq0okAKXpoT+ DH/rqv8XT8/jq3gIWJe5znrtUV8zzA5bEdT6xi3Fjqc5p6CtwbfaVJFt2u+O+fpZ PQb4lwLDk7CrRIwejxpKr4/uXYXwwRV2d/eN+GFQPMLZZ+Y9ce6ytvF1TUyW3W6t vHNg8G3mLXoUkO/dks/BDJcS4CJ/bsP0bpFM3NQrC1DFqEw8kMHXxr2gQr5ckZb3 9CPFjDP0w7jzmqXmBI+Aoof9D1r6lybwRo3JuvKT0s4/NFtzxGE5AfJqwDK+bcA8 DAY9uDUn2p+Xtt4r7uwr7DQZL38W5OhL1QE9pZM+GKO17CTT99iqClG4l/4XwAL7 2i6h5NvC1o36u8+2xCjihk63LM2+PFZknyWv5/oWeAm/E1lJdlAMCfoSg4V+AtVn 5fpL7T/BEPVo0xVZXKLT =69uh -----END PGP SIGNATURE----- --VSaCG/zfRnOiPJtU-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 20:40:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F57E7D8; Fri, 27 Feb 2015 20:40:28 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24D1A6B1; Fri, 27 Feb 2015 20:40:28 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so23553332pdb.5; Fri, 27 Feb 2015 12:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GYCdT8602uGdBNc8qZ9KoMxdGiceBqOuIyIK4w8gmXE=; b=DyLekIFyCdnwgAeJesMOLHc3OAu83eVA5bilM7Cu9aLfilRLVzjNP4gF5m7ze5Eg2k l1hL5kxD6rvV+HT6ZijKb2ZY5Vhf09UNt8OaSG7slweWOQCM1vtnPI38ulNIBsJI1ho7 KIub8rs1OoETSQ4eYTLBJe6EKT187Y2UwgmejPSqcbuO+m2ztw6KNKTqPaWjCzhxgG3T u85mCIs/Us6yyJOToyjjFsRWPK7yrcWpVOrkYNUveY9qidUWj+dlfyH9C+0SAPND0t9m O5/VsEEImt7rJYKQ2BeiTXATMzL11VVMSiZO4ktSScdkn02tTujXlTZP/z9Yqf542IE2 E3yg== X-Received: by 10.66.100.202 with SMTP id fa10mr27144436pab.36.1425069627668; Fri, 27 Feb 2015 12:40:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.237.39 with HTTP; Fri, 27 Feb 2015 12:40:04 -0800 (PST) In-Reply-To: <20150227202131.GJ28569@hub.FreeBSD.org> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <20150225190512.GH1161@hub.FreeBSD.org> <54EE1F1D.8060807@FreeBSD.org> <54EE2D68.9050209@FreeBSD.org> <20150227202131.GJ28569@hub.FreeBSD.org> From: Arseny Nasokin Date: Sat, 28 Feb 2015 00:40:04 +0400 Message-ID: Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) To: Glen Barber Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ivan Klymenko , freebsd-current , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 20:40:28 -0000 On 27 February 2015 at 23:21, Glen Barber wrote: > On Sat, Feb 28, 2015 at 12:18:33AM +0400, Arseny Nasokin wrote: > > On 25 February 2015 at 23:15, Jung-uk Kim wrote: > > > > I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and > > > > invalid YACC. So This conditional expression must be fixed to check > > > > if this 11.x and yacc is not changed. > > > > > > Wow, that's more than 9-month old now. > > > > > > > In my hypothetical "patch" I set OSRELDATE to invalid abstract > > > > future version, because it's only concept and I have no time to fix > > > > it correctly now. > > > > > > If you insist, you can try this: > > > > > > - --- Makefile.inc1 > > > +++ Makefile.inc1 > > > @@ -1274,7 +1274,8 @@ > > > _awk= usr.bin/awk > > > .endif > > > > > > - -.if ${BOOTSTRAPPING} < 1001506 > > > +.if ${BOOTSTRAPPING} < 1001506 || \ > > > + (${BOOTSTRAPPING} >= 1100000 && ${BOOTSTRAPPING} < 1100046) > > > _yacc= lib/liby \ > > > usr.bin/yacc > > > > > > (but I won't commit it.) > > > > > > > Should I fill PR for? > > > > Yes, please do. > > Glen > > Hi, I've filled PR 198081 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198081 -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 21:07:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97A8DF0D for ; Fri, 27 Feb 2015 21:07:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 877819CB for ; Fri, 27 Feb 2015 21:07:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 81CA579D for ; Fri, 27 Feb 2015 21:07:40 +0000 (UTC) Date: Fri, 27 Feb 2015 21:07:40 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <276322690.39.1425071260438.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #780 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 21:07:40 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 22:50:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1E48278; Fri, 27 Feb 2015 22:50:18 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DF057A7; Fri, 27 Feb 2015 22:50:18 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 30FB9358C67; Fri, 27 Feb 2015 23:50:14 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 1C69F28494; Fri, 27 Feb 2015 23:50:14 +0100 (CET) Date: Fri, 27 Feb 2015 23:50:14 +0100 From: Jilles Tjoelker To: Garrett Cooper Subject: Re: r279278 failed to build (yacc: maximum table size exceeded) Message-ID: <20150227225013.GA66202@stack.nl> References: <20150225154327.GD1161@hub.FreeBSD.org> <20150225182201.216f6fee@nonamehost.local> <54EE05EA.3030509@FreeBSD.org> <8E4B6A07-BEB7-46B9-BFD2-0B3F33162760@gmail.com> <54EE1E38.30106@FreeBSD.org> <95891DFC-786D-4064-A9F9-7A8E434EC568@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95891DFC-786D-4064-A9F9-7A8E434EC568@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ivan Klymenko , freebsd-current@freebsd.org, Glen Barber , Arseny Nasokin , Allan Jude , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 22:50:18 -0000 On Wed, Feb 25, 2015 at 12:11:29PM -0800, Garrett Cooper wrote: > I was going to propose something a bit more radical — I can remove the > BOOTSTRAPPING conditionals and simplify the code on 10-STABLE / > 11-CURRENT. > Maintaining BOOTSTRAPPING is error prone and it’s not saving much time > in the long run in builds (it's taking longer to diagnose issues, test > them, and commit fixes which will break at a later date). I’ve been > bitten by this once because I don’t run ancient CURRENT/STABLE > (r279198) and here are a couple follow up commits bumping tools > versions in the past (e.g. r278975, r269662, etc). > Just a thought. This may be appropriate for contributed code that will build on older FreeBSD versions without issues, but I don't like being forced to add (mostly untested) compatibility code with usage of recent libc features. For example, utilities like cp and touch currently use utimensat/futimens without #ifdef mess or extra code in libegacy. The strict BOOTSTRAPPING conditionals allow removing bootstrap tools eventually, when building from such old versions as to need them is no longer supported. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 22:56:44 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD60C432; Fri, 27 Feb 2015 22:56:44 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6EE88E; Fri, 27 Feb 2015 22:56:44 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id D89906058 ; Fri, 27 Feb 2015 22:56:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150217183645.GA30947@mithlond.kdm.org> Date: Fri, 27 Feb 2015 17:56:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Fri, 27 Feb 2015 23:11:09 +0000 Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 22:56:44 -0000 > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry wrote: >=20 > On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: >>=20 >>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry = wrote: >>>=20 >>>=20 >>> I have a fairly large set of changes to the sa(4) driver and mt(1) = driver >>> that I'm planning to commit in the near future. >>>=20 >>> A description of the changes is here and below in this message. >>>=20 >>> If you have tape hardware and the inclination, I'd appreciate = testing and >>> feedback. >>=20 >> I have a DLT 8000 and an SDLT 220. >>=20 >> I don't have anything running current, but I have a spare machine = which I could use for testing. >>=20 >> Do you see any value is tests with that hardware? I'd be testing it = via Bacula. >>=20 >> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula = committer. >>=20 >=20 > Actually, yes. Bacula is a bit tricky to configure, so your trying it = out > would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware = issues. I may be able to try tomorrow. >=20 > In looking at the manuals for both the SDLT 220 and the DLT 8000, they = both > claim to support long position information for the SCSI READ POSITION > command. >=20 > You can see what I'm talking about by doing: >=20 > mt eod > mt status >=20 > On my DDS-4 tape drive, this shows: >=20 > # mt -f /dev/nsa3 status > Drive: sa3: Serial Number: HJ00YWY > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x26:DDS-4 1024 bytes 97000 enabled (DCLZ) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: -1 Calc Record Number: -1 > Residual: 0 Reported File Number: -1 Reported Record Number: -1 > Flags: None >=20 > But on an LTO-5, which will give long position information, I get: >=20 > [root@doc ~]# mt status > Drive: sa0: > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x58:LTO-5 variable 384607 enabled (0x1) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 2 Calc Record Number: -1 > Residual: 0 Reported File Number: 2 Reported Record Number: = 32373 > Flags: None >=20 > That, in combination with the changes I made to the position = information > code in the driver, mean that even the old MTIOCGET ioctl should = return an > accurate file number at end of data. e.g., on the LTO-5: >=20 > [root@doc ~]# mt ostatus > Mode Density Blocksize bpi Compression > Current: 0x58:LTO-5 variable 384607 0x1 > ---------available modes--------- > 0: 0x58:LTO-5 variable 384607 0x1 > 1: 0x58:LTO-5 variable 384607 0x1 > 2: 0x58:LTO-5 variable 384607 0x1 > 3: 0x58:LTO-5 variable 384607 0x1 > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 2 Record Number: -1 Residual Count -1 >=20 > So the thing to try, in addition to just making sure that Bacula = continues > to work properly, is to try setting this for the tape drive in > bacula-sd.conf: >=20 > Hardware End of Medium =3D yes >=20 > It looks like the Bacula tape program (btape) has a test mode, and it = would > be good to run through the tests on one of the tape drives and see = whether > they work, and whether the results are different before and after the > changes. I'm not sure how to enable the test mode. >=20 >> I'll let the other Bacula devs know about this. They deal with the = hardware. I work on PostgreSQL. >>=20 >=20 > Thanks! If there are additional features they would like out of the = tape > driver, I'm happy to talk about it. (Or help if they'd like to use = the new > status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-current@FreeBSD.ORG Fri Feb 27 23:33:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D664DCC9 for ; Fri, 27 Feb 2015 23:33:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C4817CA0 for ; Fri, 27 Feb 2015 23:33:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 98E117CF for ; Fri, 27 Feb 2015 23:33:12 +0000 (UTC) Date: Fri, 27 Feb 2015 23:33:12 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <223256842.41.1425079992574.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <276322690.39.1425071260438.JavaMail.jenkins@jenkins-9.freebsd.org> References: <276322690.39.1425071260438.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #781 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Feb 2015 23:33:12 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 00:08:55 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B532D479; Sat, 28 Feb 2015 00:08:55 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E79AFB7; Sat, 28 Feb 2015 00:08:55 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t1S08kDJ035820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 17:08:46 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1S08kkt035819; Fri, 27 Feb 2015 17:08:46 -0700 (MST) (envelope-from ken) Date: Fri, 27 Feb 2015 17:08:46 -0700 From: "Kenneth D. Merry" To: Harald Schmalzbauer Subject: Re: sa(4) driver changes available for test Message-ID: <20150228000846.GA33584@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> <20150226224202.GA14015@mithlond.kdm.org> <54F0BFE1.4000000@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F0BFE1.4000000@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Fri, 27 Feb 2015 17:08:46 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,NORMAL_HTTP_TO_IP,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 00:08:55 -0000 On Fri, Feb 27, 2015 at 20:05:05 +0100, Harald Schmalzbauer wrote: > Bez?glich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime): > > ? > >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > >>> > >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt > ? > > > I'm glad it is working well for you! You can do larger I/O sizes with the > > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config > > file. e.g.: > > > > options MAXPHYS=(1024*1024) > > options DFLTPHYS=(1024*1024) > > > > If you set those values larger, you won't be able to do more than 132K with > > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 > > segments * PAGE_SIZE.) > > Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver > limitations corresponding to systems MAX/DFLTPHYS. I thought only > silicon limitations define it's value. It depends on the driver. I thought that the Adaptec drivers go off of MAXPHYS (because that's what the driver author told me last week :), but in looking at the code, they actually have a hard-coded value that can be increased. You can bump AHC_MAXPHYS or AHD_MAXPHYS in aic7xxx_osm.h or aic79xx_osm.h, respectively. In order to make any difference, though, you would have to bump MAXPHYS/DFLTPHYS (so the sa(4) driver will use that value) or change the ahc(4)/ahd(4) driver to set the maxio field in the path inquiry CCB. > But in order to have a best matching pre-production test-environment, I > nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on > PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, > which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge). Okay. That should work. > Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, > LTO3 and DDS5) > With DDS5, densitiy is reported as "unknown". If I remember correctly, > you have your DDS4 reporting "DDS4"? That means that we need to add DDS5 to the density table in libmt. Can you send the output of 'mt status -v'? It would actually be helpful for all three drives. Also, do any of your drives give a full report for 'mt getdensity'? If so, can you send that as well? (By full report, I mean more than one line.) We don't have density codes for DDS-5/DAT 72, DAT 160 or DAT 320 yet. It looks like DDS-5 should be 0x47. > > > therefore I'd like to point to the new port misc/vdmfec > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 > > That looks cool. :) I'm not a ports committer, but hopefully one of them > > will pick it up. > > Cool it is indeed, but whether it's really usefull or not is beyond my > expertise. I couldn't collect much MT experience yet. > I know that LTO and similar "modern" MT technology do their own ECC (in > the meaning of erasure code, mostly Reed-Solomon). > What I don't know (but wanting to be best prepared for) is how arbitrary > LTO drives behave, if the one (1) in 10^17 bits was detected to be > uncorrectable. > If it wasn't detected, the post erasure code (vdmfec in that case) would > help for sure. > But If the drive just cuts the output, or stops streaming at all, vdmfec > was useless? There is a difference in the uncorrectable bit error rate and the undetectable bit error rate. The uncorrectable bit error rate for LTO-6 is 1 in 10^17. It is 1 in 10^19 for Oracle T10000 C/D drives, and 1 in 10^20 for IBM TS1150. Seagate Enterprise drives claim to have an uncorrectable bit error rate of 1 sector per 10^15 bits read. See: http://www.oracle.com/us/products/servers-storage/storage/tape-storage/t10000c-reliability-wp-409919.pdf http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=2513 http://www.seagate.com/www-content/product-content/enterprise-hdd-fam/enterprise-capacity-3-5-hdd/constellation-es-4/en-us/docs/enterprise-capacity-3-5-hdd-ds1791-8-1410us.pdf The second white paper claims that tape has an undetectable bit error rate of 1 in 1.6x10^33 bits. I assume it is referring to TS1150, but I don't know for sure. It is far more likely that your tape or tape drive will break than it is that you would get a bad bit back from the drive. > According to excerpts of "Study of Perpendicular AME Media in a Linear > Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS > has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So > with DDS, _every_ single block pax(1) writes to tape needs to be > internally corrected! Of course, nobody wants zfs' send output stream to > DDS, it's much too slow/small, but just to mention. > > For archives of zfs streams, I don't feel safe relying on the tape > drives' FEC, which was designed for backup solutions which do their own > blocking+cheksumming, so the very seldom to expect uncorrectable read > error would at worst lead to some/single unrecoverable files ? even in > case of database files most likely post-recoverable. > But with one flipped bit in the zfs stream, you'd loose hundred of > gigabytes, completely unrecoverable! > As long as the tape keeps spitting complete blocks, even in the case > when the tape knows that the output is not correct, vdmfec ought to be > the holy grail :-) A tape drive or hard drive isn't going to return bits that it knows aren't correct. They'll return an error instead. The bit error rate of a tape drive is lower than the bit error rate for a hard drive, so you're less likely to get bad bits back from a tape drive than a disk drive. Another thing you have to consider, if you're concerned about the bit error rates, is the error rate of the link that you're using to connect to the tape or disk drive. The tape/disk might read the block correctly, but you could also get corruption on the link. This article talks about disk/tape bit error rates and the link bit error rates. I haven't read the whole thing, but it should make for some interesting reading: http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-1.html With ZFS, you get protection from link and disk errors via its checksums and RAID. If there is a checksum error on one drive, it can rebuild the corrupted data using the parity/mirror information. If you want to do the same thing with a tape drive, you would need to write your data to two tapes, or have another copy somewhere that you could use as your recovery copy in case of corruption. FWIW, the sa(4) driver now supports protection information on a per-block basis. LTO (at least newer drives) and TS drives support adding a CRC on the end of each tape block written to and read from the drive. The drive will verify it on writes, and supply the checksum on reads. You could also do your own FEC scheme. > Going slightly more off topic: > One hot candidate for beeing another holy grail, is mbuffer(1) for me. > > I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but > for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge > block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's > no problem to stream LTO-4 native rate with a tape-transport-blocksize > of 32k. > Btw, besides the FIFO-buffering, I'm missing star(1) also for it's > multi-volume support. tar(1) in base isn't really useful for tape > buddies ? IMHO it's hardly adequate for any purpose and I don't > understand it's widespread usage? Most likely the absence of dump(8) for > zfs misleads to tar(1) ;-) > > Were there ever thoughts about implementing FIFO-buffering into sa(4)? > We don't have mbuffer(1) in base, but I think, to complete FreeBSD's > tape support, users should find all technology/tools, needed for using > modern tape drives, in base. If sa(4) could provide sysctl-controlled > FIFO-buffering, some base tools were a bit more apropriate for tape > usage, I think. It would probably be easier and better to just put mbuffer in the base. The challenge with doing buffering in the tape driver is that the userland application would need to use a different API to write to the driver. The standard write(2) API requires that it return status when the block is written. So if we're going to buffer up a bunch of I/O in the tape driver, we would need to do it with an async I/O type interface so that we could return an individual error status for any I/O that fails. If you're not able to stream to a tape drive with ZFS send, but it does work with mbuffer, then the issue is just an inconsistent output rate from ZFS send. mbuffer overcomes the consistency problem with buffering. We could do the buffering in the kernel, but that would mean rewriting any userland application that wants to talk to the tape drive. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 02:36:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D470D11 for ; Sat, 28 Feb 2015 02:36:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB5DF99 for ; Sat, 28 Feb 2015 02:36:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DF055817 for ; Sat, 28 Feb 2015 02:36:49 +0000 (UTC) Date: Sat, 28 Feb 2015 02:36:49 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2104775957.43.1425091009860.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <223256842.41.1425079992574.JavaMail.jenkins@jenkins-9.freebsd.org> References: <223256842.41.1425079992574.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #782 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 02:36:49 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 06:49:03 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CA4DDE2; Sat, 28 Feb 2015 06:49:03 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 200F9C90; Sat, 28 Feb 2015 06:48:58 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t1S6m8l0040338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 23:48:08 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1S6lurr040337; Fri, 27 Feb 2015 23:47:56 -0700 (MST) (envelope-from ken) Date: Fri, 27 Feb 2015 23:47:56 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150228064756.GA40281@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Fri, 27 Feb 2015 23:48:08 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 06:49:03 -0000 On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: > > > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry wrote: > > > > On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: > >> > >>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry wrote: > >>> > >>> > >>> I have a fairly large set of changes to the sa(4) driver and mt(1) driver > >>> that I'm planning to commit in the near future. > >>> > >>> A description of the changes is here and below in this message. > >>> > >>> If you have tape hardware and the inclination, I'd appreciate testing and > >>> feedback. > >> > >> I have a DLT 8000 and an SDLT 220. > >> > >> I don't have anything running current, but I have a spare machine which I could use for testing. > >> > >> Do you see any value is tests with that hardware? I'd be testing it via Bacula. > >> > >> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. > >> > > > > Actually, yes. Bacula is a bit tricky to configure, so your trying it out > > would be helpful if you have the time. > > I have been unable to test yet. I've encountered time and hardware issues. I know how that goes! (On both counts.) > I may be able to try tomorrow. So I have tested building it and it does build at least. If you're able to figure out some of the answers below, that would be great! > > > > In looking at the manuals for both the SDLT 220 and the DLT 8000, they both > > claim to support long position information for the SCSI READ POSITION > > command. > > > > You can see what I'm talking about by doing: > > > > mt eod > > mt status > > > > On my DDS-4 tape drive, this shows: > > > > # mt -f /dev/nsa3 status > > Drive: sa3: Serial Number: HJ00YWY > > --------------------------------- > > Mode Density Blocksize bpi Compression > > Current: 0x26:DDS-4 1024 bytes 97000 enabled (DCLZ) > > --------------------------------- > > Current Driver State: at rest. > > --------------------------------- > > Partition: 0 Calc File Number: -1 Calc Record Number: -1 > > Residual: 0 Reported File Number: -1 Reported Record Number: -1 > > Flags: None > > > > But on an LTO-5, which will give long position information, I get: > > > > [root@doc ~]# mt status > > Drive: sa0: > > --------------------------------- > > Mode Density Blocksize bpi Compression > > Current: 0x58:LTO-5 variable 384607 enabled (0x1) > > --------------------------------- > > Current Driver State: at rest. > > --------------------------------- > > Partition: 0 Calc File Number: 2 Calc Record Number: -1 > > Residual: 0 Reported File Number: 2 Reported Record Number: 32373 > > Flags: None > > > > That, in combination with the changes I made to the position information > > code in the driver, mean that even the old MTIOCGET ioctl should return an > > accurate file number at end of data. e.g., on the LTO-5: > > > > [root@doc ~]# mt ostatus > > Mode Density Blocksize bpi Compression > > Current: 0x58:LTO-5 variable 384607 0x1 > > ---------available modes--------- > > 0: 0x58:LTO-5 variable 384607 0x1 > > 1: 0x58:LTO-5 variable 384607 0x1 > > 2: 0x58:LTO-5 variable 384607 0x1 > > 3: 0x58:LTO-5 variable 384607 0x1 > > --------------------------------- > > Current Driver State: at rest. > > --------------------------------- > > File Number: 2 Record Number: -1 Residual Count -1 > > > > So the thing to try, in addition to just making sure that Bacula continues > > to work properly, is to try setting this for the tape drive in > > bacula-sd.conf: > > > > Hardware End of Medium = yes > > > > It looks like the Bacula tape program (btape) has a test mode, and it would > > be good to run through the tests on one of the tape drives and see whether > > they work, and whether the results are different before and after the > > changes. I'm not sure how to enable the test mode. > > > >> I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. > >> > > > > Thanks! If there are additional features they would like out of the tape > > driver, I'm happy to talk about it. (Or help if they'd like to use the new > > status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) > > > > Ken > > -- > > Kenneth Merry > > ken@FreeBSD.ORG > > ? > Dan Langille > http://langille.org/ > > > > > Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 08:38:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C289698F for ; Sat, 28 Feb 2015 08:38:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B0CF27CB for ; Sat, 28 Feb 2015 08:38:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 96EF08D0 for ; Sat, 28 Feb 2015 08:38:17 +0000 (UTC) Date: Sat, 28 Feb 2015 08:38:17 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <803912478.44.1425112697489.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2104775957.43.1425091009860.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2104775957.43.1425091009860.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #783 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 08:38:17 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 14:38:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C75D8F1B for ; Sat, 28 Feb 2015 14:38:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B504FC63 for ; Sat, 28 Feb 2015 14:38:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F0E18965 for ; Sat, 28 Feb 2015 14:38:39 +0000 (UTC) Date: Sat, 28 Feb 2015 14:38:39 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <685493215.45.1425134319755.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <803912478.44.1425112697489.JavaMail.jenkins@jenkins-9.freebsd.org> References: <803912478.44.1425112697489.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #784 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 14:38:39 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 15:53:21 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B76E386; Sat, 28 Feb 2015 15:53:21 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FDCF400; Sat, 28 Feb 2015 15:53:20 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id EA2946F06 ; Sat, 28 Feb 2015 15:53:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150228064756.GA40281@mithlond.kdm.org> Date: Sat, 28 Feb 2015 10:53:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <36E25B53-8D76-4409-87FD-5E0369A4A513@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> <20150228064756.GA40281@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 15:53:21 -0000 > On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry wrote: >=20 > On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: >>=20 >>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: >>>>=20 >>>>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>>=20 >>>>> I have a fairly large set of changes to the sa(4) driver and mt(1) = driver >>>>> that I'm planning to commit in the near future. >>>>>=20 >>>>> A description of the changes is here and below in this message. >>>>>=20 >>>>> If you have tape hardware and the inclination, I'd appreciate = testing and >>>>> feedback. >>>>=20 >>>> I have a DLT 8000 and an SDLT 220. >>>>=20 >>>> I don't have anything running current, but I have a spare machine = which I could use for testing. >>>>=20 >>>> Do you see any value is tests with that hardware? I'd be testing it = via Bacula. >>>>=20 >>>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula = committer. >>>>=20 >>>=20 >>> Actually, yes. Bacula is a bit tricky to configure, so your trying = it out >>> would be helpful if you have the time. >>=20 >> I have been unable to test yet. I've encountered time and hardware = issues. >=20 > I know how that goes! (On both counts.) Hardware issues fixed. Now upgrading that zfsroot box from 9.2 to 10.1 = RELEASE. sudo freebsd-update -r 10.1-RELEASE upgrade Then I'll grab sources, apply your 10 STABLE patches, and build world. >=20 >> I may be able to try tomorrow. >=20 > So I have tested building it and it does build at least. If you're = able to > figure out some of the answers below, that would be great! >=20 >>>=20 >>> In looking at the manuals for both the SDLT 220 and the DLT 8000, = they both >>> claim to support long position information for the SCSI READ = POSITION >>> command. >>>=20 >>> You can see what I'm talking about by doing: >>>=20 >>> mt eod >>> mt status >>>=20 >>> On my DDS-4 tape drive, this shows: >>>=20 >>> # mt -f /dev/nsa3 status >>> Drive: sa3: Serial Number: HJ00YWY >>> --------------------------------- >>> Mode Density Blocksize bpi Compression >>> Current: 0x26:DDS-4 1024 bytes 97000 enabled = (DCLZ) >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> Partition: 0 Calc File Number: -1 Calc Record Number: -1 >>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 >>> Flags: None >>>=20 >>> But on an LTO-5, which will give long position information, I get: >>>=20 >>> [root@doc ~]# mt status >>> Drive: sa0: >>> --------------------------------- >>> Mode Density Blocksize bpi Compression >>> Current: 0x58:LTO-5 variable 384607 enabled (0x1) >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> Partition: 0 Calc File Number: 2 Calc Record Number: -1 >>> Residual: 0 Reported File Number: 2 Reported Record Number: = 32373 >>> Flags: None >>>=20 >>> That, in combination with the changes I made to the position = information >>> code in the driver, mean that even the old MTIOCGET ioctl should = return an >>> accurate file number at end of data. e.g., on the LTO-5: >>>=20 >>> [root@doc ~]# mt ostatus >>> Mode Density Blocksize bpi Compression >>> Current: 0x58:LTO-5 variable 384607 0x1 >>> ---------available modes--------- >>> 0: 0x58:LTO-5 variable 384607 0x1 >>> 1: 0x58:LTO-5 variable 384607 0x1 >>> 2: 0x58:LTO-5 variable 384607 0x1 >>> 3: 0x58:LTO-5 variable 384607 0x1 >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> File Number: 2 Record Number: -1 Residual Count -1 >>>=20 >>> So the thing to try, in addition to just making sure that Bacula = continues >>> to work properly, is to try setting this for the tape drive in >>> bacula-sd.conf: >>>=20 >>> Hardware End of Medium =3D yes >>>=20 >>> It looks like the Bacula tape program (btape) has a test mode, and = it would >>> be good to run through the tests on one of the tape drives and see = whether >>> they work, and whether the results are different before and after = the >>> changes. I'm not sure how to enable the test mode. >>>=20 >>>> I'll let the other Bacula devs know about this. They deal with the = hardware. I work on PostgreSQL. >>>>=20 >>>=20 >>> Thanks! If there are additional features they would like out of the = tape >>> driver, I'm happy to talk about it. (Or help if they'd like to use = the new >>> status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) >>>=20 >>> Ken >>> --=20 >>> Kenneth Merry >>> ken@FreeBSD.ORG >>=20 >> ?=20 >> Dan Langille >> http://langille.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 16:48:04 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F09E42B; Sat, 28 Feb 2015 16:48:04 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E93E9CAA; Sat, 28 Feb 2015 16:48:03 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 1A0636FA9 ; Sat, 28 Feb 2015 16:48:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> Date: Sat, 28 Feb 2015 11:48:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 16:48:04 -0000 > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >=20 >=20 > I have updated the patches. >=20 > I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since > I committed those separately. >=20 > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) >=20 > Rough draft commit message: >=20 > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >=20 > The patches against FreeBSD/head as of SVN revision 278975: >=20 > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt >=20 > And (untested) patches against FreeBSD stable/10 as of SVN revision = 278974: >=20 > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Not sure what I've done wrong here. I've applied your patches and run make buildworld against: [root@cuppy:/usr/src] # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 278721 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 278721 Last Changed Date: 2015-02-13 21:46:22 +0000 (Fri, 13 Feb 2015) But I get: rm -f .depend GPATH GRTAGS GSYMS GTAGS =3D=3D=3D> lib/libmp (cleandir) rm -f Version.map libmp.3.gz libmp.3.cat.gz rm -f a.out mpasbn.o mpasbn.o.tmp=20 rm -f mpasbn.po mpasbn.po.tmp rm -f mpasbn.So mpasbn.so mpasbn.So.tmp rm -f libmp.so rm -f libmp.a libmp_p.a libmp.so.7 rm -f Version.map rm -f .depend GPATH GRTAGS GSYMS GTAGS =3D=3D=3D> lib/libmt (cleandir) cd: /usr/src/lib/libmt: No such file or directory *** Error code 2 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src >=20 > Thanks, >=20 > Ken >=20 > On Fri, Feb 13, 2015 at 17:32:32 -0700, Kenneth D. Merry wrote: >>=20 >> I have a fairly large set of changes to the sa(4) driver and mt(1) = driver >> that I'm planning to commit in the near future. >>=20 >> A description of the changes is here and below in this message. >>=20 >> If you have tape hardware and the inclination, I'd appreciate testing = and >> feedback. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Rough draft commit message: >>=20 >> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt >>=20 >> The patches against FreeBSD/head as of SVN revision 278706: >>=20 >> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt >>=20 >> And (untested) patches against FreeBSD stable/10 as of SVN revision = 278721. >>=20 >> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The intent is to get the tape infrastructure more up to date, so we = can >> support LTFS and more modern tape drives: >>=20 >> http://www.ibm.com/systems/storage/tape/ltfs/ >>=20 >> I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port = depends >> on the patches linked above. It isn't fully cleaned up and ready for >> redistribution. If you're interested, though, let me know and I'll = tell >> you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 = or >> TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and = older >> drives don't have the necessary features to support LTFS. >>=20 >> The commit message below outlines most of the changes. >>=20 >> A few comments: >>=20 >> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. >>=20 >> 2. The XML output is similar to what GEOM and CTL do. It would be = nice to >> figure out how to put a standard schema on it so that standard = tools >> could read it. I don't know how feasible that is, since I haven't >> time to dig into it. If anyone has suggestions on whether that is >> feasible or advisable, I'd appreciate feedback. >>=20 >> 3. I have tested with a reasonable amount of tape hardware (see below = for a >> list), but more testing and feedback would be good. >>=20 >> 4. Standard 'mt status' output looks like this: >>=20 >> # mt -f /dev/nsa3 status -v >> Drive: sa3: Serial Number: 101500520A >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x5a:LTO-6 variable 384607 enabled (0xff) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >> Residual: 0 Reported File Number: 0 Reported Record Number: 0 >> Flags: BOP >>=20 >> 5. 'mt status -v' looks like this: >>=20 >> # mt -f /dev/nsa3 status -v >> Drive: sa3: Serial Number: 101500520A >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x5a:LTO-6 variable 384607 enabled (0xff) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >> Residual: 0 Reported File Number: 0 Reported Record Number: 0 >> Flags: BOP >> --------------------------------- >> Tape I/O parameters: >> Maximum I/O size allowed by driver and controller (maxio): 1081344 = bytes >> Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes >> Maximum block size supported by tape drive and media (max_blk): = 8388608 bytes >> Minimum block size supported by tape drive and media (min_blk): 1 = bytes >> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >> Maximum possible I/O size (max_effective_iosize): 1081344 bytes >>=20 >> 6. Existing applications should work without changes. If not, please = let >> me know. Hopefully they will move over time to the new interfaces. >>=20 >> 7. There are lots of additional features that could be added later. >> Append-only support, encryption, more log pages, etc. >>=20 >> 8. I have SCSI READ ATTRIBUTE changes for camcontrol(8) that will go = in >> separately. These changes allow displaying the contents of the MAM >> (Medium Auxiliary Memory) chips on LTO, TS and other modern tape = drives. >> These are good, and a future possible direction is adding = attributes=20 >> to the status XML from the sa(4) driver. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Significant upgrades to sa(4) and mt(1). >>=20 >> The primary focus of these changes is to modernize FreeBSD's >> tape infrastructure so that we can take advantage of some of the >> features of modern tape drives and allow support for LTFS. >>=20 >> Significant changes and new features include: >>=20 >> o sa(4) driver status and parameter information is now exported via = an >> XML structure. This will allow for changes and improvements later >> on that will not break userland applications. The old MTIOCGET >> status ioctl remains, so applications using the existing interface >> will not break. >>=20 >> o 'mt status' now reports drive-reported tape position information >> as well as the previously available calculated tape position >> information. These numbers will be different at times, because >> the drive-reported block numbers are relative to BOP (Beginning >> of Partition), but the block numbers calculated previously via >> sa(4) (and still provided) are relative to the last filemark. >> Both numbers are now provided. 'mt status' now also shows the >> drive INQUIRY information, serial number and any position flags >> (BOP, EOT, etc.) provided with the tape position information. >> 'mt status -v' adds information on the maximum possible I/O size, >> and the underlying values used to calculate it. >>=20 >> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. >>=20 >> The extra devices were originally added as place holders for >> density-specific device nodes. Some OSes (NetBSD, NetApp's OnTap >> and Solaris) have had device nodes that, when you write to them, >> will automatically select a given density for particular tape = drives. >>=20 >> This is a convenient way of switching densities, but it was never >> implemented in FreeBSD. Only the device nodes were there, and that >> sometimes confused users. >>=20 >> For modern tape devices, the density is generally not selectable >> (e.g. with LTO) or defaults to the highest availble density when >> the tape is rewritten from BOT (e.g. TS11X0). So, for most users, >> density selection won't be necessary. If they do need to select >> the density, it is easy enough to use 'mt density' to change it. >>=20 >> o Protection information is now supported. This is either a >> Reed-Solomon CRC or CRC32 that is included at the end of each block >> read and written. On write, the tape drive verifies the CRC, and >> on read, the tape drive provides a CRC for the userland application >> to verify. >>=20 >> o New, extensible tape driver parameter get/set interface. >>=20 >> o Density reporting information. For drives that support it, >> 'mt getdensity' will show detailed information on what formats the >> tape drive supports, and what formats the tape drive supports. >>=20 >> o Some mt(1) functionality moved into a new mt(3) library so that >> external applications can reuse the code. >>=20 >> o The new mt(3) library includes helper routines to aid in parsing >> the XML output of the sa(4) driver, and build a tree of driver >> metadata. >>=20 >> o Support for the MTLOAD (load a tape in the drive) and MTWEOFI >> (write filemark immediate) ioctls needed by IBM's LTFS >> implementation. >>=20 >> o Improve device departure behavior for the sa(4) driver. The = previous >> implementation led to hangs when the device was open. >>=20 >> o This has been tested on the following types of drives: >> IBM TS1150 >> IBM TS1140 >> IBM LTO-6 >> IBM LTO-5 >> HP LTO-2 >> Seagate DDS-4 >> Quantum DLT-4000 >> Exabyte 8505 >> Sony DDS-2 >>=20 >> contrib/groff/tmac/doc-syms, >> share/mk/bsd.libnames.mk, >> lib/Makefile, >> Add libmt. >>=20 >> lib/libmt/Makefile, >> lib/libmt/mt.3, >> lib/libmt/mtlib.c, >> lib/libmt/mtlib.h, >> New mt(3) library that contains functions moved from mt(1) and >> new functions needed to interact with the updated sa(4) driver. >>=20 >> This includes XML parser helper functions that application = writers >> can use when writing code to query tape parameters. >>=20 >> rescue/rescue/Makefile: >> Add -lmt to CRUNCH_LIBS. >>=20 >> sys/cam/cam_ccb.h >> Add a new flag value for the XPT_DEV_ADVINFO CCB, = CDAI_FLAG_NONE. >>=20 >> sbin/camcontrol/camcontrol.c, >> sys/cam/scsi/scsi_da.c, >> sys/cam/scsi/scsi_enc_ses.c, >> sys/dev/mps/mps_sas.c: >> Make sure the flags for the XPT_DEV_ADVINFO CCB are set = correctly. >> This prevents unintended attempts to set advanced information >> values when XPT_DEV_ADVINFO CCBs are not pre-zeroed. >>=20 >> src/share/man/man4/mtio.4 >> Clarify this man page a bit, and since it contains what is >> essentially the mtio.h header file, add new ioctls and structure >> definitions from mtio.h. >>=20 >> src/share/man/man4/sa.4 >> Update BUGS and maintainer section. >>=20 >> sys/cam/scsi/scsi_all.c, >> sys/cam/scsi/scsi_all.h: >> Add SCSI SECURITY PROTOCOL IN/OUT CDB definitions and CDB = building >> functions. >>=20 >> sys/cam/scsi/scsi_sa.c >> sys/cam/scsi/scsi_sa.h >> Many tape driver changes, largely outlined above. >>=20 >> Increase the sa(4) driver read/write timeout from 4 to 32 >> minutes. This is based on the recommended values for IBM LTO >> 5/6 drives. This may also avoid timeouts for other tape >> hardware that can take a long time to do retries and error >> recovery. Longer term, a better way to handle this is to ask >> the drive for recommended timeout values using the REPORT >> SUPPORTED OPCODES command. Modern IBM and Oracle tape drives >> at least support that command, and it would allow for more >> accurate timeout values. >>=20 >> Add XML status generation. This is done with a series of >> macros to eliminate as much duplicate code as possible. The >> new XML-based status values are reported through the new >> MTIOCEXTGET ioctl. >>=20 >> Add XML driver parameter reporting, using the new MTIOCPARAMGET >> ioctl. >>=20 >> Add a new driver parameter setting interface, using the new >> MTIOCPARAMSET and MTIOCSETLIST ioctls. >>=20 >> Add a new MTIOCRBLIM ioctl to get block limits information. >>=20 >> Add CCB/CDB building routines scsi_locate_16, scsi_locate_10, >> and scsi_read_position_10(). >>=20 >> scsi_locate_10 implements the LOCATE command, as does the >> existing scsi_set_position() command. It just supports >> additional arguments and features. If/when we figure out a >> good way to provide backward compatibility for older >> applications using the old function API, we can just revamp >> scsi_set_position(). The same goes for >> scsi_read_position_10() and the existing scsi_read_position() >> function. >>=20 >> Revamp sasetpos() to take the new mtlocate structure as an >> argument. It now will use either scsi_locate_10() or >> scsi_locate_16(), depending upon the arguments the user >> supplies. As before, once we change position we don't have a >> clear idea of what the current logical position of the tape >> drive is. >>=20 >> For tape drives that support long form position data, we >> read the current position and store that for later reporting >> after changing the position. This should help applications >> like Bacula speed tape access under FreeBSD once they are >> modified to support the new ioctls. >>=20 >> Add a new quirk, SA_QUIRK_NO_LONG_POS, that is set for all >> drives that report SCSI-2 or older, as well as drives that >> report an Illegal Request type error for READ POSITION with >> the long format. So we should automatically detect drives >> that don't support the long form and stop asking for it after >> an initial try. >>=20 >> Add a partition number to the sa(4) softc. >>=20 >> Improve device departure handling. The previous implementation >> led to hangs when the device was open. >>=20 >> If an application had the sa(4) driver open, and attempted to >> close it after it went away, the cam_periph_release() call in >> saclose() would cause the periph to get destroyed because that >> was the last reference to it. Because destroy_dev() was >> called from the sa(4) driver's cleanup routine (sacleanup()), >> and would block waiting for the close to happen, a deadlock >> would result. >>=20 >> So instead of calling destroy_dev() from the cleanup routine, >> call destroy_dev_sched_cb() from saoninvalidate() and wait for >> the callback. >>=20 >> Acquire a reference for devfs in saregister(), and release it >> in the new sadevgonecb() routine when all devfs devices for=09 >> the particular sa(4) driver instance are gone. >>=20 >> Add a new function, sasetupdev(), to centralize setting >> per-instance devfs device parameters instead of repeating the >> code in saregister(). >>=20 >> Add an open count to the softc, so we know how many >> peripheral driver references are a result of open >> sessions. >>=20 >> Add the D_TRACKCLOSE flag to the cdevsw flags so >> that we get a 1:1 mapping of open to close calls >> instead of a N:1 mapping. >>=20 >> This should be a no-op for everything except the >> control device, since we don't allow more than one >> open on non-control devices. >>=20 >> However, since we do allow multiple opens on the >> control device, the combination of the open count >> and the D_TRACKCLOSE flag should result in an >> accurate peripheral driver reference count, and an >> accurate open count. >>=20 >> The accurate open count allows us to release all >> peripheral driver references that are the result >> of open contexts once we get the callback from devfs. >>=20 >> sys/sys/mtio.h: >> Add a number of new mt(4) ioctls and the requisite data >> structures. None of the existing interfaces been removed >> or changed. >>=20 >> This includes definitions for the following new ioctls: >>=20 >> MTIOCRBLIM /* get block limits */ >> MTIOCEXTLOCATE /* seek to position */ >> MTIOCEXTGET /* get tape status */ >> MTIOCPARAMGET /* get tape params */ >> MTIOCPARAMSET /* set tape params */ >> MTIOCSETLIST /* set N params */ >>=20 >> usr.bin/mt/Makefile: >> mt(1) now depends on libmt, libsbuf and libbsdxml. >>=20 >> usr.bin/mt/mt.1: >> Document new mt(1) features and subcommands. >>=20 >> usr.bin/mt/mt.c: >> Implement support for mt(1) subcommands that need to >> use getopt(3) for their arguments. >>=20 >> Implement a new 'mt status' command to replace the old >> 'mt status' command. The old status command has been >> renamed 'ostatus'. >>=20 >> The new status function uses the MTIOCEXTGET ioctl, and >> therefore parses the XML data to determine drive status. >> The -x argument to 'mt status' allows the user to dump out >> the raw XML reported by the kernel. >>=20 >> The new status display is mostly the same as the old status >> display, except that it doesn't print the redundant density >> mode information, and it does print the current partition >> number and position flags. >>=20 >> Add a new command, 'mt locate', that will supersede the >> old 'mt setspos' and 'mt sethpos' commands. 'mt locate' >> implements all of the functionality of the MTIOCEXTLOCATE >> ioctl, and allows the user to change the logical position >> of the tape drive in a number of ways. (Partition, >> block number, file number, set mark number, end of data.) >> The immediate bit and the explicit address bits are >> implemented, but not documented in the man page. >>=20 >> Add a new 'mt weofi' command to use the new MTWEOFI ioctl. >> This allows the user to ask the drive to write a filemark >> without waiting around for the operation to complete. >>=20 >> Add a new 'mt getdensity' command that gets the XML-based >> tape drive density report from the sa(4) driver and displays >> it. This uses the SCSI REPORT DENSITY SUPPORT command >> to get comprehensive information from the tape drive about >> what formats it is able to read and write. >>=20 >> Add a new 'mt protect' command that allows getting and setting >> tape drive protection information. The protection information >> is a CRC tacked on to the end of every read/write from and to >> the tape drive. >>=20 >> Sponsored by: Spectra Logic >> MFC after: 1 month >>=20 >> Thanks, >>=20 >> Ken >> --=20 >> Kenneth Merry >> ken@FreeBSD.ORG >=20 > --=20 > Kenneth Merry > ken@FreeBSD.ORG > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to = "freebsd-scsi-unsubscribe@freebsd.org" =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 17:10:06 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC4FEA38; Sat, 28 Feb 2015 17:10:06 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A383CE8C; Sat, 28 Feb 2015 17:10:05 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id A7E4FA0 ; Sat, 28 Feb 2015 17:10:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> Date: Sat, 28 Feb 2015 12:10:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF4E4B7-3B9C-42CF-A2D1-F7BD5974D603@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 17:10:06 -0000 > On Feb 28, 2015, at 11:48 AM, Dan Langille wrote: >=20 >=20 >> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry = wrote: >>=20 >>=20 >> I have updated the patches. >>=20 >> I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since >> I committed those separately. >>=20 >> I have (hopefully) fixed the build for the stable/10 patches by = MFCing >> dependencies. (One of them mav did for me, thanks!) >>=20 >> Rough draft commit message: >>=20 >> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >>=20 >> The patches against FreeBSD/head as of SVN revision 278975: >>=20 >> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt >>=20 >> And (untested) patches against FreeBSD stable/10 as of SVN revision = 278974: >>=20 >> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt >=20 > Not sure what I've done wrong here. >=20 > I've applied your patches and run make buildworld against: It appears 'patch -p0' is my friend... It's been a long time.. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 17:33:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A01DF67 for ; Sat, 28 Feb 2015 17:33:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1755C174 for ; Sat, 28 Feb 2015 17:33:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 030F1996 for ; Sat, 28 Feb 2015 17:33:26 +0000 (UTC) Date: Sat, 28 Feb 2015 17:33:26 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <936787470.46.1425144806964.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <685493215.45.1425134319755.JavaMail.jenkins@jenkins-9.freebsd.org> References: <685493215.45.1425134319755.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #785 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 17:33:27 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 20:35:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBA1265C for ; Sat, 28 Feb 2015 20:35:24 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D905A60E for ; Sat, 28 Feb 2015 20:35:24 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F39C59DF for ; Sat, 28 Feb 2015 20:35:24 +0000 (UTC) Date: Sat, 28 Feb 2015 20:35:24 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2013185165.47.1425155724931.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <936787470.46.1425144806964.JavaMail.jenkins@jenkins-9.freebsd.org> References: <936787470.46.1425144806964.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #786 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 20:35:25 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 21:25:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B4C0363 for ; Sat, 28 Feb 2015 21:25:40 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9079AB9 for ; Sat, 28 Feb 2015 21:25:39 +0000 (UTC) Received: by igdh15 with SMTP id h15so8689157igd.4 for ; Sat, 28 Feb 2015 13:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0qE1rWiKGEEtvYZyR3uMbLjye5Lr4UB5FktQnUucRoA=; b=Oy8cdPvXrJSBX/3HUgULAjQJEtxbX+ll1VNfxOomAaDG9Iw8AWqFt28RtAKLsnlL74 qgYwtY+Et0lWQU1dlCn/JUBixwHN64O/ecAtlSBslZ37JyDq3JMW+VLC6EdJt3Sk7TrJ wjwvEaqfZzpQZUNiB3yCS71QLxzIsMQ07CPUDyWWymqCrErxQIm8EFl/1YfiYJgYzmDT 3Hl5i5JIrL55x4qnnsGwiIBpHkDu+74b+2Eyx3i3biHzBz9sfl6neF6Mr2ulUYXzFa+a bBfrT3rV8Chy1/k7eVwN1Ev8dhsUC/osIZ3m9W7nQeF/742mE4lSW3vZpLKVZy0JKa7X G9IA== MIME-Version: 1.0 X-Received: by 10.42.150.130 with SMTP id a2mr23017156icw.69.1425158739378; Sat, 28 Feb 2015 13:25:39 -0800 (PST) Received: by 10.107.156.75 with HTTP; Sat, 28 Feb 2015 13:25:39 -0800 (PST) Date: Sat, 28 Feb 2015 16:25:39 -0500 Message-ID: Subject: atkbd.c not compiling? From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 21:25:40 -0000 I updated my source tree this morning and now I'm seeing this compile error in "make tinderbox"; /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of undecla red identifier 'key_map'; did you mean 'keymap'? keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); ^~~~~~~ keymap /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' declar ed here keymap_t *keymap; /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of undecla red identifier 'accent_map'; did you mean 'accentmap_t'? accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); ^ /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' declared here typedef struct accentmap accentmap_t; (By the way, this is the second time in two days that "make tinderbox" has been broken for me. It's extremely frustrating that I can't test my pending commits because others haven't done me the same courtesy) From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 21:42:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E8A16F0 for ; Sat, 28 Feb 2015 21:42:44 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55E03CA6 for ; Sat, 28 Feb 2015 21:42:44 +0000 (UTC) Received: by igkb16 with SMTP id b16so8741173igk.1 for ; Sat, 28 Feb 2015 13:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KxjZ8H/ZBwUPJvNksB+zhgWgYcV0So+aJagTVxK0B8w=; b=ab6bcmWey1/1D9t3qaP0JDrNBRacxJRQHtwQzf56qcxVonA1acjZcqgkFha7OnxZ5Z 4OH4QBSChilBeYANrPPxbKP9RVqp26rHjiUd987UiRul4/DKvIvW6r5AHw32O2xqQhDe 7kVrdVomVRUbUQIuODws7j6j32sTk87oTlGxZVIep7C46ZJTkqijH66zV1e6uA6jbGKc q8jyFbF9ChLPCayZPADLA2R0acegCLYN5Dyf/IbkGQy2/rdPpEaxh8LJjFYu0gCXxK35 OHd7WevNRoiVaj+2AddddQ2/bMYl78XNxE/TZgXDYarmv8iAYHIkEH1IoGZ0zIePKHlr KXZw== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr13031856igb.39.1425159763794; Sat, 28 Feb 2015 13:42:43 -0800 (PST) Received: by 10.107.156.75 with HTTP; Sat, 28 Feb 2015 13:42:43 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2015 16:42:43 -0500 Message-ID: Subject: Re: atkbd.c not compiling? From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 21:42:44 -0000 And now this: /repos/users/rstone/freebsd-2/sys/modules/sfxge/../../dev/sfxge/sfxge_rx.h:39:2: error: LRO #error LRO Seriously? From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 21:51:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F16AD4A for ; Sat, 28 Feb 2015 21:51:02 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA277CED for ; Sat, 28 Feb 2015 21:51:01 +0000 (UTC) Received: by padbj1 with SMTP id bj1so6510237pad.11 for ; Sat, 28 Feb 2015 13:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=D4iiW5rbptvVK4STks0APAL2ORg19ZB6aoGC+OvV/No=; b=RXNythT4MX8m4JRQ2/OB+0rN/li/7jzx+IuPc23VINLA7ca9TmKXNHdOCqtfKz6RpU q27PV52JgcHB8EDcrz8nMOI5oqkocIKThzDDDMwMC21Sw04yKH29kREXhqs5gPsRl7xp sDaSX+VlH3D7hFJ3Wrv2oDPL7m4NIdeL6T3G7eO+YB27MfVqxl3WjgoEygqyZ7fL/r3o usWXD+Pkp3Fvsln+7LakoEbBPL/4XQJgEcudtsv6Xb04+6qvB835vVyphIrYbbUGBwdJ XzpHJZUVQgFCkU5lVrzhh1ECBdeHNv5rh3u6AOjaUOk2t7y7tsue/8aZ+IvWaRfNmrIN NjPg== X-Received: by 10.68.137.229 with SMTP id ql5mr35265871pbb.134.1425160261357; Sat, 28 Feb 2015 13:51:01 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:70f4:34b0:7fef:39da? ([2601:8:ab80:7d6:70f4:34b0:7fef:39da]) by mx.google.com with ESMTPSA id y12sm7675845pdk.46.2015.02.28.13.51.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Feb 2015 13:51:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B44DBA25-8070-4D2A-B3FD-75E2800670B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: atkbd.c not compiling? From: Garrett Cooper In-Reply-To: Date: Sat, 28 Feb 2015 13:51:00 -0800 Message-Id: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> References: To: Ryan Stone X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 21:51:02 -0000 --Apple-Mail=_B44DBA25-8070-4D2A-B3FD-75E2800670B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 28, 2015, at 13:25, Ryan Stone wrote: > I updated my source tree this morning and now I'm seeing this compile > error in "make tinderbox"; >=20 > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use = of undecla > red identifier 'key_map'; did you mean 'keymap'? > keymap =3D malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); > ^~~~~~~ > keymap > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: = 'keymap' declar > ed here > keymap_t *keymap; > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use = of undecla > red identifier 'accent_map'; did you mean 'accentmap_t'? > accmap =3D malloc(sizeof(accent_map), M_DEVBUF, = M_NOWAIT); > ^ > /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' = declared > here > typedef struct accentmap accentmap_t; >=20 >=20 >=20 > (By the way, this is the second time in two days that "make tinderbox" > has been broken for me. It's extremely frustrating that I can't test > my pending commits because others haven't done me the same courtesy) I=92m not sure about key_map =97 are you building with syscons or vt? --Apple-Mail=_B44DBA25-8070-4D2A-B3FD-75E2800670B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8jhEAAoJEMZr5QU6S73e8coIAJgpVrr9P36T7xHERjWHByMB bq/mgl0aLXfX+yCeBQubKm1QmSBxQfCoDzyFn/8QPOR/S3NFb0ILzVwRgLzLRdLD o0n7oYrKXZobnKRZSkPW6IxCoJ1pHZYeoc6CE3QwQujziKVI/q5iiFQV4MEMa8LD Ij7wHeeYwSiad2AIyH7YZ8oAiwKhOHI7NLamMiNcQX9uPKbjQU6zMoBWMhw0hQd4 TDD5c9hbYOQbZDe05guUKUQ4yGMeDAnAHH5ITteWMZ8KwNB3MQ4/yv7UdJSvdUuJ T2yqahCr1tLbAm1PTgj3eMiLRvkTXBDBXnHNl+nrgcPHSV2D02KRgFJ1LHhven0= =tE+V -----END PGP SIGNATURE----- --Apple-Mail=_B44DBA25-8070-4D2A-B3FD-75E2800670B1-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 21:56:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E33BAE76 for ; Sat, 28 Feb 2015 21:56:37 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8426DA2 for ; Sat, 28 Feb 2015 21:56:37 +0000 (UTC) Received: by igjz20 with SMTP id z20so8760296igj.4 for ; Sat, 28 Feb 2015 13:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nRXlm53gQDpwiR13DcHwaOcVCjY7bP5hgxUQ4h4oNx0=; b=olQf1njamZi7d+HYvj+iAQkbmnPfOvD7bggOZwn1xwPDV/hAZNg70dT79nbrnYJcZT 2ngpP08CIdh/P9naQFyjvNu8/lGMQrRx5nEZSDMl8TU86vKsUuLBVr23JzIrPq1RbYhO 5VQsQUeV5ewBAuX0PUYifWuUEAAb9qN4gNgsFzCkNaUYGsKH33ghx4Q9erO81yaWxLXg ouaW2IFqKiFq8vgOUils2J/Zv7CPUvE2x1e32gxRquk9Bn3ralwa/CgFghvBqojqrF9K fh5LNMoRTq4dTjvCEhyRDQGJUX6Gv6BszDmyYYDPEPy4JMPPUXSwCK8Kt9fcBj+QBLP6 odLg== MIME-Version: 1.0 X-Received: by 10.50.111.202 with SMTP id ik10mr12957195igb.37.1425160597093; Sat, 28 Feb 2015 13:56:37 -0800 (PST) Received: by 10.107.156.75 with HTTP; Sat, 28 Feb 2015 13:56:37 -0800 (PST) In-Reply-To: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> References: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> Date: Sat, 28 Feb 2015 16:56:37 -0500 Message-ID: Subject: Re: atkbd.c not compiling? From: Ryan Stone To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 21:56:38 -0000 On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper wro= te: > I=E2=80=99m not sure about key_map =E2=80=94 are you building with syscon= s or vt? I have no idea. I'm just running make tinderbox. So far _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed, among others. i386.LINT and sparc64.LINK have both "device sc" and "device vt" from what I can see From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:12:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C28121F1 for ; Sat, 28 Feb 2015 22:12:02 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85D23F23 for ; Sat, 28 Feb 2015 22:12:02 +0000 (UTC) Received: by pdno5 with SMTP id o5so29566611pdn.8 for ; Sat, 28 Feb 2015 14:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YAMb7SJFuksLuqe+Oa/d8JkNWKXzgLgEGLmItg0nF5I=; b=hwZL1xY8L/grF7Z4RXWtU2YW+tB/4scbVwGDpKKSpyTnpQbqM8ZzYFPH1mkGJQ7eaK EQIkQQWCIc2jnQKvqMHDNfoZl4suk84PYWddCLPfBGIWw4C2BNJl/4DMnD4nJI3lr9hX w+34mnjz3iLWSngqzOMWlG6qo7ul//phzpj3JlSf3roT0TLkNDxrT/dAL9x4m3kgbRVE dp5v/+uN8a40eHThwjEtxfEqs8Qevdi9CmyJ5chISoq94RF8U69cJUrNf3sqnkhImdYa FdDwNq/C7+L8AbP9ups8h8lF/VJDhVukYfKl67d/3O6KZ51vDRY5Td3verFQ/OWVEQ36 XQ3w== X-Received: by 10.70.21.195 with SMTP id x3mr34843860pde.73.1425161522065; Sat, 28 Feb 2015 14:12:02 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id uy8sm7698229pbc.31.2015.02.28.14.12.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Feb 2015 14:12:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_0ABB79D0-C00C-488F-B0F0-EDBDA196AECD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: atkbd.c not compiling? From: Garrett Cooper In-Reply-To: Date: Sat, 28 Feb 2015 14:12:00 -0800 Message-Id: References: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> To: Ryan Stone X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:12:02 -0000 --Apple-Mail=_0ABB79D0-C00C-488F-B0F0-EDBDA196AECD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 28, 2015, at 13:56, Ryan Stone wrote: > On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper = wrote: >> I=92m not sure about key_map =97 are you building with syscons or vt? >=20 > I have no idea. I'm just running make tinderbox. So far > _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed, > among others. >=20 > i386.LINT and sparc64.LINK have both "device sc" and "device vt" from > what I can see It looks like a few keyboard drivers would be broken. Might be related = to [AT]KBD_DFLT_KEYMAP... =46rom sys/dev/kbd/kbdtables.h : 31 #ifndef KBD_DFLT_KEYMAP 32=20 33 /* US iso8859 */ 34 #define ISO_ACCENTCHARS 35 /* 36 * Automatically generated from = /usr/share/syscons/keymaps/us.iso.kbd. 37 * DO NOT EDIT! 38 */ 39 static keymap_t key_map =3D { 0x6d, { =46rom sys/dev/atkbd/atkbd.c: 265 /* the initial key map, accent map and fkey strings */ 266 #ifdef ATKBD_DFLT_KEYMAP 267 #define KBD_DFLT_KEYMAP 268 #include "atkbdmap.h" 269 #endif 270 #include --Apple-Mail=_0ABB79D0-C00C-488F-B0F0-EDBDA196AECD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8j0wAAoJEMZr5QU6S73eJkIH/347olYtQYJYheayN2J+4IL5 N3zMx+/i0YEScMHXXuEZHBnRqFpvmmB5qnpvP4O0foWfPaTg1sYoMXdGOilbRqp3 Qn+Mtm1xhO62aC+DwUPjxuP1KkHbG9ZohNi79hehKZfxfkyz8TYqckSWV565LVYx SbqIeUZbBQl5he+xhGGnx8VH6QGWk7ALuHOAEjaDp/IvIvA4z5DyVYNrIxRnmFvj FMy0FLi+t/GtW+efZ3iWHvtmUYbL/3IuNfia8iE1/LgnTrxiy87P0AieEeleHCU/ s4gxH6X4xIbBe8JO4NhkVBFi/OZoXEdUIMwZF8R1AU0xAqdyfA0P0J4M7AqKE1Q= =RmK+ -----END PGP SIGNATURE----- --Apple-Mail=_0ABB79D0-C00C-488F-B0F0-EDBDA196AECD-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:15:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 008353BF for ; Sat, 28 Feb 2015 22:15:22 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7CDEF4B for ; Sat, 28 Feb 2015 22:15:22 +0000 (UTC) Received: by paceu11 with SMTP id eu11so32285094pac.7 for ; Sat, 28 Feb 2015 14:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TcT9HglDYGBDeUqFZxc+suxPeDd3NLpM+6/uMtZjUGo=; b=S6xW4J2CakzTDyCGCnBspVX9Aou7NhWEeWY89lwTfx4WFXDWTMoS7k8f37ksy4+Z+v 52N68fjtoPeKc5mvpjT4Op04Q/y9KneHNArLTIPRDMW+0ZFBpn/F8/I5Ediwjc/CWl1I 0clZV9CWqh71gLM4Vc2VeDeX0UPpJQM+u/5EeIyveqmAiY4hjvYDJBmeKfYaJ3VSdrqm dt80o+3LpnYXS/cBhyCEsxiq8IjG3S/0F2POFu9JxizzsAE2aX8II/rL0cf4g/ulSc27 9R6DrrsjmyS25L+p6gMGSHeFTpXw+gUwb3B+ATlFUju1BlrkknBZi+D/y1z6joXAlZWT rMRQ== X-Received: by 10.70.51.131 with SMTP id k3mr34424945pdo.155.1425161722265; Sat, 28 Feb 2015 14:15:22 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id v5sm7762113pdh.9.2015.02.28.14.15.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Feb 2015 14:15:21 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_915EEC58-63DC-4BAB-A8E4-6D5BD7C4DB70"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: atkbd.c not compiling? From: Garrett Cooper In-Reply-To: Date: Sat, 28 Feb 2015 14:15:21 -0800 Message-Id: <7455B5E3-EAE6-4D5D-B0DA-373F2D75397B@gmail.com> References: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> To: Ryan Stone X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:15:23 -0000 --Apple-Mail=_915EEC58-63DC-4BAB-A8E4-6D5BD7C4DB70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 28, 2015, at 13:56, Ryan Stone wrote: > On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper = wrote: >> I=92m not sure about key_map =97 are you building with syscons or vt? >=20 > I have no idea. I'm just running make tinderbox. So far > _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed, > among others. >=20 > i386.LINT and sparc64.LINK have both "device sc" and "device vt" from > what I can see I think I figured it out. Is it because MK_VT !=3D =93no=94 and = MK_LEGACY_CONSOLE =3D=3D =93no=94? --Apple-Mail=_915EEC58-63DC-4BAB-A8E4-6D5BD7C4DB70 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8j35AAoJEMZr5QU6S73eifIIAI+mUKjwWDImh7BGG3zUP2AT Iq6CfQJsN/X3wmdiqyz5lB0+6PHWg8Y2FMUbeOEh/r9zdj8mXY+T8Ian5jTfx+tE qAkCpmiYzcw3bWQZqes4qQZBf/pcPZBQQU6H2NpI2AkS/aGBVY5XjczU2HGd7Upn 0L8kCyvEHKjEtUPEgmE+WiCeJWvF1hd4HMR4Du4NAOuL/jo7phgGOVcjupR4OYKJ t0Dc+WgUh3pHpvH44HBIJeyad3BdcFcpJyr49NAwo0+sw1CH+I5BUzy6ZZ7l4ttT EjmGZMfpQXfgVkIpR5xgtgqpAlPJdbxiMhjBTauQKGrZv6v6gUhwZhBKCutT84Y= =dRPo -----END PGP SIGNATURE----- --Apple-Mail=_915EEC58-63DC-4BAB-A8E4-6D5BD7C4DB70-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:19:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 048A7539 for ; Sat, 28 Feb 2015 22:19:31 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC284F89 for ; Sat, 28 Feb 2015 22:19:30 +0000 (UTC) Received: by padbj1 with SMTP id bj1so32325852pad.5 for ; Sat, 28 Feb 2015 14:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MMstVi8w+F2Qdg+nWxl4DmbuxhnkYSb2Mx+QF7tGqrs=; b=DQHFzPlYmVOSVCsugBMvZFGlFMmTZZxrTTvqu4cpov4qhX4JcMzJbSMnioW7VLgfpi pWe6VJAoIIyGK8LgiBtiwGqBf9SV7U6Tx5EqdkRKDIouBcxJRLEfIHx1tlNZmooRf0EE V+qqVwPcCHcqJrvLBRNTTwEVoq5kl4pv3cbhuN45lTm0SAHPyX6DDBZna1KkyRQ0bAg9 L0er8IoT9MiCPnmmMoE7foq288sp37R6mFk+L5bfUIV7JBSvLIjxnOIlDQdaZfby4ItH 8lqQwOI6wEYpUhbY9baw96f1xs4Wc7ntsu9UfRjkZ2rOoNbqcd4srFlFomzchtcmUqR4 +qXA== X-Received: by 10.69.19.129 with SMTP id gu1mr34816698pbd.50.1425161970288; Sat, 28 Feb 2015 14:19:30 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id r7sm7632071pdo.90.2015.02.28.14.19.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Feb 2015 14:19:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_F15EF1EB-B46F-4E0C-91BC-9292E80694C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: atkbd.c not compiling? From: Garrett Cooper In-Reply-To: <7455B5E3-EAE6-4D5D-B0DA-373F2D75397B@gmail.com> Date: Sat, 28 Feb 2015 14:19:29 -0800 Message-Id: <372ECBB0-2491-4995-8A9C-65ECF7E675AD@gmail.com> References: <2C7266F4-70C0-4AAE-876D-A03FA2E91FE4@gmail.com> <7455B5E3-EAE6-4D5D-B0DA-373F2D75397B@gmail.com> To: Ryan Stone X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:19:31 -0000 --Apple-Mail=_F15EF1EB-B46F-4E0C-91BC-9292E80694C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 28, 2015, at 14:15, Garrett Cooper wrote: > On Feb 28, 2015, at 13:56, Ryan Stone wrote: >=20 >> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper = wrote: >>> I=92m not sure about key_map =97 are you building with syscons or = vt? >>=20 >> I have no idea. I'm just running make tinderbox. So far >> _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have = failed, >> among others. >>=20 >> i386.LINT and sparc64.LINK have both "device sc" and "device vt" from >> what I can see >=20 > I think I figured it out. Is it because MK_VT !=3D =93no=94 and = MK_LEGACY_CONSOLE =3D=3D =93no=94? =85 or because MK_SYSCONS =3D=3D no? --Apple-Mail=_F15EF1EB-B46F-4E0C-91BC-9292E80694C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8j7xAAoJEMZr5QU6S73eKqIIAJL7eznwPuNYa3x40OopA4pC 09OSbG5ozEd9bZ9CrA+suLlJuo9KLQY9a0kvhaRljvcZhRJJijQLUe50Y4ZHdNes sR3MB6uNfFNzCT9/FgNlusHTXqTKwFWuss0V9XUUJgGf873QLu1mOS+gyhd4XqRJ KH/Vkq9L1waYpjLYblgrd1UHrP09jLczbyf/ihoFDWopEKC29n4kS+LwWAEXQzjS 0kKmKkPc++QXJTSp+1GcOF4wiUFpgeTArvHqFcHiIIiLUkQUHuC/Ls8mvUF3XEZf TWLazQaWUdCrgLq2zndwrjayP5G4aHIrMdR8eWqyoXrKgDWB1wFkj1lW4eDnjPI= =iCiM -----END PGP SIGNATURE----- --Apple-Mail=_F15EF1EB-B46F-4E0C-91BC-9292E80694C7-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:29:52 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F33AA8B4; Sat, 28 Feb 2015 22:29:51 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAF48FC; Sat, 28 Feb 2015 22:29:51 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 78C505D1 ; Sat, 28 Feb 2015 22:29:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> Date: Sat, 28 Feb 2015 17:29:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:29:52 -0000 > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >=20 >=20 > I have updated the patches. >=20 > I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since > I committed those separately. >=20 > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) >=20 > Rough draft commit message: >=20 > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt I have current installed and running with Bacula, but I have not tried = the tape drive yet. It seems like your changes are in there from about 5 days ago. Having solved my server hardware issues, I'm now having issues with the = autochanger mechanism=20 of the tape library. =20 =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:31:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABE419FB for ; Sat, 28 Feb 2015 22:31:19 +0000 (UTC) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F3CB1AD for ; Sat, 28 Feb 2015 22:31:18 +0000 (UTC) Received: by ykq19 with SMTP id 19so10275624ykq.4 for ; Sat, 28 Feb 2015 14:31:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lMn4zVX81Otkdjlh1sGbZSo64KfsQpyef+zOO8FadnU=; b=X5B8mwXg838UtlF5wFkMDf9bCqiv2jfdSHs8Yv9YFZuCzPm8WFBO1ODRx280nqDa6u GBfbnoULFeMEhbxVYGtGq67vgGKIoUXw5ZXBPeA/+zo6CyB6JBmPuRQwNOhglvWNtCVJ EaQI/XUIWWEULU3WZAYLuLSFmFrhJK2H4wzcytjFDDxLaxzVrzoG2VbAK6s730kH8RyT 3QKk9zqfRMnTo18B1HOrIafshJXmn6i7wyWaWYfINza2k5zHLcA5bkjAJAStTzN83+/C l1w8yY3AtAvpTFq1nwWBKwmw+EbtHththEa6/TchuVcJpSjJExA/SLOy6OIgU2qst2I0 k4kw== X-Gm-Message-State: ALoCoQndAg3fVv4y6q2CQoPZCWKfFSfe6xmGY9yVdRpsKt3WgRA5dfE4Y//rx8duiDNvkV5hkwKG MIME-Version: 1.0 X-Received: by 10.236.203.193 with SMTP id f41mr19202007yho.191.1425158968232; Sat, 28 Feb 2015 13:29:28 -0800 (PST) Received: by 10.170.56.134 with HTTP; Sat, 28 Feb 2015 13:29:28 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2015 22:29:28 +0100 Message-ID: Subject: Re: atkbd.c not compiling? From: Oliver Pinter To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:31:19 -0000 On Sat, Feb 28, 2015 at 10:25 PM, Ryan Stone wrote: > I updated my source tree this morning and now I'm seeing this compile > error in "make tinderbox"; > > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of undecla > red identifier 'key_map'; did you mean 'keymap'? > keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); > ^~~~~~~ > keymap > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' declar > ed here > keymap_t *keymap; > /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of undecla > red identifier 'accent_map'; did you mean 'accentmap_t'? > accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); > ^ > /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' declared > here > typedef struct accentmap accentmap_t; > Hi! See these PRs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193817 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 > > > (By the way, this is the second time in two days that "make tinderbox" > has been broken for me. It's extremely frustrating that I can't test > my pending commits because others haven't done me the same courtesy) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 22:49:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CD9AEDE; Sat, 28 Feb 2015 22:49:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBA92E9; Sat, 28 Feb 2015 22:49:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A023EA12; Sat, 28 Feb 2015 22:49:59 +0000 (UTC) Date: Sat, 28 Feb 2015 22:49:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, loos@FreeBSD.org, arybchik@FreeBSD.org, alc@FreeBSD.org, kib@FreeBSD.org, kan@FreeBSD.org Message-ID: <1887508547.48.1425163799584.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2472 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 22:49:59 -0000 See Changes: [loos] Add ofw_gpiobus_parse_gpios(), a new public function, to parse the g= pios property for devices that doesn't descend directly from gpiobus. The parser supports multiple pins, different GPIO controllers and can use arbitrary names for the property (to match the many linux variants: cd-gpios, power-gpios, wp-gpios, etc.). Pass the driver name on ofw_gpiobus_add_fdt_child(). Update gpioled to match. An usage example of ofw_gpiobus_parse_gpios() will follow soon. [kib] Supposed fix for some SandyBridge mobile CPUs hang on AP startup when x2APIC mode is detected and enabled. Current theory is that switching the APIC mode while an IPI is in flight might be the issue. Postpone switching to x2APIC mode until we are guaranteed that all starting IPIs are already send and aknowledged. Use aps_ready signal as an indication that the BSP is done with us. Tested by:=09adrian Sponsored by:=09The FreeBSD Foundation MFC after:=092 months [kan] Avoid closing unallocated socket in case socreate fails. Found by: Brainy Code Scanner Reported by: Maxime Villard MFC after: 2 weeks [kan] Avoid lookup of CODESET aliases using uninitialized path We do not use iconv.alias file, so avoid using the vestiges of the code that do. Differential Revision:=09https://reviews.freebsd.org/D1729 Reviewed by: emaste MFC after: 2 weeks [loos] Rename and move gpiobus_alloc_ivars() and gpiobus_free_ivars() so th= ey can be used on non FDT systems. This prevents access to uninitialized memory on drivers that try to access pin flags on non FDT systems. [kib] Some fixes for fdescfs lookup code. Do not ever return doomed vnode from lookup. This could happen, if not checked, since dvp is relocked in the 'looking up ourselves' case. In the other case, since dvp is relocked, mount point might go away while fdesc_allocvp() is called. Prevent the situation by doing vfs_busy() before unlocking dvp. Reuse the vn_vget_ino_gen() helper. Reported and tested by:=09pho Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks [alc] Eliminate a variable that became unused when VFS_LOCK_GIANT() was eliminated. MFC after:=093 days [loos] Add a driver for the Maxim DS3231 a low-cost, extremely accurate (+-= 2PPM) I2C real-time clock (RTC). The DS3231 has an integrated temperature-compensated crystal oscillator (TXCO) and crystal. DS3231 has a temperature sensor, an independent 32kHz output (which can be turned on and off by the driver) and another output that can be used as interrupt for alarms or as a second square-wave output, which frequency and operation mode can be set by driver sysctl(8) knobs. Differential Revision:=09https://reviews.freebsd.org/D1016 Reviewed by:=09ian, rpaulo Tested on:=09Raspberry pi model B [arybchik] sfxge: compile out LRO if kernel is compiled without IPv4 and IP= v6 Sponsored by: Solarflare Communications, Inc. Approved by: gnn (mentor) ------------------------------------------ [...truncated 258685 lines...] CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_sfxge --- In file included from :40: In file included from :87: :39:2: error: LRO #error LRO ^ --- depend_subdir_si --- --- device_if.h --- awk -f -h --- depend_subdir_sfxge --- 1 error generated. --- depend_subdir_si --- --- isa_if.h --- awk -f -= h --- pci_if.h --- awk -f -h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_netgraph --- =3D=3D=3D> netgraph/vlan (depend) --- depend_subdir_sfxge --- In file included from :54: In file included from :87: :39:2: error: LRO #error LRO ^ 1 error generated. --- depend_subdir_netgraph --- --- --- --- depend_subdir_sfxge --- In file included from :67: In file included from :87: :39:2: error: LRO #error LRO ^ --- depend_subdir_netgraph --- machine -> --- depend_subdir_sfxge --- 1 error generated. --- depend_subdir_netgraph --- --- --= - x86 -> --- opt_netgraph.h --- ln -sf opt_netgraph.h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_siba_bwn --- =3D=3D=3D> siba_bwn (depend) --- depend_subdir_siftr --- =3D=3D=3D> siftr (depend) --- depend_subdir_siba_bwn --- --- --- machine -> --- --- x86 -> --- device_if.h --- awk -f -h --- bus_if.h --- awk -f = -h --- depend_subdir_siftr --- --- --- machine -> --- --- --- depend_subdir_siba_bwn --- --- pci_if.h --- awk -f -h --- depend_subdir_siftr --- x86 -> --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_siba_bwn --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_siis --- =3D=3D=3D> siis (depend) --- depend_subdir_sis --- =3D=3D=3D> sis (depend) --- depend_subdir_siis --- --- --- machine -> --- --- x86 -> --- opt_cam.h --- ln -sf opt_cam.h --- device_if.h --- awk -f -h --- bus_if.h --- awk -f = -h --- depend_subdir_sis --- --- --- machine -> --- --- x86 -> --- device_if.h --- awk -f -h --- depend_subdir_siis --- --- pci_if.h --- awk -f -h --- depend_subdir_sis --- --- bus_if.h --- awk -f = -h --- depend_subdir_siis --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_sis --- --- pci_if.h --- awk -f -h --- miibus_if.h --- awk -f -h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_sk --- =3D=3D=3D> sk (depend) --- depend_subdir_smbfs --- =3D=3D=3D> smbfs (depend) --- depend_subdir_sk --- --- --- machine -> --- --- x86 -> --- device_if.h --- awk -f -h --- bus_if.h --- awk -f = -h --- depend_subdir_smbfs --- --- --- machine -> --- --- --- depend_subdir_sk --- --- pci_if.h --- awk -f -h --- depend_subdir_smbfs --- x86 -> --- vnode_if_newproto.h --- awk -f -p --- depend_subdir_sk --- --- miibus_if.h --- awk -f -h --- depend_subdir_smbfs --- --- vnode_if_typedef.h --- awk -f -q --- depend_subdir_sk --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_smbfs --- --- opt_inet.h --- ln -sf opt_inet.h --- opt_netsmb.h --- ln -sf opt_netsmb.h --- vnode_if.h --- awk -f -h --- iconv_converter_if.h --- awk -f -h --- .depend --- --- depend_subdir_sn --- --- depend_subdir_smbfs --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 depe= nd_subdir_sn --- =3D=3D=3D> sn (depend) --- depend_subdir_smbfs --- ys/modules/smbfs/../../fs/smbfs/smbfs_io.c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/modules/smbfs/../../cry= pto/des/des_enc.c> --- depend_subdir_sn --- --- --- machine -> --- --- x86 -> --- device_if.h --- awk -f -h --- bus_if.h --- awk -f = -h --- isa_if.h --- awk -f -= h --- card_if.h --- awk -f -h --- pccarddevs.h --- awk -f --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_snp --- =3D=3D=3D> snp (depend) --- --- machine -> --- --- x86 -> --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_K= ERNEL_OPTION_HEADERS -I. -I -I = -I -std=3Diso9899:1999 --- depend_subdir_sfxge --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_sfxge] Error code 2 make[3]: stopped in --- depend_subdir_snp --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_snp] Error code 2 make[3]: stopped in --- depend_subdir_smbfs --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_smbfs] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-depend] Error code 2 make[2]: stopped in --- .depend --- make -V CFILES_ZFS | MKDEP_CPP=3D"cc -E" CC=3D"cc " xargs mkdep -a -f .ne= wdep -DFREEBSD_NAMECACHE -DBUILDING_ZFS -nostdinc -I -I -I -I -I -I -I -O2 -pipe -fno-strict= -aliasing -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-po= inter-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-o= ption -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-emp= ty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-e= rror-pointer-sign -nostdinc -I. -I -I -I -I -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/contrib/ngatm> -I -I -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include= opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmode= l=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-= unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-dec= ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wm= issing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-e= rror-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ= ality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-av= x -std=3Diso9899:1999 -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-un= def -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-d= ecls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-sw= itch -Wno-pointer-arith -Wno-unknown-pragmas -include make -V SFILES_NOZFS | MKDEP_CPP=3D"cc -E" xargs mkdep -a -f .newdep -x a= ssembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -g -Wall -Wredun= dant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensi= ons -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas= -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parenth= eses-equality -Wno-error-unused-function -Wno-error-pointer-sign -nostdinc= -I. -I -I -I -I -I -I -I -I -I -I -I -I= -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-fr= ame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkernel -mno-red-zone -m= no-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestandin= g -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-compare -Wno-= error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-functio= n -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-externs -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -W= undef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagn= ostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -= Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fun= ction -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso9899:1999=20 make -V SFILES_ZFS | MKDEP_CPP=3D"cc -E" xargs mkdep -a -f .newdep -x ass= embler-with-cpp -DLOCORE -DFREEBSD_NAMECACHE -DBUILDING_ZFS -nostdinc -I = -I -I -I -I -I -I -= O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-q= ual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -I -I -I -I -I -I -I -I -I -D_KERNEL -DHAVE_KERNEL_OPT= ION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-f= rame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float= -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector = -gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -= Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prot= otypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffo= rmat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -Wno-unknown-pragmas -Wno-missin= g-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parenthe= ses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused= -Wno-inline -Wno-switch -Wno-pointer-arith -Wno-unknown-pragmas -include <= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/cddl/compat/opensolaris= /sys/debug_compat.h> rm -f .depend mv .newdep .depend 1 error make[2]: stopped in *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 23:15:24 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE1DE91A; Sat, 28 Feb 2015 23:15:24 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AEC2D7DF; Sat, 28 Feb 2015 23:15:24 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t1SNFMA6053061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Feb 2015 16:15:22 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1SNFMYR053060; Sat, 28 Feb 2015 16:15:22 -0700 (MST) (envelope-from ken) Date: Sat, 28 Feb 2015 16:15:22 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150228231521.GA53017@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Sat, 28 Feb 2015 16:15:22 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 23:15:25 -0000 On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: > > > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: > > > > > > I have updated the patches. > > > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > > I committed those separately. > > > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > > dependencies. (One of them mav did for me, thanks!) > > > > Rough draft commit message: > > > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > > I have current installed and running with Bacula, but I have not tried the tape drive yet. > Thanks for all your work on this! > It seems like your changes are in there from about 5 days ago. Yes, that is correct. > Having solved my server hardware issues, I'm now having issues with the autochanger mechanism > of the tape library. Does it work with chio(1)? Does it look like hardware or software? (If it is software, I can help with that.) Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 23:42:42 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FEF472; Sat, 28 Feb 2015 23:42:42 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26688A6A; Sat, 28 Feb 2015 23:42:41 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 5161467F ; Sat, 28 Feb 2015 23:42:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: sa(4) driver changes available for test From: Dan Langille X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150228231521.GA53017@mithlond.kdm.org> Date: Sat, 28 Feb 2015 18:42:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> <20150228231521.GA53017@mithlond.kdm.org> To: "Kenneth D. Merry" Cc: "current@freebsd.org" , "scsi@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Feb 2015 23:42:42 -0000 > On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry wrote: >=20 >> On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: >>=20 >>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >>>=20 >>>=20 >>> I have updated the patches. >>>=20 >>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, sin= ce >>> I committed those separately. >>>=20 >>> I have (hopefully) fixed the build for the stable/10 patches by MFCing >>> dependencies. (One of them mav did for me, thanks!) >>>=20 >>> Rough draft commit message: >>>=20 >>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >>=20 >>=20 >> I have current installed and running with Bacula, but I have not tried th= e tape drive yet. >=20 > Thanks for all your work on this! >=20 >> It seems like your changes are in there from about 5 days ago. >=20 > Yes, that is correct. >=20 >> Having solved my server hardware issues, I'm now having issues with the a= utochanger mechanism=20 >> of the tape library. =20 >=20 > Does it work with chio(1)? >=20 > Does it look like hardware or software? (If it is software, I can help > with that.) >=20 >=20 Hardware. The screw drive for the tape robot is sticky. It can be moved by h= and, but the motor in this DL 891 cannot. It might need lube. It was suspect= last time I used it. Worst case, I will remove ins of the two DLT 8000 tap= e drives and load tapes manually.=20 --=20 Dan Langille http://langille.org/