From owner-freebsd-arm@freebsd.org Mon Sep 10 10:36:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72148108B6D3 for ; Mon, 10 Sep 2018 10:36:51 +0000 (UTC) (envelope-from 4250.10.freebsd-arm=freebsd.org@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2228D7AA4A for ; Mon, 10 Sep 2018 10:36:51 +0000 (UTC) (envelope-from 4250.10.freebsd-arm=freebsd.org@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1536575811; x=1539167811; h=content-transfer-encoding:content-type:mime-version:message-id:subject:to:from:date:x-thread-info; bh=Ky5wrvZyAEboIa/YRtfkZ34B1qVLxxhNRdQbP73LIcA=; b=J1Y4QbZIIFGCCAAU6MGcVIOdvxNDilXlod4ftASxr/enZiPS6XPvHpqzzgCMYF+1YbyvdlReVnzhmtm2UBuuyDC7+aedEn9m0QEzQ9bwMACIavLn2tawIjwnbBkmG5o+pA4rihQvmLgJ7TrEtVumxq+zlDWXvFqXTEicOq2VSyI= X-Thread-Info: NDI1MC4xMi4xOTkwMDAwMDFkZTU2MWIuZnJlZWJzZC1hcm09ZnJlZWJzZC5vcmc= Received: from r5.us-east.aws.in.socketlabs.com (r5.us-east.aws.in.socketlabs.com [52.204.195.176]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Mon, 10 Sep 2018 06:36:46 -0400 Received: from smtp.lan.sohara.org (EMTPY [89.127.62.20]) by r5.us-east.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Mon, 10 Sep 2018 06:36:45 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fzJYj-000Fvl-40 for freebsd-arm@freebsd.org; Mon, 10 Sep 2018 10:36:45 +0000 Date: Mon, 10 Sep 2018 11:36:43 +0100 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Subject: Raspberry Pi avail memory oddly low. Message-Id: <20180910113643.783cdf87f5ca66664cb79613@sohara.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 10:36:51 -0000 Hi, On booting my 256MB Pi I see this in the dmesg output real memory = 234876928 (223 MB) avail memory = 119918592 (114 MB) The avail memory was 114MB before I dropped gpu_mem to 32 and I thought it suspiciously low then, not changing with increased real memory makes me strongly suspect an artificial limit being applied somewhere but I'm not seeing where. -- Steve O'Hara-Smith From owner-freebsd-arm@freebsd.org Tue Sep 11 09:44:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD760108AC31 for ; Tue, 11 Sep 2018 09:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51DB78E9DD for ; Tue, 11 Sep 2018 09:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EvKtiP8VM1n6JCZpfesxwzvsuB2cJf8zopR5p3XQ8ioj6CkJYnutdIZuY4BWhkM c0M.cmgwjHN5uWPxIT96pWwqnCUgg1Ygbm9iJphU7PfhCSqaWazJg_rRf7g2_js2VofOcPvQG1_c a20UgAHFSnasEBOOU.kEI34ViUpKXJ6PXChiz7TyGMpHE3vHu4uO0e4OlejOeYT8w0PF0b5SnSkf Qy8UKavTEQihIF1mMY1yl89df2F1Jzl.Ao5zWZd0uf8CDYEDP.yUibDNyZlhpKi3GcB8tGQYkvDY fgZ088iGDmhK1cH1_tTCAz_.KsbcTOzdnZnO1TTr5EMey7IJ0LSDqjuHq08X7T05QNEplAjAb96u pPg69uPFeS1T26sNiZSVqSZWHYIh2yrX5xuRezpktpOsvcOe62Ig.lGUuqlA5DkCnAGaQOt2pxrz NfDyLxAGg77.YjAqmoKrDWtxjNiUo7GEpnxg46BtN5ElvpIQSwH5hBlTHtmmAqIplD2GXmB2xMq0 M.nRHiZqf1hBwQ50Ch75o34sJbi97FcnnK48BYOoAV.VzAE.ONaRUbiEXOUvet2NRrbz7xubKZbB bF_j4u5r.HTSD2gi8uMArI_KGvXoT1WHL7PMxdf4P4161QMlAo.rlLEW4SF0tczKWAtL1n3m0MJo ONFJzpDe42HMl4vt6U9EhN41ULYX.GRQYiQd41UyEzpQW4NV93vo7l0_c2TktNlUGb96tjiP3tBD x.z52i94YHs.QMmfhhGrhVcsWOVFGeuiuG735OILacviOIus10exC.aaD3ikHN8I3F6m2W_o_Cxn UBjxCTkHvs8tyFj1UYdtgrWA1UfOArtD_ZXWeMcFD1QnZnRVPFYKmEUvCcUhF0PB_FFBF9anseqo a9xNNaHdRy.4A2eQOf9nInaL9w584dU0W5kkm9O8VyHjF9NgtlbmtSim72DCahvuh1eoK6nxhk.n edshj9k7dpZYOfRpTOesEqOCSXHRHZiN22BuhYUeZGbmF70vWs.S5FmdjZ6t0qP6shVuAEuiGtIc G6HScBV595A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 11 Sep 2018 09:44:53 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp419.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 32c42484b2aa6d29488d41a9bc0fb0e4; Tue, 11 Sep 2018 09:44:51 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-Id: Date: Tue, 11 Sep 2018 02:44:49 -0700 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 09:45:00 -0000 [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] I got 14 failures. I've not enabled any configuration properties. I do not know if official devel/kyua tests are part of the head -> stable transition for any tier or not. I'm not claiming to know if anything here could be a significant issue. Someone may want to test an official aarch64 build rather than presume that my personal build is good enough. But I expect that its results should be strongly suggestive, even if an official tests uses a more normal-for-FreeBSD configuration of an aarch64 system. The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file system. This might let some things pass that otherwise would time out. =3D=3D=3D> Failed tests lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.107s] lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output for = more details [0.013s] lib/msun/trig_test:special -> failed: 8 checks failed; see output for = more details [0.013s] local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: Line = 420: atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) = not met [4.470s] local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see = the output of the test for details [0.151s] usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, = 14 failed Total time: 6688.125s I'll note that the console reported over 73720 messages like (with = figures where I've listed ????'s): md????.eli: Failed to authenticate ???? bytes of data at offset ????. There are also device created and destroyed/removed notices with related material. Overall there were over 84852 lines reported with "GEOM_ELI:" on the line. This did not prevent tests from passing. (The huge console output is unfortunate in my view: it makes finding interesting console messages a problem while watching messages go by.) I did get the console message block: kern.ipc.maxpipekva exceeded; see tuning(7) Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with non-tentative = address (epair2Freed UMA keg (rtentry) was not empty (18 = items). Lost 1 pages of memory. a) Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. But no failure reports seemed to be associated. Still, I wonder if the block of messages is significant. Some other console messages seen (extracted from various places): GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] Again no failure reports seemed to be associated. Some or all of the following may be normal/expected: Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: exited = on signal 3 (core dumped) Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited on = signal 6 (core dumped) Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited on = signal 6 (core dumped) Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: exited = on signal 6 (core dumped) Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited on = signal 6 Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited on = signal 11 (core dumped) Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited on = signal 11 (core dumped) Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited on = signal 3 Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited on = signal 3 Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited on = signal 6 Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited on = signal 6 Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited on = signal 6 Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited on = signal 5 (core dumped) Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: exited = on signal 6 (core dumped) Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: exited = on signal 11 (core dumped) I'm not sure that they all would be expected. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Sep 11 15:48:15 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14F9A1095022 for ; Tue, 11 Sep 2018 15:48:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97EA07C7F1 for ; Tue, 11 Sep 2018 15:48:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: x78ZPcIVM1mhH3zDsAQngublf5Wo.WDv1Y56rUWndAqS6C8XUZsHxteLTJMHfU2 LqkYWw8_VoQgxXk_6eNtH6I.3qTBG7MF2odXjAjbS3hTf8wKzd47J8W.89BmU6J3_N3_VlPyR5Lj w8FkZOsJZuYwhkqyWTDQSGX5LPuxban1kjlsQeYkz6_zcKn7Atw_uVcgmDohcVetOiVwYGvhBCEw fIgEegynPYYVOGuzN1rL6UCwVdpWrHsHQplogDxtry_i5BhmJYZd5pxp7d7La34pXAqPoNcmn_q4 HABVaEZPdyzd29xniXyetBXMJVnbb4IieYw5dTbb2LfWMLFDRUrgZm30WVEP9z9VVbIzeajVBPUa Sdv_.FfTAluH894X41ge7XUBEQmWdkbgkphdR4a.FAmrw3aLKOc4pdctcF6LoSaa6BGjxcV24YCI RYbwi6oz9oHZqElJ4ftorYXbv_5DDlFqwN571Gai8oDr7aQEl3ww.TWq2i04jdb2oaVOVLVR8P3d StzKD6eRJOvnsA1bmtzIlas86S7_LetUuCR8YYSi4XebeBjzJa6oVqJqNpwSr_55e0nfurI_tP8t Dlm4QvZSKCvBiIsTSV89meiJqmGzgpx.UdVIXWJiDeNq9Ccvy0Bujq.y23kopmfthRg6NQyIiOuu HKir7aLYUAJjXZMniY1.yxyuo2mF4QM.kpPgyDEkPn6Shgxak7HsqHnxQO0MyX3qspjeeh1keDE2 zzlrVJqNyy_GpyGYg4xdmrf09DPXyty7wKDuud44HQiTL7Tjzoy5GaNXcv25YHi9TrduEsf1y9La 0.aYzlIE6lG.5IvGuaTM52zWhmBaXjgA4Ykd9DN1hDJ2YcV.A9ivSksPLqVUuPcWtvisqSaEz0OV hhTyRtDcdqbRWjUYoykVFkIuOrvJwgi5AydOyWSbtKNDKuXOsIY0KTq_2Vh20RNONWfM7zUM3UGQ M6LLCFKs6lB8JhOQ_7x44AuXbF.FXmIwWNsAOuX4.nUzOyHiRrT65MWxI1pEiuHPvrKE4HwNjw_w F_s7AW_U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 11 Sep 2018 15:48:07 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp401.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 451ae66fd0229211cc86b1d6ad14bc7f; Tue, 11 Sep 2018 15:48:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Date: Tue, 11 Sep 2018 08:48:03 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 15:48:15 -0000 [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. lib/libc/string/memcmp_test:diff is one of them.] On 2018-Sep-11, at 2:44 AM, Mark Millard wrote: > [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] >=20 > I got 14 failures. I've not enabled any configuration properties. >=20 > I do not know if official devel/kyua tests are part of the head -> > stable transition for any tier or not. I'm not claiming to know if > anything here could be a significant issue. >=20 > Someone may want to test an official aarch64 build rather than presume > that my personal build is good enough. But I expect that its results > should be strongly suggestive, even if an official tests uses a more > normal-for-FreeBSD configuration of an aarch64 system. >=20 > The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal > configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file > system. This might let some things pass that otherwise would time out. >=20 >=20 > =3D=3D=3D> Failed tests > lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] > lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.107s] > lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] > lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] > lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output = for more details [0.013s] > lib/msun/trig_test:special -> failed: 8 checks failed; see output = for more details [0.013s] > local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] > local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: Line = 420: atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) = not met [4.470s] > local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] > local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] > local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] > sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] > usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see = the output of the test for details [0.151s] > usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] > =3D=3D=3D> Summary > Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db > Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, = 14 failed > Total time: 6688.125s >=20 >=20 >=20 >=20 > I'll note that the console reported over 73720 messages like (with = figures > where I've listed ????'s): >=20 > md????.eli: Failed to authenticate ???? bytes of data at offset ????. >=20 > There are also device created and destroyed/removed notices with = related > material. Overall there were over 84852 lines reported with = "GEOM_ELI:" > on the line. >=20 > This did not prevent tests from passing. >=20 > (The huge console output is unfortunate in my view: it makes finding > interesting console messages a problem while watching messages > go by.) >=20 >=20 >=20 > I did get the console message block: >=20 > kern.ipc.maxpipekva exceeded; see tuning(7) > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with = non-tentative address (epair2Freed UMA keg (rtentry) was not = empty (18 items). Lost 1 pages of memory. > a) > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. > Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >=20 > But no failure reports seemed to be associated. >=20 > Still, I wonder if the block of messages is significant. >=20 >=20 > Some other console messages seen (extracted from various places): >=20 > GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] > GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] > GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] > GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). > GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). > GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] > GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] > GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] >=20 > Again no failure reports seemed to be associated. >=20 >=20 > Some or all of the following may be normal/expected: >=20 > Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: exited = on signal 3 (core dumped) > Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited = on signal 6 (core dumped) > Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: = exited on signal 6 (core dumped) > Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited = on signal 6 > Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited = on signal 11 (core dumped) > Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited on = signal 11 (core dumped) > Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited on = signal 3 > Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited on = signal 3 > Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated > Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 > Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited = on signal 6 > Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated > Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited = on signal 6 > Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited on = signal 6 > Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated > Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited on = signal 6 > Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited = on signal 5 (core dumped) > Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited = on signal 6 (core dumped) > Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: = exited on signal 6 (core dumped) > Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) > Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: exited = on signal 11 (core dumped) >=20 > I'm not sure that they all would be expected. =3D=3D=3D> Broken tests lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case = received signal 6 (core dumped) [3.962s] lib/libregex/exhaust_test:regcomp_too_big -> broken: Premature exit; = test case received signal 11 (core dumped) [8.997s] lib/msun/exponential_test:main -> broken: Received signal 6 [3.893s] lib/msun/fenv_test:main -> broken: Received signal 6 [4.326s] lib/msun/fma_test:main -> broken: Received signal 6 [4.315s] lib/msun/invtrig_test:main -> broken: Received signal 6 [4.345s] lib/msun/logarithm_test:main -> broken: Received signal 6 [3.921s] lib/msun/lrint_test:main -> broken: Received signal 6 [4.416s] lib/msun/nearbyint_test:main -> broken: Received signal 6 [4.389s] lib/msun/next_test:main -> broken: Received signal 6 [4.401s] lib/msun/rem_test:main -> broken: Received signal 6 [4.385s] sbin/growfs/legacy_test:main -> broken: TAP test program yielded = invalid data: Load of '/tmp/kyua.5BsFl9/3782/stdout.txt' failed: = Reported plan differs from actual executed tests [0.476s] sys/cddl/zfs/ ones ignored here: no zfs context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Sep 12 02:24:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A528410A67CA for ; Wed, 12 Sep 2018 02:24:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3019518D for ; Wed, 12 Sep 2018 02:24:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3ZdQWm4VM1l4hYoOYczE3I0zvmitYtLmi_P3xuvWE1mFOLf3c71VsWVVvWZ5jTb gSGzUzfT.Erbj7bPCYDVO9ducmWL5zTkGygURKCKbZXXdLT02qMlf8AyIfGEFvk0UfCtvhOtUaIW HS.xEaV2XmmOIsqHN26D5z8LEE.s3b2WBacvgJyhN_iN.xgJ261cYi84Tk..8z_Q_SlT596HMuhm zKtVg9di4.a1uU3Q4_7OjQAjY4AiDsUFRtHt1Ii9H.XDwHtNmzaXKOmW3.HJSYy8Ta68swsO0BE7 yQzs8ozpLoR.HsIPQ5C6olnRzMHWQcz7XXCTUqodQiLy.4Lpn4dcs1_.JSOItSkE1_tcZ6K6qeYK iTDuiqml10WmzBbMUQaOwHwefCdhyl2TXTQPA0Nb4wb_IJTwC3E2AU12MUQ1NIsPWDt2ZGJekVM2 CwAskKdAvKLUc0.vvJJNLG0.INwTyEW3XjAxXbN1KXZCu3H4nHJWxBv7X7_OO6hfS7piVcTGm1EU 6sl98UUsfHeZS6KDVC5xsTulAgpPz7QAuztA3L23_e.PqPW3P_ap1zINDP7f1D4ujmoBLWIDqB7I AmaI1pJz3zu5XL7Lqsf8b7.STNXLS5gmkKbf4xSOwTPUPDaDSwSns3eRcxEFpoExcdgKQNJgecZ8 9Hwa8ZeDzOIwwK39axGMt_R7eQX_LIUxp9ugg0XvwnnPrs4X2rNXaEV8nnQoP0JZ_fKRtlGWQLSw SMmbyy72Cu5QS4qk6BXZhtpAhuay1Eu6wXMHL.DY4t85HB8FygT0Z6TtSHpR4VAPk08N99vpDOws Xri3naB2HT6LgCPOTg3ED1NmV1d4cOTSz9hg9zMIq3Pmq7gg2BHb8NSX0Az9ZKxrlMJBb4k7REry PhQ1zrfzmBl85RMI7PBXJygRChPg8t8iEA2FfPH1XyfFL8VimYVhvKp2ngyVL32m91Se38VwJXD8 3b66xz2vp7aDWvMeruHaRGYdH_8GHeY10mJFLT3lS__JzZYglYqMuL6pNy3bHxuoDsIOVOxFIvFK fTnENYQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Sep 2018 02:24:04 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 927b9386155167cb3794e88956251398; Wed, 12 Sep 2018 02:24:01 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context [md related processes left waiting (and more)] Date: Tue, 11 Sep 2018 19:24:00 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: <3E3E4449-E132-4F59-87C8-22A0AD2092BF@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:24:12 -0000 [After the run top -CawSopid shows something interesting/odd: lots of g_eli[?] and md?? processes are still around in=20 geli:w state for g_eli[?] and mdwait for md??. Also there are 4 processes in aiordy state.] On 2018-Sep-11, at 8:48 AM, Mark Millard wrote: > [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. > lib/libc/string/memcmp_test:diff is one of them.] >=20 > On 2018-Sep-11, at 2:44 AM, Mark Millard wrote: >=20 >> [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.] >>=20 >> I got 14 failures. I've not enabled any configuration properties. >>=20 >> I do not know if official devel/kyua tests are part of the head -> >> stable transition for any tier or not. I'm not claiming to know if >> anything here could be a significant issue. >>=20 >> Someone may want to test an official aarch64 build rather than = presume >> that my personal build is good enough. But I expect that its results >> should be strongly suggestive, even if an official tests uses a more >> normal-for-FreeBSD configuration of an aarch64 system. >>=20 >> The e.MMC is V5.1 is operating in DDR52 mode and is faster than = normal >> configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file >> system. This might let some things pass that otherwise would time = out. >>=20 >>=20 >> =3D=3D=3D> Failed tests >> lib/libc/resolv/resolv_test:getaddrinfo_test -> failed: = /usr/src/lib/libc/tests/resolv/resolv_test.c:299: = run_tests(_hostlist_file, METHOD_GETADDRINFO) =3D=3D 0 not met = [98.834s] >> lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see = the output of the test for details [0.107s] >> lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.105s] >> lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, &tsym, = sizeof(*sym)) !=3D 0 [0.057s] >> lib/msun/trig_test:accuracy -> failed: 3 checks failed; see output = for more details [0.013s] >> lib/msun/trig_test:special -> failed: 8 checks failed; see output = for more details [0.013s] >> local/kyua/utils/stacktrace_test:dump_stacktrace__integration -> = failed: Line 391: atf::utils::grep_file("#0", = exit_handle.stderr_file().str()) not met [4.015s] >> local/kyua/utils/stacktrace_test:dump_stacktrace__ok -> failed: = Line 420: atf::utils::grep_file("^frame 1$", = exit_handle.stderr_file().str()) not met [4.470s] >> local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append = -> failed: Line 560: atf::utils::grep_file("frame 1", = exit_handle.stderr_file().str()) not met [4.522s] >> local/kyua/utils/stacktrace_test:find_core__found__long -> failed: = Core dumped, but no candidates found [3.988s] >> local/kyua/utils/stacktrace_test:find_core__found__short -> failed: = Core dumped, but no candidates found [4.014s] >> sys/kern/ptrace_test:ptrace__PT_STEP_with_signal -> failed: = /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) =3D=3D = SIGABRT not met [0.017s] >> usr.bin/indent/functional_test:nsac -> failed: atf-check failed; = see the output of the test for details [0.151s] >> usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] >> =3D=3D=3D> Summary >> Results read from = /root/.kyua/store/results.usr_tests.20180911-070147-413583.db >> Test cases: 7301 total, 212 skipped, 37 expected failures, 116 = broken, 14 failed >> Total time: 6688.125s >>=20 >>=20 >>=20 >>=20 >> I'll note that the console reported over 73720 messages like (with = figures >> where I've listed ????'s): >>=20 >> md????.eli: Failed to authenticate ???? bytes of data at offset ????. >>=20 >> There are also device created and destroyed/removed notices with = related >> material. Overall there were over 84852 lines reported with = "GEOM_ELI:" >> on the line. >>=20 >> This did not prevent tests from passing. >>=20 >> (The huge console output is unfortunate in my view: it makes finding >> interesting console messages a problem while watching messages >> go by.) >>=20 >>=20 >>=20 >> I did get the console message block: >>=20 >> kern.ipc.maxpipekva exceeded; see tuning(7) >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with = non-tentative address (epair2Freed UMA keg (rtentry) was not = empty (18 items). Lost 1 pages of memory. >> a) >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >> Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of = memory. >>=20 >> But no failure reports seemed to be associated. >>=20 >> Still, I wonder if the block of messages is significant. >>=20 >>=20 >> Some other console messages seen (extracted from various places): >>=20 >> GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D524288, = length=3D2048)] >> GEOM_MIRROR: Request failed (error=3D6). md28[READ(offset=3D1048576, = length=3D2048)] >> GEOM_MIRROR: Request failed (error=3D5). md28[WRITE(offset=3D0, = length=3D2048)] >> GEOM_MIRROR: Cannot write metadata on md29 (device=3Dmirror.KRYGpE, = error=3D5). >> GEOM_MIRROR: Cannot update metadata on disk md29 (error=3D5). >> GEOM_MIRROR: Request failed (error=3D5). md28[READ(offset=3D0, = length=3D131072)] >> GEOM_MIRROR: Synchronization request failed (error=3D5). = mirror/mirror.YQGUHJ[READ(offset=3D0, length=3D131072)] >> GEOM_MIRROR: Request failed (error=3D5). md29[READ(offset=3D0, = length=3D131072)] >>=20 >> Again no failure reports seemed to be associated. >>=20 >>=20 >> Some or all of the following may be normal/expected: >>=20 >> Sep 11 00:05:44 pine64 kernel: pid 21057 (process_test), uid 0: = exited on signal 3 (core dumped) >> Sep 11 00:05:49 pine64 kernel: pid 21071 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:05:54 pine64 kernel: pid 21074 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:05:58 pine64 kernel: pid 21077 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:03 pine64 kernel: pid 21080 (sanity_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:44 pine64 kernel: pid 23170 (cpp_helpers), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:06:49 pine64 kernel: pid 23306 (c_helpers), uid 977: exited = on signal 6 (core dumped) >> Sep 11 00:06:54 pine64 kernel: pid 23308 (cpp_helpers), uid 977: = exited on signal 6 (core dumped) >> Sep 11 00:18:44 pine64 kernel: pid 38227 (assert_test), uid 0: exited = on signal 6 >> Sep 11 00:51:38 pine64 kernel: pid 39883 (getenv_test), uid 0: exited = on signal 11 (core dumped) >> Sep 11 00:51:51 pine64 kernel: pid 40063 (memcmp_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:53:26 pine64 kernel: pid 40627 (wait_test), uid 0: exited = on signal 11 (core dumped) >> Sep 11 00:53:27 pine64 kernel: pid 40632 (wait_test), uid 0: exited = on signal 3 >> Sep 11 00:53:27 pine64 kernel: pid 40634 (wait_test), uid 0: exited = on signal 3 >> Sep 11 07:53:32 pine64 h_fgets[41013]: stack overflow detected; = terminated >> Sep 11 00:53:32 pine64 kernel: pid 41013 (h_fgets), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_gets[41049]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41049 (h_gets), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_memcpy[41066]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41066 (h_memcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_memmove[41083]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41083 (h_memmove), uid 0: exited = on signal 6 >> Sep 11 07:53:33 pine64 h_memset[41100]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41100 (h_memset), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_read[41135]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41135 (h_read), uid 0: exited on = signal 6 >> Sep 11 07:53:33 pine64 h_readlink[41152]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41152 (h_readlink), uid 0: exited = on signal 6 >> Sep 11 07:53:33 pine64 h_snprintf[41169]: stack overflow detected; = terminated >> Sep 11 00:53:33 pine64 kernel: pid 41169 (h_snprintf), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_sprintf[41186]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41186 (h_sprintf), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_stpcpy[41203]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41203 (h_stpcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_stpncpy[41220]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41220 (h_stpncpy), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_strcat[41237]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41237 (h_strcat), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_strcpy[41254]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41254 (h_strcpy), uid 0: exited on = signal 6 >> Sep 11 07:53:34 pine64 h_strncat[41271]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41271 (h_strncat), uid 0: exited = on signal 6 >> Sep 11 07:53:34 pine64 h_strncpy[41288]: stack overflow detected; = terminated >> Sep 11 00:53:34 pine64 kernel: pid 41288 (h_strncpy), uid 0: exited = on signal 6 >> Sep 11 00:53:41 pine64 kernel: pid 41478 (target_prog), uid 0: exited = on signal 5 (core dumped) >> Sep 11 00:56:53 pine64 kernel: pid 43967 (exponential_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:56:58 pine64 kernel: pid 43972 (fenv_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:02 pine64 kernel: pid 43974 (fma_test), uid 0: exited on = signal 6 (core dumped) >> Sep 11 00:57:07 pine64 kernel: pid 43990 (invtrig_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:13 pine64 kernel: pid 44067 (logarithm_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:17 pine64 kernel: pid 44069 (lrint_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:21 pine64 kernel: pid 44073 (nearbyint_test), uid 0: = exited on signal 6 (core dumped) >> Sep 11 00:57:26 pine64 kernel: pid 44075 (next_test), uid 0: exited = on signal 6 (core dumped) >> Sep 11 00:57:31 pine64 kernel: pid 44100 (rem_test), uid 0: exited on = signal 6 (core dumped) >> Sep 11 00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: = exited on signal 11 (core dumped) >>=20 >> I'm not sure that they all would be expected. >=20 > =3D=3D=3D> Broken tests > lib/libc/string/memcmp_test:diff -> broken: Premature exit; test = case received signal 6 (core dumped) [3.962s] > lib/libregex/exhaust_test:regcomp_too_big -> broken: Premature exit; = test case received signal 11 (core dumped) [8.997s] > lib/msun/exponential_test:main -> broken: Received signal 6 = [3.893s] > lib/msun/fenv_test:main -> broken: Received signal 6 [4.326s] > lib/msun/fma_test:main -> broken: Received signal 6 [4.315s] > lib/msun/invtrig_test:main -> broken: Received signal 6 [4.345s] > lib/msun/logarithm_test:main -> broken: Received signal 6 [3.921s] > lib/msun/lrint_test:main -> broken: Received signal 6 [4.416s] > lib/msun/nearbyint_test:main -> broken: Received signal 6 [4.389s] > lib/msun/next_test:main -> broken: Received signal 6 [4.401s] > lib/msun/rem_test:main -> broken: Received signal 6 [4.385s] > sbin/growfs/legacy_test:main -> broken: TAP test program yielded = invalid data: Load of '/tmp/kyua.5BsFl9/3782/stdout.txt' failed: = Reported plan differs from actual executed tests [0.476s] >=20 > sys/cddl/zfs/ ones ignored here: no zfs context. One more thing of note after kyua completed (the Pine64+ 2GB has been mostly idle since then), top shows: last pid: 59782; load averages: 0.22, 0.25, 0.19 = = up 0+19:13:11 19:11:36 122 processes: 2 running, 119 sleeping, 1 waiting CPU: 0.0% user, 0.0% nice, 0.0% system, 0.1% interrupt, 99.9% idle Mem: 2164K Active, 1474M Inact, 14M Laundry, 365M Wired, 202M Buf, 122M = Free Swap: 3584M Total, 3584M Free PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 82157 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md27] 82156 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md27] 82155 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md27] 82154 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md27] 82147 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md27] 82001 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md26] 81941 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md25] 81940 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md25] 81939 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md25] 81938 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md25] 81925 root 1 -8 - 0 16K 0 mdwait 1 0:00 = 0.00% [md25] 81777 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md24p1] 81776 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md24p1] 81775 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md24p1] 81774 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md24p1] 81701 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md24] 81598 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md23] 72532 root 1 -8 - 0 16K 0 mdwait 0 0:01 = 0.00% [md22] 70666 root 1 -8 - 0 16K 0 mdwait 2 0:01 = 0.00% [md21] 70485 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md20] 70484 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md20] 70483 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md20] 70482 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md20] 70479 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md20] 70413 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md19.nop] 70412 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md19.nop] 70411 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md19.nop] 70410 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md19.nop] 70393 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md19] 70213 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md18] 70212 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md18] 70211 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md18] 70210 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md18] 70193 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md18] 70088 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md17] 59763 root 1 -8 - 0 16K 0 mdwait 3 0:01 = 0.00% [md16] 49482 root 1 -8 - 0 16K 0 mdwait 2 0:01 = 0.00% [md15] 27196 root 1 -8 - 0 16K 0 mdwait 0 0:04 = 0.00% [md14] 27018 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md13] 26956 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md12] 26364 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md11] 16100 root 1 -8 - 0 16K 0 mdwait 2 0:03 = 0.00% [md10] 15556 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md9] 15498 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md8] 15497 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md8] 15496 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md8] 15495 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md8] 15462 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md8] 13400 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md7] 13101 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md6] 13005 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md5] 13004 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md5] 13003 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md5] 13002 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md5] 12995 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md5] 12877 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md4] 12719 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md3] 12621 root 1 -8 - 0 16K 0 mdwait 0 0:00 = 0.00% [md2] 12559 root 1 20 - 0 16K 0 geli:w 3 0:00 = 0.00% [g_eli[3] md1] 12558 root 1 20 - 0 16K 0 geli:w 2 0:00 = 0.00% [g_eli[2] md1] 12557 root 1 20 - 0 16K 0 geli:w 1 0:00 = 0.00% [g_eli[1] md1] 12556 root 1 20 - 0 16K 0 geli:w 0 0:00 = 0.00% [g_eli[0] md1] 12549 root 1 -8 - 0 16K 0 mdwait 3 0:00 = 0.00% [md1] 12477 root 1 -8 - 0 16K 0 mdwait 2 0:00 = 0.00% [md0] 1345 root 1 -16 - 0 16K 0 aiordy 1 0:00 = 0.00% [aiod4] 1344 root 1 -16 - 0 16K 0 aiordy 3 0:00 = 0.00% [aiod3] 1343 root 1 -16 - 0 16K 0 aiordy 2 0:00 = 0.00% [aiod2] 1342 root 1 -16 - 0 16K 0 aiordy 0 0:00 = 0.00% [aiod1] 34265 root 1 20 0 14M 2668K 0 CPU3 3 3:10 = 0.28% top -CawSores 34243 root 1 23 0 12M 1688K 0 wait 2 0:00 = 0.00% su (sh) 34242 markmi 1 20 0 13M 1688K 0 wait 2 0:00 = 0.00% su 34236 markmi 1 21 0 12M 1688K 0 wait 0 0:00 = 0.00% -sh (sh) 34235 markmi 1 20 0 20M 1312K 0 select 1 0:09 = 0.01% sshd: markmi@pts/1 (sshd) 34230 root 1 21 0 20M 3460K 0 select 3 0:00 = 0.00% sshd: markmi [priv] (sshd) 898 root 1 52 0 12M 1688K 0 ttyin 1 0:00 = 0.00% su (sh) 897 markmi 1 21 0 13M 1688K 0 wait 2 0:00 = 0.00% su 889 markmi 1 26 0 12M 1688K 0 wait 3 0:00 = 0.00% -sh (sh) 888 markmi 1 20 0 21M 1016K 0 select 1 0:03 = 0.00% sshd: markmi@pts/0 (sshd) 885 root 1 23 0 20M 3460K 0 select 2 0:00 = 0.00% sshd: markmi [priv] (sshd) 836 root 1 20 0 12M 2164K 0 ttyin 0 0:03 = 0.00% -sh (sh) 835 root 1 20 0 13M 1688K 0 wait 1 0:00 = 0.00% login [pam] (login) 785 root 1 52 0 11M 884K 0 nanslp 0 0:01 = 0.00% /usr/sbin/cron -s 781 smmsp 1 20 0 15M 796K 0 pause 3 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = (sendmail) 778 root 1 20 0 15M 1832K 0 select 2 0:02 = 0.00% sendmail: accepting connections (sendmail) 775 root 1 20 0 19M 788K 0 select 1 0:00 = 0.00% /usr/sbin/sshd 731 root 1 20 0 18M 18M 0 select 3 0:07 = 0.01% /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g 694 root 32 52 0 11M 1112K 0 rpcsvc 0 0:00 = 0.00% nfsd: server (nfsd) After the run top -CawSopid shows something interesting/odd: lots of g_eli[?] and md?? processes are still around in geli:w state for g_eli[?] and mdwait for md??. Also there are 4 aiod? processes in the aiordy state as well. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Sep 12 10:11:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92BE7108E63C for ; Wed, 12 Sep 2018 10:11:51 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh503-vm7.bullet.mail.kks.yahoo.co.jp (nh503-vm7.bullet.mail.kks.yahoo.co.jp [183.79.56.193]) by mx1.freebsd.org (Postfix) with SMTP id B9C8C7BF1D for ; Wed, 12 Sep 2018 10:11:50 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.138] by nh503.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Sep 2018 10:11:43 -0000 Received: from [183.79.100.137] by t501.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Sep 2018 10:11:43 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 12 Sep 2018 10:11:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 318475.29852.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 23770 invoked by uid 60001); 12 Sep 2018 10:11:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1536747103; bh=Qiy7iIlQ2/qPQHkNnZ/TrbgOy9aR7Lg35iy/WDNtLgI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b7OXzglL/fkK9Bg18CXRdiHg+gQb4sf8HxnmHITX2OUfPUMrcVvpQou2cYbj/9E26CQBeZp9DoW+j6NB1u0U8OkXnJu3NSRtWGxyhyzXpuM/lzHFNtTJ+Rg5eLkEj9s/9AkyiZxsrDKLCrLeFID0ktGD4z4Qod9pLSTrUIlyz0I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C1/g38Z0UzJM9O94x1WM+InIzuH/qocoiMPbcRUqdc1J9hfeVr8zPZJOmg+TURHwR3mN3humReqGWxOwW7JKZ2iGK5LAFhUMSDFzKGPdQ3eyM7zpUGB0fRcfsSEH09UQgw2qxH3oxXc/hR18KGjgQYLrvwKLAz+g32VymXqQ3GQ=; Message-ID: <56209.23275.qm@web103907.mail.ssk.yahoo.co.jp> X-YMail-OSG: aKEAnwEVM1mPK6.MMLaCcnTPMaMCI8xCXzIDL4_MkLL0zD_NFdRSlJUpb5yMFV0n3AR4wkt500UPp5U16moQM5o3PiAEfNABzZVlwyru_hG_Rmq8iyYKExei5O1Vgncj7U8N1uFl_kxH.bN3fAfK0riwMGcjE_lMrWEnjA0R3zr.nOj1_e3BsDGPZvBvWER29zDf4KASPICTsxn_C1iFX.QwwqPl.xuU1QxvXi9nyA65o5uPvg0ZyUAqsRD1tsKwUSzxHMGuIXD_03mvMR_e8xrQMKfIMWcexs91gSILgrj0PDOgkNUgjP8XV3Bv_0MRs4HjSDCAb.1Rbo1J9k1oTDDLPhBNAU82V3yH1H2NLJHeg0.u6cAMENIt9h.iY8BaO5_nvfakaXuzs6lngZI264oECoOQOyEweK0rKaCB7ITXEv.TgZF3mTgzUGYhcMI.FA.3AMzXreAjERGL3DyyvEdUeo3HhBTi9aIqbCMhUlnL5yGaN_WVa49Rb1Mgkke._iFWGlIuD0keP0gxZdoUDZNCEWgdM2ITpxW1woiY8BggLTAlM1tikPCmh5NufaS2Hp6pxsj1I_H0iw0PH3_trCSp7hX5hVOq0.HcIk9Gl.6JCZSiH7e7MTocUKAMu63hoLqoQD4uzOoAYW8YqucP Received: from [203.165.91.75] by web103907.mail.ssk.yahoo.co.jp via HTTP; Wed, 12 Sep 2018 19:11:41 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: lwexbfwVM1kVxh8W8ROm1oCMWxLjMhrSyb3yq1dg.3LtYF7DNwPD.zP_.cb3y3prg6S13GPCxOzTftCCUZE2SmyFSviOFlo.7Ub27UK47Kcz1gfODSOZAuaU7HljuzMRlNSB Date: Wed, 12 Sep 2018 19:11:41 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: real memory is 0 MB To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 10:11:51 -0000 Hi=0A=0AI build today's head and run on rt1310.=0A=0Ahttps://gist.github.co= m/yamori813/88224f1c96c9c592fb611b12a15e4ab5=0A=0A=0AI found strange log.= =0A=0Areal memory =3D 0 (0MB)=0A=0AWhy ?=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Wed Sep 12 10:29:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B58D108EEA5 for ; Wed, 12 Sep 2018 10:29:21 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:191:217b::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1AAB7C83E for ; Wed, 12 Sep 2018 10:29:20 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Wed, 12 Sep 2018 12:29:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail201809; t=1536748158; bh=4KrvPlc5QsWHon5CbTQVU42523oADQAjqncydzq3GHA=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:from:to: subject:date:content-type:mime-version:message-id; b=HoF6lGpjffcNCMRNtBQa317YTpc3cMSx0V61N4JuyjrHX8jXuI/ZLmQYNZY1f28zL g8Q+Nwq/Wf2i70kK5+h3k/OwGMGwOa5D5XDLqjOoakWb4qHY+MIgvS2vEu3WVO6iTT 0C16wwXCLHEv++bV9UYmELtC6hZLQjrM0bh0EbAP4XDXV2jBQOncYFTxld8StNgfDV ozf9KXKhbPYwiMUYxTETeN2LcbQw1MwoneXhE04PM3YHqVmEb3yFjuMn8T/mtkT7NS zgUL2d/b65QttEsR/81sTwvRkaXN1wMXheTBrh46KjrwkB8dym4TkqqOrUUk3/U4xV POzmuGp9AGt2g== From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: real memory is 0 MB Message-ID: <20180912102918.ua4nlamcyzw2ycwe@mail.bsd4all.net> References: <56209.23275.qm@web103907.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56209.23275.qm@web103907.mail.ssk.yahoo.co.jp> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 10:29:21 -0000 On Wed, Sep 12, 2018 at 07:11:41PM +0900, Mori Hiroki wrote: > Hi > > I build today's head and run on rt1310. > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 > > > I found strange log. > > real memory = 0 (0MB) > > Why ? Same issue on Raspberry Pi 2 Model B: real memory = 0 (0 MB) avail memory = 1011384320 (964 MB) % sysctl -a | egrep "hw.(phys|real|user)mem" hw.physmem: 1034596352 hw.usermem: 854900736 hw.realmem: 0 'grep "real memory" /var/log/messages' shows: May 5 23:22:03 rpi01 kernel: real memory = 989851648 (943 MB) Jun 2 12:05:45 rpi01 kernel: real memory = 0 (0 MB) May 5 23:22:03 rpi01 kernel: FreeBSD 12.0-CURRENT #1 r333274: Sat May 5 22:33:37 CEST 2018 Jun 2 12:05:45 rpi01 kernel: FreeBSD 12.0-CURRENT #2 r334527: Sat Jun 2 11:19:21 CEST 2018 -- Herbert From owner-freebsd-arm@freebsd.org Wed Sep 12 10:36:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 018AD108F294 for ; Wed, 12 Sep 2018 10:36:25 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:191:217b::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 960D17CD13 for ; Wed, 12 Sep 2018 10:36:24 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Wed, 12 Sep 2018 12:36:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail201809; t=1536748583; bh=ohwNbIRXDaLitnZfze2w3YmxtThADZz5vZQ2EcAqMNM=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:from:to: subject:date:content-type:mime-version:message-id; b=gfHJ0t8R2kOlruGrCc6FJ3CW6O/NeMkLkXRqIP8uhI7qIdBESEtnvlfeQS1GQKc8C Zoy36ReaKbvx05Z1Pd+H516E27Fsn6HtQWi1BM7Qnz1ErvacZpdxy6FqVxwrEyWQze S0L7+n5DRcvNwlNRXfWPZ/RUNlVzFJG46xaSjfVKKoyn9JWqAwhPFMznobGDV3OgoP WXgk569u/xX2ezdrMfUTTnFVamI524MamavYq1WcytneUnA10Od8UAxqLTERoEjdFh UGsYYPVHpy8lSW1WyBWQJzeXRnJa1PKGG+N1mQI40BMJN90jkiVUGVlNeBlAEXviRS ipDdqKMgIZXpg== From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: real memory is 0 MB Message-ID: <20180912103623.khrvoh3tfdqvvalz@mail.bsd4all.net> References: <56209.23275.qm@web103907.mail.ssk.yahoo.co.jp> <20180912102918.ua4nlamcyzw2ycwe@mail.bsd4all.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180912102918.ua4nlamcyzw2ycwe@mail.bsd4all.net> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 10:36:25 -0000 On Wed, Sep 12, 2018 at 12:29:18PM +0200, Herbert J. Skuhra wrote: > On Wed, Sep 12, 2018 at 07:11:41PM +0900, Mori Hiroki wrote: > > Hi > > > > I build today's head and run on rt1310. > > > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 > > > > > > I found strange log. > > > > real memory = 0 (0MB) > > > > Why ? > > Same issue on Raspberry Pi 2 Model B: And Raspberry Pi 3 Model B (FreeBSD 12.0-ALPHA5 r338541): % sysctl hw |grep mem hw.physmem: 971988992 hw.usermem: 829018112 hw.realmem: 0 (no memory size information in /var/log/messages). -- Herbert From owner-freebsd-arm@freebsd.org Wed Sep 12 11:03:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20EE1108FC5D for ; Wed, 12 Sep 2018 11:03:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B72DF7DB52 for ; Wed, 12 Sep 2018 11:03:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EB50C10D4E for ; Wed, 12 Sep 2018 11:03:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w8CB3rU2042203 for ; Wed, 12 Sep 2018 11:03:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8CB3r6C042202 for freebsd-arm@FreeBSD.org; Wed, 12 Sep 2018 11:03:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231325] CURRENT ALPHA5: rescue/sh check failed Date: Wed, 12 Sep 2018 11:03:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: joneum@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 11:03:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231325 Bug ID: 231325 Summary: CURRENT ALPHA5: rescue/sh check failed Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: joneum@FreeBSD.org :/usr/src # make installworld make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using cached toolchain metadata from build at rescue on Wed Sep 12 10:59:33 CEST = 2018 /bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found rescue/sh check failed, installation aborted *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. /usr/src is up-to-date with "svn up" # uname -a FreeBSD rescue 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #0 r338597: Tue Sep 11 23:07= :44 CEST 2018 root@rescue:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Sep 14 18:24:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC025109013D for ; Fri, 14 Sep 2018 18:24:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A38F8C9F6 for ; Fri, 14 Sep 2018 18:24:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wv9oV7kVM1n0T.vTn5n.9Mb_AshowmWind_gaPmzwjVb.YBRM8Ag_rVRikFgkQR ziKXpAPrElhQzv.DNrxpQtISLXidDfaIpO2Vmvid0Sj23GupygtX2t.FAoMWqrT5mySDBACFKF9V 0luBgbaBX52AZYrVzXfdnuf5zBCMddno0kCuDnk9HqsfAG64j38dS1Ay8I.IEIv_5s7vErgPaC66 tXpvXTr.d2XI0dd.86Bd.MIsegv87NLIjvGr6MA9q1w2asqIOCKOlFq8N7vg.Dw_8.mfsXdeioCd wpbNH6RHqgGuTB0xV4bGRCcfNAj4O7ncgQHSdoCpfC.nz0CQ6y1sS46G1JuNnmGwzJBlX7XbaHQt 5YIcFnh0T60IQSduThD8S7kUQzaEP0brdQ1q0LgG9k6eM1skcG07Fg26GOZ45UD.0AUbIdjh41GG qs3pmrkvs19JW8jO7EOmCqeMaQtnG_TuJYsT4lUighQAUWAmnDTLyvu6RCYmesoPaBfkLjSBcD8T Bv61yK7Ehbjgq2VAs45MyPFwz.YbsfGTYELdDMWpfIxNY03rrL8QYme49uOrs31cBsd1_pzaITCX 0L_e957xfFn0gJyMqsZUYOMZjescvwXH0VWlQZRc33RcLYLiWJK8sbiYaBg3Xtq.4XpZqOvIUIEz pR.6ieE417TPblVfxub_7oQTu7.uk8R3wveFoXLaW6o97EaKJBEGgrcP9VNseInGWb4ZsfnL0NoT EiCVb4tuZdbUT3331TRn1MlFtb1FvIs3MDvJbeluJoBmf4KPaNLPguMAgI.WSP.pMpUKAEyOfQbN bXfKKmq8ES73l6QbFnk0ZdrfUovf4YNopj57eIlVN5GPTiH7rKWheA4Y828wZ83d6rxZ0h5MQWyT anyrpHAYUQozQR9EtOnwfaNxdowDF_vLd1ozms3TwdIYAH0buVhCzmIdd4i1zIH8xcc6zhdeYsai o7oEFr5UkyC8HWvbUuuTUyHRoIsVLy15I3jHWIm.Y9QIH8pdvU3fqxhJ.0gvdxW_2zLIidPA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 14 Sep 2018 18:24:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f1da5f9dede5893759a0964615ace41c; Fri, 14 Sep 2018 18:24:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: devd on head -r338675 on aarch64 (Pine64+ 2GB example) gets during booting: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found" Message-Id: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Date: Fri, 14 Sep 2018 11:24:03 -0700 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 18:24:13 -0000 =46rom the boot of the Pine64+ 2GB for -r338675: . . . Starting devd. sh: /usr/libexec/hyperv/hyperv_vfattach: not found add host 127.0.0.1: gateway lo0 fib 0: route already in table . . . This seems to result from: # grep -r hyperv_vfattach /etc/ | more /etc/devd/hyperv.conf:# For transparent network VF, hyperv_vfattach does = nothing and /etc/devd/hyperv.conf: action "/usr/libexec/hyperv/hyperv_vfattach = $subsystem 0"; But for the aarch64/pine64+ context there is only: # ls -a /usr/libexec/hyperv/ . .. On amd64 that directory has content, including the file referenced. aarch64/pine64+ is likely not unique in missing the files in /usr/libexec/hyperv/ . Context: uname output: # uname -apKU FreeBSD pine64 12.0-ALPHA6 FreeBSD 12.0-ALPHA6 #6 r338675M: Thu Sep 13 = 18:48:05 PDT 2018 = markmi@pine64:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64= /sys/GENERIC-NODBG arm64 aarch64 1200084 1200084 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Sep 14 22:59:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FA971095DEA; Fri, 14 Sep 2018 22:59:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA80175873; Fri, 14 Sep 2018 22:59:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id E56B010AFCD; Fri, 14 Sep 2018 18:59:27 -0400 (EDT) Subject: Re: devd on head -r338675 on aarch64 (Pine64+ 2GB example) gets during booting: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found" To: Mark Millard , freebsd-arm , FreeBSD Current References: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Cc: dexuan@FreeBSD.org From: John Baldwin Message-ID: Date: Fri, 14 Sep 2018 15:59:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1B2307CA-A0EA-4590-81FC-67423268454C@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 14 Sep 2018 18:59:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 22:59:33 -0000 On 9/14/18 11:24 AM, Mark Millard via freebsd-arm wrote: > From the boot of the Pine64+ 2GB for -r338675: > > . . . > Starting devd. > sh: /usr/libexec/hyperv/hyperv_vfattach: not found > add host 127.0.0.1: gateway lo0 fib 0: route already in table > . . . I got the same error booting FreeBSD/riscv in qemu. -- John Baldwin                                                                              From owner-freebsd-arm@freebsd.org Fri Sep 14 23:24:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF5C110966A0 for ; Fri, 14 Sep 2018 23:24:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F71A764AF for ; Fri, 14 Sep 2018 23:24:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 83A8C108A6 for ; Fri, 14 Sep 2018 23:24:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w8ENOtLV075658 for ; Fri, 14 Sep 2018 23:24:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8ENOtpk075657 for freebsd-arm@FreeBSD.org; Fri, 14 Sep 2018 23:24:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231366] CARP setup on two servers Date: Fri, 14 Sep 2018 23:24:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: siva@myglobaldata.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 23:24:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231366 Bug ID: 231366 Summary: CARP setup on two servers Product: Base System Version: 11.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: siva@myglobaldata.com I have been working on setup the CARP between two FREEBSD servers from last= one month. I installed FreeBSD 11.2- RELEASE VM's on my two VMware servers. I s= etup one as a master other as a slave. I'm able to see the CARP status on both my servers as a MASTER and BACKUP. I can able to ping CARP ip from my other servers. If i reboot my master server i am getting couple of errors in sla= ve server. I would like run the HAST and CARP failover script between two serv= ers but i am getting following servers. 1. ifa_maintain_loopback_route: deletion failed for interface em0:3 2. carp: 1@em0: BACKUP -> MASTER (master timed out) I did following troubleshooting steps: 1. I changed Net.ReversePathFwdCheckPromisc to 1 on my both VMware servers 2. i changed net.inet.carp.preempt value to 1 in sysctl config file. 3. I connected two servers to dummy switch. Please help me on this issue. Thank you Siva --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Sep 15 02:26:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50E16109A0F6 for ; Sat, 15 Sep 2018 02:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8A307B36D for ; Sat, 15 Sep 2018 02:26:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: NB71J_QVM1lHaYTMyEZ8Mu9klXBp3SIhoNvvv3fvqw1CTxi0XluNIS4hPhgm.zB F6hEZ6IfCpY8cROszfmdpJAqDyoGboXVIC4za8RYuGV6KiGVU0SvuWAxTODi6aKPfAwpVoKYoS1w e4qGhWJpWFx3n9S_gI2qKoviP3mWFQ7cECKlMl8HPLfcPeFh5RiAsPQk8vLL1hhksWGD3IQqq8FX CIH4tNbDqnywBfwVRKmqUBM6KrlvwrWZL2rmMZk7LM45u0Ygz.FNv8gRbhQh19bFFL4KHDpAWTal XPGHgrjt_BzPX563u5RsoeH6jgLpbjhSSA_PvZcn29_XQRIDURR06_.1Xecpf7fjujLtONFBy0cX NpZdDvGEn9w3MCifJh12uzGHD6wDdWnYux6CxP31U68py6Njh4Q2LHroxkWBKBzj_4cDiUxyPmp4 2M8x1.EsDo48H7Iqga7ha3vJcYvnL7eVrfkeTInnEHTBeCOW3Q2n0.Kf5IyIhZ8sOOd86mBXT.Ft eAqtcgdADkbAl9pPyUUs0AwsZcxH0ekmXEKxEnMhffemtNu0_u5sn4OqDayuGFdkK08K9pkQB0xL H_S4PyKlxsjgY7r8y0JED0MrTR3qmKUa15XP4JJ2MoPwdc1IuS7zX2NjAofCj1q6WvJ9avB2NlwO nGCuu_7YosLinQei5vQQ1p03dmmpbBhlgaSK1RIsYajIjvM7w34aqeiOmSJrtTHing6XFnoMKZpU BfNociTIWvF.kTnAlPi6squItRP82gNE_FIt2CzwUJ3QfZ7nDv_75I5t59bIqwJ7S8.VIVN_dkUP B.M7zlWeqMsYQJtYj.1zSOKQCNWl9wxItV.PcBG8l0SdBP7YS_mXB23HKlEFGbWzqQ7j26LkwESU Wo4T10fGAoPBZNBirhYADrd_lLYKWijTnjG5c.njPKIQSguvZ6eETC_5HDnw.z_Y6MVAs0WauvFj .vuJCKAaHmU9gpe1IMgHqLAMLx89q7GiK8vA2FuansHTdzytwgtOz.fYawgrAQejj19ScLrSEkhN hTOQSm1pPAX1q Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Sat, 15 Sep 2018 02:26:24 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5e7b754f31acfc8d4eeb553d17f279ee; Sat, 15 Sep 2018 02:16:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: An experimental hack that makes head -r338518 boot from e.MMC via an microsd card adapter, in DDR52 mode at that From: Mark Millard In-Reply-To: <6D375D5B-34E2-4124-9A32-92C320AD6A54@yahoo.com> Date: Fri, 14 Sep 2018 19:16:15 -0700 Cc: Emmanuel Vadot , Marius Strobl Content-Transfer-Encoding: quoted-printable Message-Id: <9C3963A6-5786-4755-9C4F-6F75FFFFDEE5@yahoo.com> References: <6D375D5B-34E2-4124-9A32-92C320AD6A54@yahoo.com> To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 02:26:32 -0000 [I'm replacing the original hack with something that is less of one. But this is just investigatory, based on my limited testing context (just a Pine64+ 2GB) and lack of a general background in the source code and its criteria. Hopefully the material is of some use.] The following adjustments track the lack of wanting to support 1.8V because of other restrictions and so lead to the use of the e.MMC DDR52 using the range around 3V for the Pine64+ 2GB. (I expect A64 generality but have only one test context.) # svnlite diff /usr/src/sys//dev/mmc/ /usr/src/sys/arm/allwinner/ = = Index: = /usr/src/sys/dev/mmc/mmc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmc.c (revision 338675) +++ /usr/src/sys/dev/mmc/mmc.c (working copy) @@ -1814,10 +1814,10 @@ setbit(&ivar->timings, = bus_timing_mmc_ddr52); setbit(&ivar->vccq_120, = bus_timing_mmc_ddr52); } - if ((card_type & EXT_CSD_CARD_TYPE_DDR_52_1_8V) = !=3D 0 && - (host_caps & MMC_CAP_SIGNALING_180) !=3D 0) = { + if ((card_type & = EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V) !=3D 0) { setbit(&ivar->timings, = bus_timing_mmc_ddr52); - setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); + if ((host_caps & MMC_CAP_SIGNALING_180) = !=3D 0) + setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); } if ((card_type & EXT_CSD_CARD_TYPE_HS200_1_2V) = !=3D 0 && (host_caps & MMC_CAP_SIGNALING_120) !=3D 0) = { Index: /usr/src/sys/dev/mmc/mmcreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmcreg.h (revision 338675) +++ /usr/src/sys/dev/mmc/mmcreg.h (working copy) @@ -463,7 +463,7 @@ =20 #define EXT_CSD_CARD_TYPE_HS_26 0x0001 #define EXT_CSD_CARD_TYPE_HS_52 0x0002 -#define EXT_CSD_CARD_TYPE_DDR_52_1_8V 0x0004 +#define EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V 0x0004 #define EXT_CSD_CARD_TYPE_DDR_52_1_2V 0x0008 #define EXT_CSD_CARD_TYPE_HS200_1_8V 0x0010 #define EXT_CSD_CARD_TYPE_HS200_1_2V 0x0020 Index: /usr/src/sys/arm/allwinner/aw_mmc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/allwinner/aw_mmc.c (revision 338675) +++ /usr/src/sys/arm/allwinner/aw_mmc.c (working copy) @@ -509,7 +509,7 @@ MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | MMC_CAP_MMC_DDR52; =20 - sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330 | = MMC_CAP_SIGNALING_180; + sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330; // | = MMC_CAP_SIGNALING_180; not used on Pine64+ 2GB =20 if (bus_width >=3D 4) sc->aw_host.caps |=3D MMC_CAP_4_BIT_DATA; @@ -1308,17 +1308,20 @@ =20 sc =3D device_get_softc(bus); =20 - if (sc->aw_reg_vqmmc =3D=3D NULL) - return EOPNOTSUPP; - switch (sc->aw_host.ios.vccq) { case vccq_180: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; uvolt =3D 1800000; break; case vccq_330: + if (sc->aw_reg_vqmmc =3D=3D NULL) // implicitly already = stuck at vccq_330 + return 0; // avoid calling code treating the = assignment attempt as an error uvolt =3D 3300000; break; default: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; return EINVAL; } =20 The above is sufficient for the Pine64+ 2GB to boot and operate from the e.MMC on a microsd card adapter, using DDR52, without the prior hack being present. I can not claim to know enough to make sure the changes are fully general. MMC_CAP_SIGNALING_180 is/was used in the following places: # grep -r MMC_CAP_SIGNALING_180 /usr/src/sys/ /usr/src/sys/arm/allwinner/aw_mmc.c: sc->aw_host.caps |=3D = MMC_CAP_SIGNALING_330; // | MMC_CAP_SIGNALING_180; not used on Pine64+ = 2GB /usr/src/sys/dev/sdhci/sdhci.c: host_caps |=3D = MMC_CAP_SIGNALING_120 | MMC_CAP_SIGNALING_180; /usr/src/sys/dev/sdhci/sdhci.c: host_caps &=3D = ~(MMC_CAP_SIGNALING_120 | MMC_CAP_SIGNALING_180); /usr/src/sys/dev/sdhci/sdhci.c: (host_caps & = MMC_CAP_SIGNALING_180) ? " 1.8V" : "", /usr/src/sys/dev/sdhci/sdhci.c: if (!(slot->host.caps & = MMC_CAP_SIGNALING_180)) { /usr/src/sys/dev/mmc/mmc.c: if ((host_caps & = MMC_CAP_SIGNALING_180) !=3D 0) /usr/src/sys/dev/mmc/mmc.c: (host_caps & = MMC_CAP_SIGNALING_180) !=3D 0) { /usr/src/sys/dev/mmc/mmc.c: (host_caps & = MMC_CAP_SIGNALING_180) !=3D 0 && /usr/src/sys/dev/mmc/mmc.c: (host_caps & = MMC_CAP_SIGNALING_180) !=3D 0 && /usr/src/sys/dev/mmc/bridge.h:#define MMC_CAP_SIGNALING_180 (1 << = 19) /* Can do signaling at 1.8 V */ I've not done anything relative to the following, as in my limited test context I've not found a operational difference and I do not have the general background to work without such as a cross check. It seem that sdhci_init_slot is another area of source code that forces MMC_CAP_SIGNALING_180, this time for MMC_CAP_MMC_DDR52 use (and MMC_CAP_MMC_DDR52_180 use): /* Determine supported VCCQ signaling levels. */ host_caps |=3D MMC_CAP_SIGNALING_330; if (host_caps & (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_HS200_180 | MMC_CAP_MMC_HS400_180)) host_caps |=3D MMC_CAP_SIGNALING_120 | = MMC_CAP_SIGNALING_180; where MMC_CAP_MMC_DDR52 and MMC_CAP_MMC_DDR52 _180 are based on: /usr/src/sys/dev/mmc/bridge.h:#define MMC_CAP_MMC_DDR52_120 (1 << = 11) /* Can do eMMC DDR52 at 1.2 V */ /usr/src/sys/dev/mmc/bridge.h:#define MMC_CAP_MMC_DDR52_180 (1 << = 12) /* Can do eMMC DDR52 at 1.8 V */ /usr/src/sys/dev/mmc/bridge.h:#define MMC_CAP_MMC_DDR52 = (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180) (so MMC_CAP_MMC_DDR52 includes MMC_CAP_MMC_DDR52_180). Having e.MMC DDR52 only using the range around 3V does not seem to be = covered in sdhci_init_slot . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 15 05:22:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92A58109C8C5 for ; Sat, 15 Sep 2018 05:22:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C23F47F935 for ; Sat, 15 Sep 2018 05:22:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w8F58hwL065379 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Sep 2018 22:08:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w8F58hZA065378; Fri, 14 Sep 2018 22:08:43 -0700 (PDT) (envelope-from fbsd) Date: Fri, 14 Sep 2018 22:08:43 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180915050842.GA65045@www.zefox.net> References: <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 05:22:54 -0000 On Thu, Sep 06, 2018 at 10:32:50AM -0700, Mark Millard wrote: > > It appears to me that for the devices that you are currently using, > you are better off for elapsed time having the swap only on the > sdcard. > In practical terms this seems true. I set up a 16 GB Sandisk Ultra Plus microSD card with a single partition for / and 1.8 GB of swap at the end, running r338572 with vm.pageout_oom_seq="1024". It finished -j4 buildworld successfully but ran out of space in buildkernel. 32 GB would have been far more than sufficient. There were many spurious "indefinite wait" and a few "out of swap" warnings on the console, but nothing came of them. A faster microSD card might have avoided the warnings entirely, the Ultra Plus isn't the fastest horse in the stable. I neglected to salvage the buildworld timing, but it was under 24 hours. Aftr moving /usr/src to a separate USB3.0 flash drive I repeated that test, adding experiments with swap on the same USB flash drive and swap on a second USB flash drive. All the tests succeeded, none sufficiently faster to justify the expense and complication of a second storage device. The log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r338572/ if anybody's interested. It might make sense to divide storage to protect valuable data from wearout, but I've not seen any evidence (knock on wood!) that wearout of flash media is a serious problem with the Pi. Setting up a physical swap partition by hand at the end of the microSD card is fairly difficult. If it could be automated through the machinery invoked by /firstboot that would be a useful feature. Thanks to all (Mark especially) for reading and guiding! bob prohaska From owner-freebsd-arm@freebsd.org Sat Sep 15 06:26:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF6BB109DC38 for ; Sat, 15 Sep 2018 06:26:34 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 082A0814C8 for ; Sat, 15 Sep 2018 06:26:33 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w8F6I5OS004071 for ; Sat, 15 Sep 2018 16:18:06 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) To: freebsd-arm@freebsd.org References: <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> <20180915050842.GA65045@www.zefox.net> From: Trev Message-ID: <8fd79c5e-4998-274a-6457-ac2a6bf939bb@sentry.org> Date: Sat, 15 Sep 2018 16:18:05 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20180915050842.GA65045@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sat, 15 Sep 2018 16:18:06 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 06:26:35 -0000 bob prohaska wrote on 15/09/2018 15:08: > There were many spurious "indefinite wait" and [...] warnings on the console, Those warnings are not actually spurious, rather indicative of significant i/o delays: https://www.freebsd.org/doc/en/books/faq/troubleshoot.html#idp59131080 What does the error swap_pager: indefinite wait buffer: mean? This means that a process is trying to page memory to disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is bad, disk errors will appear in /var/log/messages and in the output of dmesg. Otherwise, check the cables and connections. From owner-freebsd-arm@freebsd.org Sat Sep 15 07:11:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 316AB109EAE7 for ; Sat, 15 Sep 2018 07:11:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.ne1.yahoo.com (sonic305-20.consmr.mail.ne1.yahoo.com [66.163.185.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B934882462 for ; Sat, 15 Sep 2018 07:11:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: el9r4LgVM1kWQ_MPq6bxXKSfYmViTlJJvEm_qapiL4mEM8kydPRQiF_ZVsaO3Re LMdthfGa228BY7fRKeXSmjEUF0aWQWDcT2OzmGyIYSgqguzgAAAQUf4Gpfy0mDdMXmzOmcxoTHvw egRWy4v4BgVo2znVZi1zgnxbJkXgJrbVUNZk_kg7kRtAX3v87v1YAFTwZhTZbTPCz1ZyEhwi388j Hy1x4g8qP5nALC1hc6q7ApzNlt5j1VxMT9GLcGzh3Uf9gNlU8moI5DEkw.AmKz368uavoUKe3gFG 1o_mNOHUzM1g7r71obhoP2.CFgbgdpcJW98owmVC6cx9bzddLKnzHXrTyjX92ZXPox1R2Q2Cl0se lmVVlOUvOyF0mr4EAtrDaRn2FYz5a52hdx5tpDy51G2lX.uhQS67MOTr0KwsU2bu02QEjQKpgrJl GSK2uA59xybKK5sp.pmnTpjO3YRmlOHgbPDt7my_lirU47xqUd9zS2Ft5ost3_ZK7ab2PUEHFMNi Q1SY422vkwhzmIxAEmCDr8ynOphkINyXam_nziIBVGr4YIgNhC8P03Jkh3E64zH3t2n30MZr6uYa oQUVQs_yf.9swoW1vd.MucFIUBGu8mnA.BpCna.8QkJW1CVpkaM1quk9Je.6_xo990rtFafj0ytz 2FMyZTk_OvOb4OYZblaMLs895Y973VuxKALM4OVXX06dYAz87tWJdZQgyEd4xDeYsVtCyEvFeI5r 5h3WuaAUgMQPlHoXW.7evi7q2RW8vsy3M86f_QRtyuVaNU9jX.iOHU5E35fJn2Z8dl_k9Uf2SMns JOrCJzpdGSiUaEAtnGJ.EKQyl51UkyJDwuFPbFuty31xcvMchpFfz1Jg1sJHAVMPoeNxxNITSkF2 9VRMEB.4g3XPI4obWxtsNHXMhvEGAUDX0_MJuGLpqVMoWDwlRdGY0hDeSu_Vv2nkSLbSTN7TY3eZ zzdEf4UWbcdL7oVGYnN2DkCsK1kaiBnK2DVtXw.NvKbxnIXJFQxYfoMwBeDjP3i8JNZzz1UMEaR2 3Y_W_bd.5IUD5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sat, 15 Sep 2018 07:11:54 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp401.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 607b1e7c1fa3793bcacf7adff1a3cf55; Sat, 15 Sep 2018 07:11:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <8fd79c5e-4998-274a-6457-ac2a6bf939bb@sentry.org> Date: Sat, 15 Sep 2018 00:11:48 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> <20180915050842.GA65045@www.zefox.net> <8fd79c5e-4998-274a-6457-ac2a6bf939bb@sentry.org> To: Trev X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 07:11:56 -0000 On 2018-Sep-14, at 11:18 PM, Trev wrote: > bob prohaska wrote on 15/09/2018 15:08: >> There were many spurious "indefinite wait" and [...] warnings on the = console, [Bob did not say if he had Mark Johnston's reporting patches in place or not.] > Those warnings are not actually spurious, rather indicative of = significant i/o delays: >=20 > https://www.freebsd.org/doc/en/books/faq/troubleshoot.html#idp59131080 >=20 > What does the error swap_pager: indefinite wait buffer: mean? >=20 > This means that a process is trying to page memory to disk, and the = page attempt has hung trying to access the disk for more than 20 = seconds. It might be caused by bad blocks on the disk drive, disk = wiring, cables, or any other disk I/O-related hardware. If the drive = itself is bad, disk errors will appear in /var/log/messages and in the = output of dmesg. Otherwise, check the cables and connections. =46rom what I can see from: http://www.zefox.net/~fbsd/rpi3/swaptests/r338572/1.8gbsd/swapscript.log no I/O errors were reported. ("swap_pager: indefinite wait buffer:" messages do show.) microsd card slots do not have cables or cable-connections involved generally: what would be analogous would be far harder to do anything about. =46rom what I've seen the I/O for the paging (mixed with the other I/O activity) can potentially queue enough data to be paged out that, under normal operation, the microsd card would take more than 20 seconds to write it all out. Say, 10 MiBytes/sec * 20 sec =3D 200 MiByte, to give ball park figures that likely are on the large side as I understand. (Paging is not sequential and reads/writes are mixed.) So if the time waiting in the queue of pending I/O is counted in that 20 seconds for the data in question, that alone might lead to message for the data that is far from the front of the queue when it is first added, no errors involved. But, that is an "if": I do not know just what starts the 20 second measurement. It looks like the distinct swap_pager messages for the ultra plus only example were: $ grep swap_pager: ~/Downloads/swapscript_rpi3_ultra_plus.log | sort | = uniq Sep 11 07:12:52 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 88445, size: 4096 Sep 11 07:13:01 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 464452, size: 12288 Sep 11 07:13:56 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 11922, size: 4096 Sep 11 11:34:08 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 295286, size: 8192 Sep 11 11:34:08 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 371269, size: 4096 Sep 11 12:48:23 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 408974, size: 4096 Sep 11 13:09:07 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 293166, size: 8192 Sep 11 13:10:19 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 226334, size: 8192 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 15 08:08:35 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE51F109FAFB for ; Sat, 15 Sep 2018 08:08:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4903883A11 for ; Sat, 15 Sep 2018 08:08:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MAN6k_AVM1kmbWGP8uUswX_doXPkQsqp7OOYB9DPVdCS9ib8Lye4IS_2lwPCzJW ZVDs_olqK2GYoNx.GWTP0bZil70J_pJLjPBdU6u6BMVqNON7A_Ym_keO3OWi_GLFN1EkMDu2lZA0 r7yC76dkh8GdZkEMMC2HRc8iGPiZ6LwFVPuYPWWXWSi21ywOvf3hl0ONiyxYUIMUlK1h_yqcleiI OneUxy2GNBQe0f.cGr9I8_d87c9fP5mr4JUOCKMA6Nc1VbIWvern9MCDbetkxEFQnBav6nXv9KpZ 6TtyDhcdNq_LnKlHGfXZd4x61UkDB0fcZ_Bee.R1x5fJ8J43az.9F7Hkxrx2xbf5Y90A1pTK27Xa KWqkziT7NaAvcyCilQnIyvOB9DSggTZnEjky2rlH8Exv7JC1HMAVMd15hM9tupFE8dF__FQa6Eay zTaX48UVE5zbsGK.O0Of_0f6bIMupemdw8yR5SOIOz7IPqUFN3vW0fqgJzpIhfWZWCxgSLls_KyJ 7VKAdeBXCKnxjTXNGbTEGOVNeZuLeFbXnu7d.1Y2DV_Yo4NA.QDwMzv5b1OQ.IEuRmX8A9mdDUzw uPYXRSMYSj84WtE7zgZbrssd0mDiDhu0V6Euj7D1O3TOJdjb1BEL6.KaBz.HQb55v28fR84wp07R HZe4jnmAdIa5FKq4wf1PfFZpd87tJ4_oBZLdxRcEL7kzGN6bkmiEH667bScEINDU8GqhNM5r_p3b clJHaK.9pN1jO_gRiKpRSDUf4aQ07RJpE6hNAsN0cka1USuHpuBzsNWGdiXuuEHApHvwuVldk6y3 ImorrNQiJ84ba53nyXgPKLkV.3gilrIydpWagAK4ELbsRUWfWZlB0jI4KbIAaDu_G8OU0F4YcDoZ XPFvZ_3LZF0_VsC3dcxl.H0MkiALNs.uyXzBE32.T17eRy4pm35W3.ATr84sHxWqp_nx3xVALZmh 55yUSnJfWMxRZCuUABdnSxawKPYRQM.IuW3UVZ8TXIJfCXZbwGqRT8m4FuXms_5Xx1ui5XrAVWiS tyEMFKrYp Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Sep 2018 08:08:28 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1e64cad8386f9741debd7e8214fa78de; Sat, 15 Sep 2018 08:08:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180915050842.GA65045@www.zefox.net> Date: Sat, 15 Sep 2018 01:08:22 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> <20180915050842.GA65045@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 08:08:36 -0000 On 2018-Sep-14, at 10:08 PM, bob prohaska wrote: > On Thu, Sep 06, 2018 at 10:32:50AM -0700, Mark Millard wrote: >>=20 >> It appears to me that for the devices that you are currently using, >> you are better off for elapsed time having the swap only on the >> sdcard. >>=20 > In practical terms this seems true. I set up a 16 GB Sandisk Ultra > Plus microSD card with a single partition for / and 1.8 GB of swap=20 > at the end, running r338572 with vm.pageout_oom_seq=3D"1024". It = finished=20 > -j4 buildworld successfully but ran out of space in buildkernel. 32=20 > GB would have been far more than sufficient. I build with debug symbols but with optimizations still enabled. The last time I built on 32 GByte media the buildworld/buildkernel tree was: # du -sm /mnt/usr/obj/* 11024 /mnt/usr/obj/cortexA53_clang With ports builds and installs and the like to do I found 32 GByte not being big enough: # du -sm /mnt/usr/* 518 /mnt/usr/bin 1 /mnt/usr/home 25 /mnt/usr/include 2241 /mnt/usr/lib 1 /mnt/usr/libdata 13 /mnt/usr/libexec 2949 /mnt/usr/local 11024 /mnt/usr/obj 2423 /mnt/usr/ports 58 /mnt/usr/sbin 106 /mnt/usr/share 3968 /mnt/usr/src 145 /mnt/usr/tests 19 /mnt/usr/typescripts So just /usr totaled to: # du -sm /mnt/usr 23484 /mnt/usr # df -m /dev/da4s2a=20 Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/da4s2a 29400 23966 3082 89% /mnt I had the swap on another device. I also do not expect nearly full flash media to perform well, instead preferring to have lots of free space of some form, for example instead using 128 MByte media (that does have swap on it): # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/label/PINE64P2Groot 109101 38396 61976 38% / > There were many spurious > "indefinite wait" It looks like the distinct swap_pager messages for the ultra plus only example were (for those recorded in swapscript.log anyway): $ grep swap_pager: ~/Downloads/swapscript_rpi3_ultra_plus.log | sort | = uniq Sep 11 07:12:52 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 88445, size: 4096 Sep 11 07:13:01 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 464452, size: 12288 Sep 11 07:13:56 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 11922, size: 4096 Sep 11 11:34:08 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 295286, size: 8192 Sep 11 11:34:08 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 371269, size: 4096 Sep 11 12:48:23 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 408974, size: 4096 Sep 11 13:09:07 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 293166, size: 8192 Sep 11 13:10:19 www kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 226334, size: 8192 > and a few "out of swap" warnings on the console, I do see one swap_pager_getswapspace in the swapscript.log (original name): $ grep "swap" ~/Downloads/swapscript_rpi3_ultra_plus.log | sort | uniq Sep 11 04:34:35 www kernel: swap_pager_getswapspace(32): failed . . . But I do not find "out of swap". I do not see examples of I/O error reports. > but nothing came of them. A faster microSD card might have avoided > the warnings entirely, the Ultra Plus isn't the fastest horse in the > stable.=20 I do not know what mode of use the microsd card was used in. That likely would be reported in "boot -v" output. A point that might contribute is if the microsd cards have application class A1 (or A2) or not. Paging is not sequential I/O of just one type. > I neglected to salvage the buildworld timing, but it was under 24 = hours. The log file shows: World build started on Mon Sep 10 14:55:38 PDT 2018 . . . World build completed on Tue Sep 11 13:14:12 PDT 2018 So somewhat under 22 hours and 20 minutes. > Aftr moving /usr/src to a separate USB3.0 flash drive I repeated that > test, adding experiments with swap on the same USB flash drive and > swap on a second USB flash drive. All the tests succeeded, none=20 > sufficiently faster to justify the expense and complication of =20 > a second storage device. >=20 > The log files are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r338572/ > if anybody's interested. >=20 > It might make sense to divide storage to protect valuable data=20 > from wearout, but I've not seen any evidence (knock on wood!) > that wearout of flash media is a serious problem with the Pi. >=20 > Setting up a physical swap partition by hand at the end of the > microSD card is fairly difficult. If it could be automated through > the machinery invoked by /firstboot that would be a useful feature. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)