From owner-freebsd-current@freebsd.org Sun Apr 1 02:31:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6165F73ECF for ; Sun, 1 Apr 2018 02:31:23 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D899839B1 for ; Sun, 1 Apr 2018 02:31:23 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: jRZ_IbEVM1mDE7zogIS1ClFi8g78erpD2dFpwa6gP8Uznf4RplOCtsONZZwJaEK jQ0p6_CTTc.Pz4i_WmY26YiinQsQlfn9Hy0GOwNoW9KEXblTjY_tl4vXilcqNFmc0b0OVY0XF4.d ESuv2fb2Dne6zX.PhheYoW4Duayb6Ab6m7nNPfpzfN83idSyugj4tSHxcxcEdacA0LrKpHy6Ab0Q Tx6lTbqUycKf6kVFGs184wvUz8OJ3Zvr4KWKM1HS66IsHqGw0k1vIhsH0piEDR79yxK7PMVQrXw3 hdiKwkicI.5xXFmPCwlb4onj5fFreo5WfoNLcx8KRhPu4CGPoD1T0D81iFyBrhKLY14WriANYtKF Qf9WnbdPmlR_J6XeBHVCphXC8VEo.xACJze8iM7MOVwwjDuTFsjM3t9o3oI9cQjeiBmcGUZopfNf ommP1RbEJOn9Ih9l0jaB5YpKRK1tW4qnaTc_wdsm8.ogHmkAi3.mt.LB3fELNHW6pOnH3DtMH04G _aVcDNI.wFTtWxzANpPf9tQd36ogNFLDL9OT6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sun, 1 Apr 2018 02:31:17 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7b8b6710b224f1a999599491619c0e43; Sun, 01 Apr 2018 02:31:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT From: Mark Millard In-Reply-To: Date: Sat, 31 Mar 2018 19:31:13 -0700 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20180317103915.081ca2dd@thor.intern.walstatt.dynvpn.de> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 02:31:24 -0000 On 2018-Mar-17, at 11:26 AM, Andriy Gapon wrote: > On 17/03/2018 18:51, Mark Millard wrote: >> I'll note that top was a -w that reports: >> >> -w Display approximate swap usage for each process. > > As far as I can tell, this option is quite broken. > The "approximate swap usage" it reports is nowhere like it. I have a hypothesis for part of what top is counting in the process/thread SWAP column that might not be what one would expect. It appears to me that vnode-backed pages are being re-classfied sometimes for inactive processes, and this classification leads to top classifying the pages as not-resident but swapped (in that a "VN PAGER in" would be required, in systat -vmstat terms). Supporting details, if you care, otherwise skip the below: The hypothesis is from observing various hours of over 20 hours of poudriere-devel "bulk -a" activity, for which, at that point: vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_vnodepgsout: 6996 vm.stats.vm.v_vnodepgsin: 32641833 vm.stats.vm.v_vnodeout: 1030 vm.stats.vm.v_vnodein: 4305027 Sometimes top showed lots of wait/select/pause and such with positive SWAP and (mostly) 0K RES. Most of the processes were in the "wait" STATE. At other times, more like between 1 and 2 dozen had positive SWAP. There would be sudden large jumps in the number of such processes. Then over time it would decrease as the processes quit waiting (children process trees finished). The large jumps were not tied to Free becoming small or anything else obvious from what I was looking at. But the Free figure would increase at that time. For example, I recently saw such a large jump that was associated with Free increasing from "90G" as shown in top. (Much of the time there were between, say, 170 and 300 sleeping processes.) The context was under Hyper-V with 29 logical processors assigned to FreeBSD on a machine with 16 cores/32 threads and 114 GiBytes of RAM assigned to FreeBSD (of 128 GiBytes) and 256 GiBytes of swap-partition set up. PARALLEL_JOBS allowed the 29 and ALLOW_MAKE_JOBS was in use (allowing a potential for 29*29=841 or so running processes via poudriere bulk). For reference: at 25 hours-in [idle] had 148.3H (around 20% of the 29 threads * 25 H/thread) and [bufdaemon] had 48.9H (around 6.7%). [kernel] showed around 13.6H (817 min converted) and [pagedaemon] showed around 1.7H (101 min converted). Other processes had less TIME than any of these. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Apr 1 07:05:23 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B42D3F54CCF for ; Sun, 1 Apr 2018 07:05:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D662E77D1C for ; Sun, 1 Apr 2018 07:05:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 9AFD5F54CC9; Sun, 1 Apr 2018 07:05:22 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60BE8F54CC7; Sun, 1 Apr 2018 07:05:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id A291F77CF6; Sun, 1 Apr 2018 07:05:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 6BE09D4ECD3; Sun, 1 Apr 2018 17:05:06 +1000 (AEST) Date: Sun, 1 Apr 2018 17:05:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric cc: Konstantin Belousov , current@FreeBSD.org, amd64@FreeBSD.org Subject: Re: i386 4/4 change In-Reply-To: <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> Message-ID: <20180401151124.G893@besplex.bde.org> References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=6I5d2MoRAAAA:8 a=RRKNnNHb0Om-JY6aZ2kA:9 a=HfVbGaZjtTc9tSMn:21 a=VRhFOslev4N6E7P5:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Mailman-Approved-At: Sun, 01 Apr 2018 10:41:24 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 07:05:23 -0000 On Sun, 1 Apr 2018, Dimitry Andric wrote: > On 31 Mar 2018, at 17:57, Bruce Evans wrote: >> >> On Sat, 31 Mar 2018, Konstantin Belousov wrote: >> >>> the change to provide full 4G of address space for both kernel and >>> user on i386 is ready to land. The motivation for the work was to both >>> mitigate Meltdown on i386, and to give more breazing space for still >>> used 32bit architecture. The patch was tested by Peter Holm, and I am >>> satisfied with the code. >>> >>> If you use i386 with HEAD, I recommend you to apply the patch from >>> https://reviews.freebsd.org/D14633 >>> and report any regressions before the commit, not after. Unless >>> a significant issue is reported, I plan to commit the change somewhere >>> at Wed/Thu next week. >>> >>> Also I welcome patch comments and reviews. >> >> It crashes at boot time in getmemsize() unless booted with loader which >> I don't want to use. > For me, it at least compiles and boots OK, but I'm one of those crazy > people who use the default boot loader. ;) I found a quick fix and sent it to kib. (2 crashes in vm86 code for memory sizing. This is not called if loader is used && the system has smap. Old systems don't have smap, so they crash even if loader is used.) > I haven't yet run any performance tests, I'll try building world and a > few large ports tomorrow. General operation from the command line does > not feel "sluggish" in any way, however. Further performance tests: - reading /dev/zero using tinygrams is 6 times slower - read/write of a pipe using tinygrams is 25 times slower. It also gives unexpected values in wait statuses on exit, hopefully just because the bug is in the test program is exposed by the changed timing (but later it also gave SIGBUS errors). This does a context switch or 2 for every read/write. It now runs 7 times slower using 2 4.GHz CPUs than in FreeBSD-5 using 1 2.0 GHz CPU. The faster CPUs and 2 of them used to make it run 4 times faster. It shows another slowdown since FreeBSD-5, and much larger slowdowns since FreeBSD-1: 1996 FreeBSD on P1 133MHz: 72k/s 1997 FreeBSD on P1 133MHz: 44k/s (after dyson's opts for large sizes) 1997 Linux on P1 133MHz: 93k/s (simpler is faster for small sizes) 1999 FreeBSD on K6 266MHz: 129k/s 2018 FBSD-~5 on AthXP 2GHz: 696k/s 2018 FreeBSD on i7 2x4GHz: 2900k/s 2018 FBSD4+4 on i7 2x4GHz: 113k/s (faster than Linux on a P1 133MHz!!) Netblast to localhost has much the same 6 times slowness as reading /dev/zero using tinygrams. This is the slowdown for syscalls. Tinygrams are hard to avoid for UDP. Even 1500 bytes is a tinygram for /dev/zero. Without 4+4, localhost is very slow because it does a context switch or 2 for every packet (even with 2 CPUs when there is no need to switch). Without 4+4 this used to cost much the same as the context switches for the pipe benchmark. Now it costs relatively much less since (for netblast to localhost) all of the context switches are between kernel threads. The pipe benchmark uses select() to avoid busy-waiting. That was good for UP. But for SMP with just 2 CPUs, it is better to busy-wait and poll in the reader and writer. netblast already uses busy-waiting. It used to be a bug that select() doesn't work on sockets, at least for UDP, so blasting using busy-waiting is the only possible method (timeouts are usually too coarse-grained to go as fast as blasting, and if they are fine-grained enough to go fast then they are not much better than busy-waiting with time wasted for setting up timeouts). SMP makes this a feature. It forces use of busy- waiting, which is best if you have a CPU free to run it and this method doesn't take to much power. Context switches to task queues give similar slowness. This won't be affected by 4+4 since task queues are in the kernel. I don't like networking in userland since it has large syscall and context switch costs. Increasing these by factors of 6 and 25 doesn't help. It can only be better by combining i/o in a way that the kernel neglects to do or which is imposed by per-packet APIs. Slowdown factors of 6 or 25 require the combined i/o to be 6 or 25 larger to amortise the costs. Bruce From owner-freebsd-current@freebsd.org Sun Apr 1 13:19:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C75AF9977B for ; Sun, 1 Apr 2018 13:19:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 799A76B40B; Sun, 1 Apr 2018 13:19:16 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-70-98.dz.commufa.jp [124.18.70.98]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w31CcWAL041402; Sun, 1 Apr 2018 21:38:33 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 1 Apr 2018 21:38:31 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: kevans@freebsd.org Subject: Re: Call for Testing: UEFI Changes Message-Id: <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 13:19:17 -0000 Confirmed both loader (with boot1) part and efirt.ko part. Working OK on my ThinkPad420 (with nvidia GPU) at r331864. No benefit (VGA resolution) but no new harm (no panic nor silent reboot). *Maybe gracefully falling back to mode 0. As I'm on x11/nvidia-driver, completely no test is done with drm-next. One more to mention. I've cherry-picked r330868, r331241 and r331361 on stable/11 after r331114, amd64 and works OK as on head. Additional cherry-picking of r331365 is OK, too. Without r330868, my ThinkPad silently reboots within about 10-60 minutes range, maybe by actual access to UEFI RS. With r331241 without r331361 causes instant panic on loading efirt.ko. So all 3 (4) revs should be MFC'ed together. Sorry for delay. On Thu, 22 Mar 2018 10:34:33 -0500 Kyle Evans wrote: > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote: > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote: > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > >>> Hi. > >>> For problem 2, try reverting r331241 alone. > >>> This worked for my ThinkPad T420. > >> > >> > >> I also hit this after updating to latest and was about to post when I > >> saw this thread - > >> > >> I build efirt into the kernel and it's now doing a panic on boot. It > >> appears to be due to this recent addition in dev/efidev/efirt.c by r331241: > >> > >>> if (!efi_is_in_map(map, efihdr->memory_size / efihdr->descriptor_size, > >>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) { > >> > >> The faulting address is for "efi_runtime->rt_gettime" (and is still a > >> phys addr here). > >> > > > > The following patch [1] (I can't guarantee how long he'll keep it > > available there) should fix this class of problems. > > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-EFI-environment-before-check-the-GetT.patch > > Now committed as of r331361. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Apr 1 15:23:23 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64B6DF5470C for ; Sun, 1 Apr 2018 15:23:23 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5C9370E25 for ; Sun, 1 Apr 2018 15:23:22 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd23.aul.t-online.de (fwd23.aul.t-online.de [172.20.26.128]) by mailout05.t-online.de (Postfix) with SMTP id 03AB742171B0 for ; Sun, 1 Apr 2018 17:18:08 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (ZG32sYZEwhad9JPWy8eNPc5mbXFzgg8tzDq13YedibP6ER4LarYRTek7Lr5GOW0gX0@[84.154.109.148]) by fwd23.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f2ek9-1PWmBc0; Sun, 1 Apr 2018 17:18:05 +0200 To: FreeBSD Current From: Stefan Esser Subject: Extremely low disk throughput under high compute load Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Message-ID: Date: Sun, 1 Apr 2018 17:18:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: ZG32sYZEwhad9JPWy8eNPc5mbXFzgg8tzDq13YedibP6ER4LarYRTek7Lr5GOW0gX0 X-TOI-MSGID: e2b012b9-9b2d-4f36-9b00-0c8868fa04d4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 15:23:23 -0000 My i7-2600K based system with 24 GB RAM was in the midst of a buildworld -j8 (starting from a clean state) which caused a load average of 12 for more than 1 hour, when I decided to move a directory structure holding some 10 GB to its own ZFS file system. File sizes varied, but were mostly in the range 0f 500KB. I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus there was nearly no disk activity caused by the buildworld. The copying proceeded at a rate of at most 10 MB/s, but most of the time less than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus a much better priority than the compute bound compiler processes, but it got just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled at such a low rate, that it only managed to issue a few controller writes per second. The system is healthy and does not show any problems or anomalies under normal use (e.g., file copies are fast, without the high compute load). This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging. Is this a regression in -CURRENT? Regards, STefan From owner-freebsd-current@freebsd.org Sun Apr 1 16:33:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6AC3F6BBF2 for ; Sun, 1 Apr 2018 16:33:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8320C73881 for ; Sun, 1 Apr 2018 16:33:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id d7so15655712ioc.11 for ; Sun, 01 Apr 2018 09:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IEtnYDlLaO2bRDi87Wl8zM94lejg2GmXwvblf8vwD1Y=; b=IcB5iz68xI6PFUXoC2bQYjkdOlzZvm2LMrKdecC47PEgTe1hLtx+nAdvF+YQ6NqROd kbTbO9XAN9FyrvoZemK0txCDY5RJLB0Yu228G8K6zui+w2I8ua8Puga01zP3pWSSKhUU rMCHKm6n2dSy38KaNK4r/OFPwHE5q3Cp+xdoEzauTQH25fIKDpWG1KPZi1iRQa2jejIq QczEnDAeUdtggVUnWEc0oxYe4ylusZYcJdVT4sAoY2p2iEMDHyRMYxrb4aCBlfKZxdS8 s+BGQThdffvZZLTw3dWgFFAolXLTZIhfjc+oTH5anFwup0updPLUmqXrXNVvCezMY74+ pHDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IEtnYDlLaO2bRDi87Wl8zM94lejg2GmXwvblf8vwD1Y=; b=VefLKAid+47NYXtgo54Nbk43udZXJARkEqvZoreg0gpARk7BCltThQbNDeeVzp2Dc8 LXs7ywPxjnzuvPXt7MgNUtDYQWqDgwaIGpJWlCwFlGQgwXswZVEvevrFvTh47BApr3bM XocxQBDUwyGCIxm4u/YKlPbAu+XaX1Cdy+m9aZ+Kg+DDR1odbRoQEiQed2I/FbktDWgk WuK0uqa4wOWmSmIrwRRKr4wB1X7aJbhkvceyATSVoR1DKeraVUfCGkh98LiKobt4AAv1 PWLOA0XmybxCurLbuGlTpigF1tuN0sl9iaUZQyCF3qljk3e1jHUwQ52vRJ4JS5ZuiodR lOBQ== X-Gm-Message-State: ALQs6tDf7d90Drl81jLWxQG5zNUdh1fCNyX6eSMM0yLNnwLcM0fs7/K6 tVr5vCwuAPBJslB81C+8YQUlDoq5H17TGfYNVhdIvQ== X-Google-Smtp-Source: AIpwx4+I9VigJ1Z6XcN14QnbFCSNLkJQvcwk8xhMSspc1lRrqs4MKUT+VbLg4xBNN3RjH1/1JXJTN9QQoUMiuU5/TWk= X-Received: by 10.107.162.146 with SMTP id l140mr5499256ioe.39.1522600435488; Sun, 01 Apr 2018 09:33:55 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Sun, 1 Apr 2018 09:33:54 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sun, 1 Apr 2018 10:33:54 -0600 X-Google-Sender-Auth: iiJYRfyjdqkdg1KRTJfzG2R9Fio Message-ID: Subject: Re: Extremely low disk throughput under high compute load To: Stefan Esser Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 16:33:57 -0000 On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser wrote: > My i7-2600K based system with 24 GB RAM was in the midst of a buildworld > -j8 > (starting from a clean state) which caused a load average of 12 for more > than > 1 hour, when I decided to move a directory structure holding some 10 GB to > its > own ZFS file system. File sizes varied, but were mostly in the range 0f > 500KB. > > I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus > there > was nearly no disk activity caused by the buildworld. > > The copying proceeded at a rate of at most 10 MB/s, but most of the time > less > than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus > a > much better priority than the compute bound compiler processes, but it got > just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled > at such a low rate, that it only managed to issue a few controller writes > per > second. > > The system is healthy and does not show any problems or anomalies under > normal use (e.g., file copies are fast, without the high compute load). > > This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging. > > Is this a regression in -CURRENT? > Does 'sync' push a lot of I/O to the disk? Is the effective throughput of CP tiny or large? It's tiny, if I read right, and the I/O is slow (as opposed to it all buffering in memory and being slow to drain own), right? Warner From owner-freebsd-current@freebsd.org Sun Apr 1 17:08:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A6B4F6E3C0 for ; Sun, 1 Apr 2018 17:08:35 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from pmta31.teksavvy.com (pmta31.teksavvy.com [76.10.157.38]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "*.teksavvy.com", Issuer "DigiCert SHA2 High Assurance Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DE707509F for ; Sun, 1 Apr 2018 17:08:34 +0000 (UTC) (envelope-from 482254ac@razorfever.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EXCQCREcFa/0StpUVdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYINgTUpO2yEBIhejCMBSAEBBQGBHwQxAV2SU4F6C4UEAoQlIjU?= =?us-ascii?q?XAQIBAQEBAQECA2goQgwBhFcBBSMPAQUeMwsYAgImAgI5HhMIAQGEfA2uYYIci?= =?us-ascii?q?DqCKxN2h2SBB4EugmKFO4I0glQClzoHAQKOJoEoDoNZgigPhHeHJohLDIElHgI?= =?us-ascii?q?1gVIfXIMIkGgjhlqHVgEB?= X-IPAS-Result: =?us-ascii?q?A2EXCQCREcFa/0StpUVdGQEBAQEBAQEBAQEBAQcBAQEBAYI?= =?us-ascii?q?NgTUpO2yEBIhejCMBSAEBBQGBHwQxAV2SU4F6C4UEAoQlIjUXAQIBAQEBAQECA?= =?us-ascii?q?2goQgwBhFcBBSMPAQUeMwsYAgImAgI5HhMIAQGEfA2uYYIciDqCKxN2h2SBB4E?= =?us-ascii?q?ugmKFO4I0glQClzoHAQKOJoEoDoNZgigPhHeHJohLDIElHgI1gVIfXIMIkGgjh?= =?us-ascii?q?lqHVgEB?= X-IronPort-AV: E=Sophos;i="5.48,391,1517893200"; d="scan'208";a="25718312" Received: from 69-165-173-68.dsl.teksavvy.com (HELO mail.razorfever.net) ([69.165.173.68]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2018 13:08:32 -0400 Received: from [127.0.0.1] (mail.razorfever.net [192.168.0.4]) by mail.razorfever.net (8.15.2/8.14.9) with ESMTP id w31H8WlY065960 for ; Sun, 1 Apr 2018 13:08:32 -0400 (EDT) (envelope-from 482254ac@razorfever.net) X-Authentication-Warning: mail.razorfever.net: Host mail.razorfever.net [192.168.0.4] claimed to be [127.0.0.1] Subject: Re: freebsd-update: to a specific patch level - help please? [PATCH] From: "Derek (freebsd lists)" <482254ac@razorfever.net> To: freebsd-current@freebsd.org References: <20180323104437.GB21001@home.opsec.eu> <8b80e639-b5a5-111e-aaf3-07952b2d57d1@chezmarcotte.ca> Message-ID: <8c9173dc-8d72-ee08-2ecc-396988d9b2fe@razorfever.net> Date: Sun, 1 Apr 2018 13:08:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8b80e639-b5a5-111e-aaf3-07952b2d57d1@chezmarcotte.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, FROM_STARTS_WITH_NUMS,RP_MATCHES_RCVD autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.razorfever.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 17:08:35 -0000 On 18-03-24 10:26 AM, Derek wrote: > On 18-03-23 06:44 AM, Kurt Jaeger wrote: >>> To be clear, *I've included a link to a patch to freebsd-update >>> in my initial post, and the help I'm looking for: is to get this >>> functionality added as a feature so others can benefit.*  It >>> works for me already, and I've already benefited. >> >> Please submit this in a PR, and post the PR number here, I'll >> work to >> get this in the tree. >> > > PR is 226893 > FYI - Just awaiting any kind of feedback on the PC. Won't be starting anything until then. Derek From owner-freebsd-current@freebsd.org Sun Apr 1 19:53:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7478F77B37 for ; Sun, 1 Apr 2018 19:53:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66C3B7AD60; Sun, 1 Apr 2018 19:53:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w31Jsq6n062352 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 1 Apr 2018 19:54:54 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w31JrbMN022352 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2018 12:53:38 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Sun, 1 Apr 2018 12:53:32 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Andriy Gapon cc: Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> Message-ID: References: <20180306173455.oacyqlbib4sbafqd@ler-imac.lerctr.org> <201803061816.w26IGaW5050053@pdx.rh.CN85.dnsmgr.net> <20180306193645.vv3ogqrhauivf2tr@ler-imac.lerctr.org> <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 19:53:49 -0000 On 27 Mar, Andriy Gapon wrote: > On 24/03/2018 01:21, Bryan Drewery wrote: >> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>> >>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >>>> Also, if you could try going back to r328953 or r326346 and let me know if >>>> the problem exists in either. That would be very helpful. If anyone is >>>> willing to debug this with me contact me directly and I will send some >>>> test patches or debugging info after you have done the above steps. >>> >>> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). >>> I initially got around the problem by reverting that commit but either >>> it or something very similar is still present in 11-stable r331053. >>> >>> I've seen it in my main server (32GB RAM) but haven't managed to reproduce >>> it in smaller VBox guests - one difficulty I faced was artificially filling >>> ARC. > > First, it looks like maybe several different issues are being discussed and > possibly conflated in this thread. I see reports related to ZFS, I see reports > where ZFS is not used at all. Some people report problems that appeared very > recently while others chime in with "yes, yes, I've always had this problem". > This does not help to differentiate between problems and to analyze them. > >> Looking at the ARC change you referred to from r325851 >> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure >> is completely broken. > > Does your being convinced come from the code review or from experiments? > If the former, could you please share your analysis? > >> On my 78GB RAM system with ARC limited to 40GB and >> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I >> can get swap up near 50GB and yet the ARC remains at 40GB through it >> all. It's always been slow to give up memory for package builds but it >> really seems broken right now. > > Well, there are multiple angles. Maybe it's ARC that does not react properly, > or maybe it's not being asked properly. > > It would be useful to monitor the system during its transition to the state that > you reported. There are some interesting DTrace probes in ARC, specifically > arc-available_memory and arc-needfree are first that come to mind. Their > parameters and how frequently they are called are of interest. VM parameters > could be of interest as well. > > A rant. > > Basically, posting some numbers and jumping to conclusions does not help at all. > Monitoring, graphing, etc does help. > ARC is a complex dynamic system. > VM (pagedaemon, UMA caches) is a complex dynamic system. > They interact in a complex dynamic ways. > Sometimes a change in ARC is incorrect and requires a fix. > Sometimes a change in VM is incorrect and requires a fix. > Sometimes a change in VM requires a change in ARC. > These three kinds of problems can all appear as a "problem with ARC". > > For instance, when vm.lowmem_period was introduced you wouldn't find any mention > of ZFS/ARC. But it does affect period between arc_lowmem() calls. > > Also, pin-pointing a specific commit requires proper bisecting and proper > testing to correctly attribute systemic behavior changes to code changes. I just upgraded my main package build box (12.0-CURRENT, 8 cores, 32 GB RAM) from r327616 to r331716. I was seeing higher swap usage and larger ARC sizes before the upgrade than I remember from the distant past, but ARC was still at least somewhat responsive to memory pressure and I didn't notice any performance issues. After the upgrade, ARC size seems to be pretty unresponsive to memory demand. Currently the machine is near the end of a poudriere run to build my usual set of ~1800 ports. The only currently running build is chromium and the machine is paging heavily. Settings of interest are: USE_TMPFS="wrkdir data localbase" ALLOW_MAKE_JOBS=yes last pid: 96239; load averages: 1.86, 1.76, 1.83 up 3+14:47:00 12:38:11 108 processes: 3 running, 105 sleeping CPU: 18.6% user, 0.0% nice, 2.4% system, 0.0% interrupt, 79.0% idle Mem: 129M Active, 865M Inact, 61M Laundry, 29G Wired, 1553K Buf, 888M Free ARC: 23G Total, 8466M MFU, 10G MRU, 5728K Anon, 611M Header, 3886M Other 17G Compressed, 32G Uncompressed, 1.88:1 Ratio Swap: 40G Total, 17G Used, 23G Free, 42% Inuse, 4756K In PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN 96239 nobody 1 76 0 140M 93636K CPU5 5 0:01 82.90% clang- 96238 nobody 1 75 0 140M 92608K CPU7 7 0:01 80.81% clang- 5148 nobody 1 20 0 590M 113M swread 0 0:31 0.29% clang- 57290 root 1 20 0 12128K 2608K zio->i 7 8:11 0.28% find 78958 nobody 1 20 0 838M 299M swread 0 0:23 0.19% clang- 97840 nobody 1 20 0 698M 140M swread 4 0:27 0.13% clang- 96066 nobody 1 20 0 463M 104M swread 1 0:32 0.12% clang- 11050 nobody 1 20 0 892M 154M swread 2 0:39 0.12% clang- Pre-upgrade I was running r327616, which is newer than either of the commits that Jeff mentioned above. It seems like there has been a regression since then. I also don't recall seeing this problem on my Ryzen box, though it has 2x the core count and 2x the RAM. The last testing that I did on it was with r329844. From owner-freebsd-current@freebsd.org Sun Apr 1 20:01:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0935CF782DD for ; Sun, 1 Apr 2018 20:01:30 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A66C97B292 for ; Sun, 1 Apr 2018 20:01:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: xkjOqUwVM1l_Shu6f99Pmd7oit2KhEIZsaJeUCaF3j4tPdw65c7HKo.U5MAOJZW KTQmRIh7mB98wYCjYO.MrN5..JVidr2.VyHnb4Da1Y7rfP6V_HSUuZ.9Jewb8B47r7AgQiiAdcvx 5tQbuZIhugeZDgGo8Np7tTgoAvv_z0pSCzw8Qvc1_DFF55XjDAU586gAwJRsACOlHbvKSH9c7hHl SDTL1URt0Rk7iHEEtBMrnihsnZSSZgVKzeOdc5eV5jBLMvo.6W5FSHuA3HF2PwiRbBHm7QiFK264 XY.DwilkoTl6NRUgtETPOQ3oSq0F82j3ranjjrogicXVgM0frHs.k6_qFL8MgQ_QMDIBwDGizCSS 0fgt55Y0VIAQkR2D339SsItKFXdV3KupZoX1SPTgLTfmWOGdHa_.GpuGh0Uq1ISUK4tc3s3WOgGM du_gg3Vs_efeGewSUYqQZvF3rLUt0t_OTGcWviQarYhI6OTLnBuM4HpVAVd9JV2Ov12zbIOiHltp .eiIAqolSyjtQRcNjmwP8P9VriUzFS4vRrvml Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 1 Apr 2018 20:01:23 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a37099a88f07b9a4169586ebfe0c9b41 for ; Sun, 01 Apr 2018 20:01:22 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT Message-Id: <7CEC1272-7C77-45F7-A5B7-56AE8CC0621B@yahoo.com> Date: Sun, 1 Apr 2018 13:01:20 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 20:01:30 -0000 Andriy Gapon avg at FreeBSD.org wrote on Tue Mar 27 14:00:20 UTC 2018 : > First, it looks like maybe several different issues are being discussed and > possibly conflated in this thread. It looks like one of the issues that contributes to non-ZFS contexts seeing process-kills for out-of-swap when there is plenty left has been identified in the code for head. See: https://lists.freebsd.org/pipermail/svn-src-head/2018-April/111629.html It looks like Mark Johnston will be checking something in to help but there is more to do after that for what was identified. Overall about the reporting: Despite lots of hypothesizing beyond the evidence presented, I'm glad for the reports of issues from multiple types of environments and to known of types of contexts multiple folks have seen somewhat similar problems with. Separating issues out can be difficult and time consuming. Knowing what all needs eventual coverage helps guide things as progress is made. This is true even for those that are just looking to pick up the eventual fix(es) for the problem(s) they happen to have run into. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Apr 1 21:33:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DAF5F7D6AA for ; Sun, 1 Apr 2018 21:33:50 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBF347EB5B for ; Sun, 1 Apr 2018 21:33:49 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: LJWjjPkVM1lBbkCAqLEhXZwCmfXs3q0ANb39gxtBjcY41nSItRNBGQAacqdb9JE QTVa715ZN4xVJyj0eGgUoF_tRcAs.0GgFCF0rgdUiADH4rfB9GQW3odgZnXYPHzvI3AEXwfM1JCJ YpNmFplqapjRCE.rFAHl1Zm.K2zHQjrRjPT_t4AXIMC772NhrT88bZZuu_G5K0i81Q.0edMLIUhI XoDIU9PcrzHZ_g8I60APqQ4lFUA901OL7HPFxDlO7figczbeckcvCtegXjpvFVWrR1BxVLZpd6V9 .2qxTHr76FvoqXNcVdUZO1y8i8dRl19ZcP3BSD_zGoGXXlr_LUBmwCFdlkVd8rroyqAYPh1y4E.8 yzvEp40AK9Tmz0pLiGUraQTkbepD5.J7lAoBEM_c6ZUBMr8MgJP_tVFyw1PQ2_sG0XoR9wHgFPID sH5NbDiTYd1Gzi.5rY5ZHesTK9AdxHnwAXqrJVUti9EYddC1FD5JM1tx3zKH4DpgDYxZtZ83WrEw zYQ6RincT1zDohvaBwiDeRddvghbEsg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Apr 2018 21:33:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c89bb7fd000d589b52f8f7b1312f48ea; Sun, 01 Apr 2018 21:23:37 +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.3 \(3445.6.18\)) Subject: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? Message-Id: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> Date: Sun, 1 Apr 2018 14:23:36 -0700 To: FreeBSD Current , FreeBSD Hackers , freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 21:33:50 -0000 For: # uname -apKU FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 = amd64 1200060 1200060 I get: . . . pci0: at device 7.3 (no driver attached) . . . intsmb0: at device 7.3 on pci0 intsmb0: Could not allocate I/O space device_attach: intsmb0 attach returned 6 on a Ryzen Threadripper 1950X where FreeBSD is being run under Hyper-V (on a Windows 10 Pro machine). Is this expected? Did I misconfigure something in Hyper-V? This may have been true for a long time and I just had not noticed until now. For reference: # pciconf -l hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x71928086 rev=3D0x03 hdr=3D0x00 isab0@pci0:0:7:0: class=3D0x060100 card=3D0x00001414 = chip=3D0x71108086 rev=3D0x01 hdr=3D0x00 atapci0@pci0:0:7:1: class=3D0x010180 card=3D0x00000000 = chip=3D0x71118086 rev=3D0x01 hdr=3D0x00 none0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 = chip=3D0x71138086 rev=3D0x02 hdr=3D0x00 vgapci0@pci0:0:8:0: class=3D0x030000 card=3D0x00000000 = chip=3D0x53531414 rev=3D0x00 hdr=3D0x00 # pciconf -l -v 0:0:7:3 none0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 = chip=3D0x71138086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ACPI' class =3D bridge And . . . Hyper-V Version: 10.0.16299 [SP0] = Features=3D0x2e7f PM Features=3D0x0 [C2] Features3=3D0xbed7b2 Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.73-MHz = K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1 = Stepping=3D1 = Features=3D0x1783fbff = Features2=3D0xfed83203 AMD Features=3D0x2e500800 AMD Features2=3D0x3f3 Structured Extended = Features=3D0x201c01a9 XSAVE Features=3D0xf AMD Extended Feature Extensions ID EBX=3D0x4 Hypervisor: Origin =3D "Microsoft Hv" real memory =3D 53687091200 (51200 MB) avail memory =3D 52206305280 (49787 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs FreeBSD/SMP: 1 package(s) x 29 core(s) The local changes to /usr/src/ are mostly tied to powerpc64 and powerpc experimental activity, but there is some arm64 and arm material: # svnlite status /usr/src/ | sort ? /usr/src/nohup.out ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/dts/arm/a83t.dtsi ? /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t.dtsi ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/modules/dtb/allwinner/Makefile M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/usr.bin/top/machine.c I've modified top to show "MaxObsUsed" (Maximum Observed used) for Swap when it is positive: Swap: 194G Total, 4235M Used, 4235M MaxObsUsed, 190G Free, 2% Inuse, = 416K In =3D=3D=3D Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Apr 1 22:19:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED427F7FCA9 for ; Sun, 1 Apr 2018 22:19:10 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 733C68088F; Sun, 1 Apr 2018 22:19:10 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd06.aul.t-online.de (fwd06.aul.t-online.de [172.20.26.150]) by mailout09.t-online.de (Postfix) with SMTP id B647D423831F; Mon, 2 Apr 2018 00:19:02 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (GuEPj-Z1rhtBSOiYp2JVJ1hyl3IUmXoqIiWy3S4vF3COcXJScxI-m-aJ9cfulOFQ6z@[84.154.109.148]) by fwd06.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f2lJQ-2I9BTs0; Mon, 2 Apr 2018 00:18:56 +0200 Subject: Re: Extremely low disk throughput under high compute load References: From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== To: "M. Warner Losh" Cc: FreeBSD Current Message-ID: <1d188cb0-ebc8-075f-ed51-57641ede1fd6@freebsd.org> Date: Mon, 2 Apr 2018 00:18:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: de-CH Content-Transfer-Encoding: 7bit X-ID: GuEPj-Z1rhtBSOiYp2JVJ1hyl3IUmXoqIiWy3S4vF3COcXJScxI-m-aJ9cfulOFQ6z X-TOI-MSGID: e0c12624-b252-488f-a7eb-d5e17608be36 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 22:19:11 -0000 Am 01.04.18 um 18:33 schrieb Warner Losh: > > > On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser > wrote: > > My i7-2600K based system with 24 GB RAM was in the midst of a buildworld -j8 > (starting from a clean state) which caused a load average of 12 for more than > 1 hour, when I decided to move a directory structure holding some 10 GB to its > own ZFS file system. File sizes varied, but were mostly in the range 0f 500KB. > > I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus there > was nearly no disk activity caused by the buildworld. > > The copying proceeded at a rate of at most 10 MB/s, but most of the time less > than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus a > much better priority than the compute bound compiler processes, but it got > just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled > at such a low rate, that it only managed to issue a few controller writes per > second. > > The system is healthy and does not show any problems or anomalies under > normal use (e.g., file copies are fast, without the high compute load). > > This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging. > > Is this a regression in -CURRENT? > > Does 'sync' push a lot of I/O to the disk? Each sync takes 0.7 to 1.5 seconds to complete, but since reading is so slow, not much is written. Normal gstat output for the 3 drives the RAIDZ1 consists of: dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 2 2 84 39.1 0 0 0.0 7.8 ada0 0 4 4 92 66.6 0 0 0.0 26.6 ada1 0 6 6 259 66.9 0 0 0.0 36.2 ada3 dT: 1.058s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 1 1 60 70.6 0 0 0.0 6.7 ada0 0 3 3 68 71.3 0 0 0.0 20.2 ada1 0 6 6 242 65.5 0 0 0.0 28.8 ada3 dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 5 5 192 44.8 0 0 0.0 22.4 ada0 0 6 6 160 61.9 0 0 0.0 26.5 ada1 0 6 6 172 43.7 0 0 0.0 26.2 ada3 This includes the copy process and the reads caused by "make -j 8 world" (but I assume that all the source files are already cached in ARC). During sync: dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 101 9 132 14.6 90 1760 5.6 59.7 ada0 2 110 16 267 15.0 92 1756 6.0 50.7 ada1 2 82 13 291 17.8 67 1653 7.4 34.3 ada3 ZFS is configured to flush dirty buffers after 5 seconds, so there are not many dirty buffers in RAM at any time, anyway. > Is the effective throughput of CP tiny or large? It's tiny, if I read right, > and the I/O is slow (as opposed to it all buffering in memory and being slow > to drain own), right? Yes, reading is very slow, with less than 10 read operations scheduled per second. Top output taken at the same time as above gstat samples: last pid: 24306; load averages: 12.07, 11.51, 8.13 up 2+05:41:57 00:10:22 132 processes: 10 running, 122 sleeping CPU: 98.2% user, 0.0% nice, 1.7% system, 0.1% interrupt, 0.0% idle Mem: 1069M Active, 1411M Inact, 269M Laundry, 20G Wired, 1076M Free ARC: 16G Total, 1234M MFU, 14G MRU, 83M Anon, 201M Header, 786M Other 14G Compressed, 30G Uncompressed, 2.09:1 Ratio Swap: 24G Total, 533M Used, 23G Free, 2% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 24284 root 1 92 0 228M 199M CPU6 6 0:11 101.34% c++ 24287 root 1 91 0 269M 241M CPU3 3 0:10 101.32% c++ 24266 root 1 97 0 303M 276M CPU0 0 0:17 101.13% c++ 24297 root 1 85 0 213M 184M CPU1 1 0:06 98.40% c++ 24281 root 1 93 0 245M 217M CPU7 7 0:12 96.76% c++ 24300 root 1 76 0 114M 89268K RUN 2 0:02 83.22% c++ 24303 root 1 75 0 105M 79908K CPU4 4 0:01 59.94% c++ 24302 root 1 52 0 74940K 47264K wait 4 0:00 0.35% c++ 24299 root 1 52 0 74960K 47268K wait 2 0:00 0.33% c++ 20954 root 1 20 0 15528K 4900K zio->i 3 0:02 0.11% cp ARC is limited to 18 GB to leave 6 GB RAM for use by kernel and user programs. vfs.zfs.arc_meta_limit: 4500000000 vfs.zfs.arc_free_target: 42339 vfs.zfs.compressed_arc_enabled: 1 vfs.zfs.arc_grow_retry: 60 vfs.zfs.arc_shrink_shift: 7 vfs.zfs.arc_average_blocksize: 8192 vfs.zfs.arc_no_grow_shift: 5 vfs.zfs.arc_min: 2250000000 vfs.zfs.arc_max: 18000000000 Regards, STefan From owner-freebsd-current@freebsd.org Sun Apr 1 23:41:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26E6FF83B27 for ; Sun, 1 Apr 2018 23:41:08 +0000 (UTC) (envelope-from wheelcomplex@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB0B7834FE; Sun, 1 Apr 2018 23:41:07 +0000 (UTC) (envelope-from wheelcomplex@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id 188-v6so11612041oih.8; Sun, 01 Apr 2018 16:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0sBXWwZvq/IhjUA6X/Sct1Grn2hByhDF6t27etk235M=; b=iZoTbLFTATvnCQpwEENkDC+ZXnw6o/DZtmk8Kl3mE+mOmWwziK25bWXklb+cWiQje5 vpS080vQU9mh0WeTpjNdweYVRE2uoq1/ZbXcO5G9/hIObw2Jf7Z+8RfR8Gl/bsd3+PtR 92Osfl5aI3ePrZWjmsBVxd8liU6b0ON9eGMbNDESIguxCf3/1dPJTaviEzvgfJJrdViJ fv1g9Cd3f9iqCGd48U82KqAkDxhSt1IfHMYt3jGcrh0iEpJV1iZNNSkJ4D1S38p5dAAH vjMtJCk/ZV3cmICyo9n4B7I/NYSe5YPKfYvYseJwrfqh9nSOtqgZ0gaSmsKGxgiNscB6 c0cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0sBXWwZvq/IhjUA6X/Sct1Grn2hByhDF6t27etk235M=; b=g8o/LCuXTwTxE3yWi5F323llKrYfborxZ+hQtNXuneAfnV+DCG03W/DSkvG9DkXMRi 1LallgNQMceca1yqx3jXyWHF7DQptua24FC4fchgEXjSBB1XXO6musbCqGiA3LDDD/Jd ikJmEcwqrWp/p/Quj0s3AWwUcIoY4SiRV3Rtgfaav6iLIlss3UQCW6kTadW6LFpFKE6O ilKN4btCSM4gvgC2i0ia52DZL2FqCKIkDlva3npVnSbwJ1NQFIhA6yCv9l7OSnwk/qek b7w5Hpa4jFBN97xRRYMPR63jYVzhGAjjfr1tjyZkTz1rm43LLG1WnBR7CpiXF2kgSNf3 1JJQ== X-Gm-Message-State: ALQs6tDCijUPC2U4HPXuqMsVxT5lRHKaCd3/nOw0XRtZYYfDPxBV9BZo 3ff1tGb19st9qT9JVgz0oNBdBSx6YyoQoUha2IxyvwTb X-Google-Smtp-Source: AIpwx4+ACApOV6fJ0V9IvkcxGiZzaHSm0EqLDem0d34h1ydNaC3yn9z3HuGqxPudAQCTY0fYg8ecIaXdO5ld3KQb2pQ= X-Received: by 2002:aca:db87:: with SMTP id s129-v6mr4295147oig.105.1522626066961; Sun, 01 Apr 2018 16:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.166.1 with HTTP; Sun, 1 Apr 2018 16:41:06 -0700 (PDT) In-Reply-To: <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: David NewHamlet Date: Mon, 2 Apr 2018 11:41:06 +1200 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Tomoaki AOKI Cc: freebsd-current@freebsd.org, kevans@freebsd.org X-Mailman-Approved-At: Sun, 01 Apr 2018 23:55:54 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 23:41:08 -0000 Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > No benefit (VGA resolution) but no new harm (no panic nor silent > reboot). > > *Maybe gracefully falling back to mode 0. > > As I'm on x11/nvidia-driver, completely no test is done with > drm-next. > > One more to mention. > I've cherry-picked r330868, r331241 and r331361 on stable/11 after > r331114, amd64 and works OK as on head. > Additional cherry-picking of r331365 is OK, too. > > Without r330868, my ThinkPad silently reboots within about 10-60 > minutes range, maybe by actual access to UEFI RS. > With r331241 without r331361 causes instant panic on loading efirt.ko. > So all 3 (4) revs should be MFC'ed together. > > Sorry for delay. > > > On Thu, 22 Mar 2018 10:34:33 -0500 > Kyle Evans wrote: > > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote: > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei > wrote: > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > > >>> Hi. > > >>> For problem 2, try reverting r331241 alone. > > >>> This worked for my ThinkPad T420. > > >> > > >> > > >> I also hit this after updating to latest and was about to post when I > > >> saw this thread - > > >> > > >> I build efirt into the kernel and it's now doing a panic on boot. It > > >> appears to be due to this recent addition in dev/efidev/efirt.c by > r331241: > > >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size / > efihdr->descriptor_size, > > >>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) > { > > >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still a > > >> phys addr here). > > >> > > > > > > The following patch [1] (I can't guarantee how long he'll keep it > > > available there) should fix this class of problems. > > > > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- > EFI-environment-before-check-the-GetT.patch > > > > Now committed as of r331361. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > > > -- > Tomoaki AOKI > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Apr 2 02:28:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E093FF6A352 for ; Mon, 2 Apr 2018 02:28:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 513E068946; Mon, 2 Apr 2018 02:28:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id c78-v6so18821810lfh.1; Sun, 01 Apr 2018 19:28:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5N3Iw3Ji1W0/3zMvOKhMV12NXuuSIqvU20DSe2F0Xu4=; b=VAum6FusqJmn9LAlHcoF6dHZs5aAjnF81v9/1TKvRE3367ssuz8Wa57AlxHlHIolPq 7OoC9BH64jkM7H52qpWb4/hdeEwlp8sR0PmuuraCWSsdm7TQQn4JJYaQX3vd8t6g5lF/ zKCQkudcTYFSDbJfOcRPcUSIF6P4IdQuzHlsx5X2aJxeXZRsZe0PTwbcLiPHn8Rssq6X BNGlRxSFt9jC3lZWhyTcMqvCuur+zUC+JRV0eIffisaF2ZzlBp8nOHCU47nR/6eUul33 4Ou6tHyWqW5prWDjKoF2jIFGfMuiON52v9JPwoD94g6q0PTpwTgGkLAY+LDfnWJyZLWL 7rtA== X-Gm-Message-State: ALQs6tARX8ZaVdST+oxhvl8ZZzvww7Fe7TLnCO0DdXiXFJiE6+m4uKu1 4Xn4IQv4HTUbcjcxT9wwjdSFveBC X-Google-Smtp-Source: AIpwx4+VTA7SV96L21RvuImqH3J2hVbzBH+DNgvnpyEkBStlryx6aFLaoVulYNQYD+1+MWQgm9FpmQ== X-Received: by 10.46.134.211 with SMTP id n19mr4550885ljj.24.1522636081303; Sun, 01 Apr 2018 19:28:01 -0700 (PDT) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. [209.85.215.48]) by smtp.gmail.com with ESMTPSA id 31-v6sm2755870lfs.57.2018.04.01.19.28.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Apr 2018 19:28:01 -0700 (PDT) Received: by mail-lf0-f48.google.com with SMTP id x70-v6so11961661lfa.0; Sun, 01 Apr 2018 19:28:01 -0700 (PDT) X-Received: by 2002:a19:c4c8:: with SMTP id u191-v6mr4787737lff.109.1522636081054; Sun, 01 Apr 2018 19:28:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Sun, 1 Apr 2018 19:27:40 -0700 (PDT) In-Reply-To: <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Kyle Evans Date: Sun, 1 Apr 2018 21:27:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Tomoaki AOKI Cc: FreeBSD Current , Kyle Evans Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 02:28:09 -0000 On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > No benefit (VGA resolution) but no new harm (no panic nor silent > reboot). > > *Maybe gracefully falling back to mode 0. > Did you pick up the change on head that calls maybe-efi-resizecons? On my X220, this bumps my resolution up to 1024x768. > As I'm on x11/nvidia-driver, completely no test is done with > drm-next. This is ok. =) > One more to mention. > I've cherry-picked r330868, r331241 and r331361 on stable/11 after > r331114, amd64 and works OK as on head. > Additional cherry-picking of r331365 is OK, too. > > Without r330868, my ThinkPad silently reboots within about 10-60 > minutes range, maybe by actual access to UEFI RS. > With r331241 without r331361 causes instant panic on loading efirt.ko. > So all 3 (4) revs should be MFC'ed together. Good to hear! We've marked all four of these to be MFC'd in one batch anyways, just to make sure we don't horribly break things. We seem to be in a pretty stable state at the moment on head from what I'm hearing. > Sorry for delay. No worries. =) From owner-freebsd-current@freebsd.org Mon Apr 2 22:51:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CECD8F59587 for ; Mon, 2 Apr 2018 22:51:50 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 606F076E79; Mon, 2 Apr 2018 22:51:50 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io0-x230.google.com with SMTP id x77so13423653ioi.2; Mon, 02 Apr 2018 15:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cNDzsE5CrIse46Khk+Yrc0B0IIH93Ftm3YaJuLZhdsw=; b=TRKwrCWIFEG7D7aGm3GRNwIF5EYhCywcVf1ZEJqkdWk6TDpPU0IrSXRCrw/KeJqfmC iV2ewbrt3czKvoPl71c9tRQBV5/n5OdZAH3xFLQ8ga7OuGUDYgE5tG+imVOosHXd+vKt rjJiZy8F3CgZ+qtgbS9bscoKO5bvQHrpZSjFQOTxXISiZoGr9J+kTX7q1P1CgOquCmKy A7rkpGa/C3zzlhwpdaWZkQwNcwd+Mb+7vi0BKn78xyY8/NTX6I1Oe8Q0UjlayYp8jaMa XLajmt6CrxHW99xOAUrwf8jGTdzeL/rpFV0lEr7qAs0uvgqQTLjzSQUO3zFPFCnwCLGh wqeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cNDzsE5CrIse46Khk+Yrc0B0IIH93Ftm3YaJuLZhdsw=; b=AlDk53B2DU7lE1wVILiO6fwcSku25INel8jUD4ws89WZ/uB4SRab5n77owOIkrBw5Z eorNfAcvv1Y0liH/V1EndNYKqkt/voqxJwsUTqKzSK84H6FWZq2d3JNP+hw3CyNycbOe eb/Wti/NofswuY61v9/k7wkbREzUWhPm2pNAuuggb8kza60LFkmVw2XFgMAS3Et4Kwkm 2tojk9WEqWtzN6/BAGpNwQRBSucWzQEtRJIv5+G0oGYpZaOpDb3c2kZk38iPq7IYgFUh OwODORp5iLAxDF74aR3DcKfoDf8cyQUfDbRZomlQZOtW6qIKxymXh5bFCta/Cy7tMsHK G9Ug== X-Gm-Message-State: ALQs6tCaSNjUu9QA2ZM4qGoFkrC6xuRS+6fbAkf/HipRmLUAGE8ulUpD cWbPgFI1TkQNCJzwdVk7zMEBULm34pInTyJwaQ== X-Google-Smtp-Source: AIpwx48bfBvap4GFCOcM0KErmpSAxKe/QMmsrbfBbGoPmPutDsYNUBk30PvneronR1LIKmvIXu7C5IblF9u850CCIxk= X-Received: by 10.107.8.32 with SMTP id 32mr9671502ioi.136.1522709509481; Mon, 02 Apr 2018 15:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Mon, 2 Apr 2018 15:51:48 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Zaphod Beeblebrox Date: Mon, 2 Apr 2018 18:51:48 -0400 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: David NewHamlet Cc: Tomoaki AOKI , freebsd-current , Kyle Evans Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:51:51 -0000 I've booted that image on my zbook 15. I show in the boot that I can deliberately load efirt.ko ... and it doesn't help. I also show that I can "type blind" after the system boots ... so everything but the screen is working. In case you can't quite make it out, I hit right cursor twice (move to the "live cd" choice) and hit enter. Then I type "root" enter and then "reboot" ... https://youtu.be/tlmaVJ-3aq0 (The rock sound track is just free audio to mask a barking dog and a radio in the background.) On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet wrote: > Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 > > On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI > wrote: > > > Confirmed both loader (with boot1) part and efirt.ko part. > > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > > > No benefit (VGA resolution) but no new harm (no panic nor silent > > reboot). > > > > *Maybe gracefully falling back to mode 0. > > > > As I'm on x11/nvidia-driver, completely no test is done with > > drm-next. > > > > One more to mention. > > I've cherry-picked r330868, r331241 and r331361 on stable/11 after > > r331114, amd64 and works OK as on head. > > Additional cherry-picking of r331365 is OK, too. > > > > Without r330868, my ThinkPad silently reboots within about 10-60 > > minutes range, maybe by actual access to UEFI RS. > > With r331241 without r331361 causes instant panic on loading efirt.ko. > > So all 3 (4) revs should be MFC'ed together. > > > > Sorry for delay. > > > > > > On Thu, 22 Mar 2018 10:34:33 -0500 > > Kyle Evans wrote: > > > > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans > wrote: > > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei > > wrote: > > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > > > >>> Hi. > > > >>> For problem 2, try reverting r331241 alone. > > > >>> This worked for my ThinkPad T420. > > > >> > > > >> > > > >> I also hit this after updating to latest and was about to post when > I > > > >> saw this thread - > > > >> > > > >> I build efirt into the kernel and it's now doing a panic on boot. It > > > >> appears to be due to this recent addition in dev/efidev/efirt.c by > > r331241: > > > >> > > > >>> if (!efi_is_in_map(map, efihdr->memory_size / > > efihdr->descriptor_size, > > > >>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_ > gettime)) > > { > > > >> > > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still > a > > > >> phys addr here). > > > >> > > > > > > > > The following patch [1] (I can't guarantee how long he'll keep it > > > > available there) should fix this class of problems. > > > > > > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- > > EFI-environment-before-check-the-GetT.patch > > > > > > Now committed as of r331361. > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd.org" > > > > > > > > > -- > > Tomoaki AOKI > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Apr 3 01:13:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CC8CF73A73 for ; Tue, 3 Apr 2018 01:13:39 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC4987D1BC for ; Tue, 3 Apr 2018 01:13:38 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-wm0-f67.google.com with SMTP id f125so30993533wme.4 for ; Mon, 02 Apr 2018 18:13:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dUVlKD90GLqmyZR5Xcmy9q1Q+6eL0vu4p2Z2IR9iOLM=; b=mPGkOqpxNnTd+pmd3R7zXolWmLdz4f5ClWKRVL4lcLCn9Ga0g3QPFpOSkPJEQ/6rok HBEA6RbbHNigC7xWJka4EazO5mwnlGwksPBYgC4/917Ehwxp/aIrZtWbCsKN1EES4YxR 0wHUAFIRtFXT7iDMNwp6GF6o2BCFW71Wa5ct7kx88DKQJ++yfqK0xNMnUKoQtFiBjgnZ TcWxGmOZr5p9pQ14Nca6Y8GsCQS19GuhzrbG4btxlwsxOBgLmIBOQ9SJ9SHEKojJIEhx aYdvaKSZatIDaoTYkUJTWdfyWR8yBWjuApkGhZtjZ8c/Xp0yrDXq1U3PR3JRf/OzJEwk RU0g== X-Gm-Message-State: AElRT7Ek5sLePdZtXBVE1zJT9GIyHZFAQJJ9Bdcl1S9OdI5xPsSaFwHO 0ojWOGCSRPkoYMzBlqTPexMfCEyY X-Google-Smtp-Source: AIpwx4+RRiB+3/mTGVZT3dFLX+id41oQX050uJThcX1yRaWHR9bisuyul2JtIDJ2quXvUz4dsl/75w== X-Received: by 10.80.151.167 with SMTP id e36mr14622517edb.210.1522717676119; Mon, 02 Apr 2018 18:07:56 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com. [74.125.82.46]) by smtp.gmail.com with ESMTPSA id l25sm948834edb.49.2018.04.02.18.07.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 18:07:55 -0700 (PDT) Received: by mail-wm0-f46.google.com with SMTP id f125so30973568wme.4 for ; Mon, 02 Apr 2018 18:07:55 -0700 (PDT) X-Received: by 10.46.148.72 with SMTP id o8mr6987942ljh.74.1522717675268; Mon, 02 Apr 2018 18:07:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Mon, 2 Apr 2018 18:07:34 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Kyle Evans Date: Mon, 2 Apr 2018 20:07:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Zaphod Beeblebrox Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 01:13:39 -0000 On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox wrote: > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet > wrote: >> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso >> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 >> >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI >> wrote: >> >> > Confirmed both loader (with boot1) part and efirt.ko part. >> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. >> > >> > No benefit (VGA resolution) but no new harm (no panic nor silent >> > reboot). >> > >> > *Maybe gracefully falling back to mode 0. >> > >> > As I'm on x11/nvidia-driver, completely no test is done with >> > drm-next. >> > >> > One more to mention. >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after >> > r331114, amd64 and works OK as on head. >> > Additional cherry-picking of r331365 is OK, too. >> > >> > Without r330868, my ThinkPad silently reboots within about 10-60 >> > minutes range, maybe by actual access to UEFI RS. >> > With r331241 without r331361 causes instant panic on loading efirt.ko. >> > So all 3 (4) revs should be MFC'ed together. >> > >> > Sorry for delay. >> > >> > >> > On Thu, 22 Mar 2018 10:34:33 -0500 >> > Kyle Evans wrote: >> > >> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans >> > > wrote: >> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei >> > wrote: >> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >> > > >>> Hi. >> > > >>> For problem 2, try reverting r331241 alone. >> > > >>> This worked for my ThinkPad T420. >> > > >> >> > > >> >> > > >> I also hit this after updating to latest and was about to post when >> > > >> I >> > > >> saw this thread - >> > > >> >> > > >> I build efirt into the kernel and it's now doing a panic on boot. >> > > >> It >> > > >> appears to be due to this recent addition in dev/efidev/efirt.c by >> > r331241: >> > > >> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size / >> > efihdr->descriptor_size, >> > > >>> efihdr->descriptor_size, >> > > >>> (vm_offset_t)efi_runtime->rt_gettime)) >> > { >> > > >> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still >> > > >> a >> > > >> phys addr here). >> > > >> >> > > > >> > > > The following patch [1] (I can't guarantee how long he'll keep it >> > > > available there) should fix this class of problems. >> > > > >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- >> > EFI-environment-before-check-the-GetT.patch >> > > >> > > Now committed as of r331361. >> > > _______________________________________________ >> > > freebsd-current@freebsd.org mailing list >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> > freebsd.org" >> > > >> > >> > >> > -- >> > Tomoaki AOKI >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to >> > "freebsd-current-unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I've booted that image on my zbook 15. I show in the boot that I can > deliberately load efirt.ko ... and it doesn't help. I also show that I can > "type blind" after the system boots ... so everything but the screen is > working. > > In case you can't quite make it out, I hit right cursor twice (move to the > "live cd" choice) and hit enter. Then I type "root" enter and then "reboot" > ... That is interesting indeed... that's perhaps the polar opposite of what was being experienced before- it looks like it's setting a higher resolution but the firmware isn't actually putting it into the higher resolution. The firmware then lies to us about what resolution it's actually in, so we tell the kernel the wrong thing. You should be able to confirm this, as I recall, by bumping into the loader prompt and inspecting the output of `gop get`. That should report a higher resolution than it's actually in. > https://youtu.be/tlmaVJ-3aq0 > > (The rock sound track is just free audio to mask a barking dog and a radio > in the background.) > This was a most enjoyable soundtrack. From owner-freebsd-current@freebsd.org Tue Apr 3 07:27:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 511AAF897C0 for ; Tue, 3 Apr 2018 07:27:30 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0F326B1A8 for ; Tue, 3 Apr 2018 07:27:29 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-pl0-x236.google.com with SMTP id u11-v6so7716965plq.1 for ; Tue, 03 Apr 2018 00:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VkPpLpPx6r9JdQlFdiRtDO0T/ecHTepSHXSAW4iHPgQ=; b=hd4yi6gG47Zfm1iqJWihJhikw63o5ni1tZc1o+0Got5+Zw+GCF+netkn6DTb7p7QVk XlM6g5blgqeTHQl5tZVtLFLFs970a1phNq1Kp549BLGDGHWaoY3tWvoK7TUGVMZtGpPl 5Vk3OCeeTHRT3uDQ+g1eJVPJL9NPZFMlwzY7BjoZ465ycsR7EC4MQn5d8cp8j2wPAJz3 mVzZMg6tJETvhd0llifjnKfPR5kzz3OXyBuNHODK0MEpLw7w4Wk9xfBS6mkTk+y1qf0s +R9aPb6zxwRO3p9jrbNDJe5rbmPNFqCw1B3fOoVrF6cw1f8TvVxyF6+yRcZHd3gKu+yl JQrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VkPpLpPx6r9JdQlFdiRtDO0T/ecHTepSHXSAW4iHPgQ=; b=udY5D1cY7SS38h7UMrkbU6Y91KLEAiHKEeU20BIhw4RSkbnEf195wcDzQ4/Qb5+pZe 6btSffbwV3vcFV/5KTvYss9bt0W9EWMiu8wXmnuwtPolBY83B9iU1eeAqEM3a4mdL3cE wBkOVyMZqrpMxSnIPNBs8A3ipBH68uS5ZkFdbURD4IH6TvmsYZJDH8EidP8Qp5j+COCL pMfcpO7WlZvqiIMNXBFohd/esIPQUX/npEoSmBuElu5w0mOYfcjv/5wIWL5VV051huq/ VA7ugtVpQUtVwa2H8eWunq3t47pbNtmaurSIhS0+NI1YQg5W+B1wYfP+MHpRMg6YAhSy skdg== X-Gm-Message-State: AElRT7E0Lk2yaJSACMETtj/r1QYNg6paSrfZ5kCxb4oKXm6jZ4bzuvO+ bWD8ku9sXWpvgB2CSXBZ9k+zIH7UTfavZ7xDeHXKSQ== X-Google-Smtp-Source: AIpwx4/JM4JBvN+cQyHNqhxdK7RSEi/hYFw7mJ5TA5BJ0Dphn/IP0l8G9CpMYm8kWf/DU2HOzbGcBrrz4R6l6QmumS0= X-Received: by 2002:a17:902:7084:: with SMTP id z4-v6mr13384062plk.395.1522740448397; Tue, 03 Apr 2018 00:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.196 with HTTP; Tue, 3 Apr 2018 00:27:27 -0700 (PDT) From: Maurizio Vairani Date: Tue, 3 Apr 2018 09:27:27 +0200 Message-ID: Subject: net/isboot-kmod works with net/istgt but not with ctld(8) To: freebsd-current , John Nielsen , Daisuke Aoyama Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:27:30 -0000 I am successfully running a diskless TrueOS, a FreeBSD 12-CURRENT derivate, desktop with the net/istgt port installed in a FreeBSD 11-RELEASE server. I am using this setup without any error, but it is a bit slow. I want to test ctld on my server, but when the diskless PC loads the isboot driver it loops with a lot of these error messages: =E2=80=9Csoreceive BHS is not complete, remaining byte(s)=3D48 do login failed soreceive BHS is not complete, remaining byte(s)=3D48 do login failed=E2=80=9D The source code, of the isboot-kmod driver, that prints the error message is: /* BHS */ flags =3D MSG_WAITALL; uio.uio_resid =3D ISCSI_BHS_LEN; error =3D soreceive(sess->so, NULL, &uio, &mp, NULL, &flags); if (error) { ISBOOT_ERROR("soreceive BHS error %d\n", error); return (error); } if (uio.uio_resid !=3D 0) { ISBOOT_ERROR("soreceive BHS is not complete, remaining " "byte(s)=3D%d\n", (int) uio.uio_resid); return (EIO); } source file: iscsi.c, proc: isboot_recv_pdu() The ISCSI_BHS_LEN constant is 48 and seems that no bytes are read. On the server, in /var/log/messages, I can read a lots of messages like: =E2=80=9CMar 28 16:32:39 clover-nas2 ctld[59634]: 192.168.0.164: protocol e= rror: received invalid opcode 0x83 Mar 28 16:32:39 clover-nas2 ctld[40784]: child process 59634 terminated with exit status 1 Mar 28 16:32:40 clover-nas2 ctld[59637]: 192.168.0.164: protocol error: received invalid opcode 0x83 Mar 28 16:32:40 clover-nas2 ctld[40784]: child process 59637 terminated with exit status 1=E2=80=9D The isboot driver send an unrecognized opcode 0x83 to the cltd daemon ..., but I cannot continue, I need some help from the community. :-) Note: the patch for compiling and running isboot-kmod in FreeBSD 12 is at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226982 Regards, Maurizio From owner-freebsd-current@freebsd.org Tue Apr 3 16:47:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F69EF6D784 for ; Tue, 3 Apr 2018 16:47:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AFC0E86B40 for ; Tue, 3 Apr 2018 16:47:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w33GQ0H5023952 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Apr 2018 09:26:00 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w33GQ0Yg023951 for freebsd-current@freebsd.org; Tue, 3 Apr 2018 09:26:00 -0700 (PDT) (envelope-from sgk) Date: Tue, 3 Apr 2018 09:26:00 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Can't load linux64.ko module Message-ID: <20180403162600.GA23894@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 16:47:25 -0000 Booting a kernel from % uname -a FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \ Thu Mar 22 13:41:30 AKDT 2018 \ kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64 gives the following from dmesg % dmesg | grep linux link_elf_obj: symbol elf64_linux_vdso_fixup undefined linker_load_file: /boot/kernel/linux64.ko - unsupported file type Mine kernel config file contains options COMPAT_LINUX32 options COMPAT_LINUXKPI options LINPROCFS Is something else missing? A glimpse at /sys/conf/NOTES and /sys/amd64/conf/GENERIC do not reveal anything obvious. -- Steve From owner-freebsd-current@freebsd.org Tue Apr 3 20:05:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2498EF7BF6F for ; Tue, 3 Apr 2018 20:05:32 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A658E7065A; Tue, 3 Apr 2018 20:05:31 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-it0-x230.google.com with SMTP id h143-v6so24990021ita.4; Tue, 03 Apr 2018 13:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ylisUzUleR1gShdud3F6mzPR3nDDu039J19uH+RKSns=; b=B/8ZaNDWt4FzOb3LZIBAAIdZWbD5R81X59alikEFsOYwVmyhV9XcI+p/lJbgKmUsRC 7Ip1sbTAib7kaFAQCaxl9pD3brGUzadFAwfweRJot+CKKvhUTR2tr45o3shjuiMVAao4 5OZ2YJb/2asw/6Kouj2tpZYOkGPLAeh6dn4EwQwE+W2dzcBbwCvtlIKMN8smx9vvzyzV 3Bw/S0oAez7YwmFm4AyEp7kl28mDYi+dbTKLpdxi6jWpsyZnWuS23wr64fFihyjJuMCP EGQ1mMn22nAHsnD+tBevMJtS99ACHT57DjfS+L11AAxU+/cT6FNGMAUnMTTgoKnYjbTA GGHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ylisUzUleR1gShdud3F6mzPR3nDDu039J19uH+RKSns=; b=EzKq+u2FSmS4sISpOZLnEE2Jv/GArsLr7NSiSBpIMKB+L7eh9Wcm1s75sgH2GymCfT 4m86TuWAs5ayYNMJH1T+r99OkkNY0k9T0kiPjcp+ZpX2xBbDQ5Ws4k4k8kLMb40vz3R7 w0yGSwnFi0L0psQD9hHVP+3PxFmoCjjzd51mO5pwAyeE65wPofoaHZ9NjN3w5sLm1Avp QuwsrqK71o1qDzEFKOT2avtGOZkk8YO4qOfi79FkV36bTTU0WPOS+xppiJc2N9JqL7oG iB+xK4KQTRNY/vaebXuYGomkFsc95EpN/ZNS5Rgv1ROyXSYRF+cPiexiT5jpv28IsjV1 qw0w== X-Gm-Message-State: ALQs6tCVpdHa/XeFwSW/f6sn5wVZDPNsEGXtFkRSCovVXTB946SnkyXU 3lVG8OVd+75OwKXvdC0SrbPkv+eIXHqnT3wALFBJ X-Google-Smtp-Source: AIpwx4/y7AShihfnGlOYjNyXaILUSrX9wDtW5Rtj5HRn8yqfX09Tc1aa9kN2ImvkXLkpWwaFmyEAsZHEkxwLerxzQBk= X-Received: by 2002:a24:5f51:: with SMTP id r78-v6mr4698360itb.119.1522785930590; Tue, 03 Apr 2018 13:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Tue, 3 Apr 2018 13:05:30 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Zaphod Beeblebrox Date: Tue, 3 Apr 2018 16:05:30 -0400 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Kyle Evans Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:05:32 -0000 I did as you asked. You can see the result at: https://owncloud.towernet.ca/s/6K3pGknCyGTi7du ... but the long and short of it is that even though the loader is printing in the center of the screen (text mode?), it sees the 1920x1080 mode as the "mode 0" ... I even tried "gop set 0" ... which it accepted, but then continuing to boot produced what you see in the video. I think, since it's in the cetner of the screen, that we're looking at 80x25 text... which is ... 800 x 600 -ish? The kernel definately wants graphics again ... but ... I dunno ... is it getting it? Is the 80x25 text mode emulated on a bitmapped screen? On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans wrote: > On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox > wrote: > > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet > > wrote: > >> > >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso > >> > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 > >> > >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI < > junchoon@dec.sakura.ne.jp> > >> wrote: > >> > >> > Confirmed both loader (with boot1) part and efirt.ko part. > >> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > >> > > >> > No benefit (VGA resolution) but no new harm (no panic nor silent > >> > reboot). > >> > > >> > *Maybe gracefully falling back to mode 0. > >> > > >> > As I'm on x11/nvidia-driver, completely no test is done with > >> > drm-next. > >> > > >> > One more to mention. > >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after > >> > r331114, amd64 and works OK as on head. > >> > Additional cherry-picking of r331365 is OK, too. > >> > > >> > Without r330868, my ThinkPad silently reboots within about 10-60 > >> > minutes range, maybe by actual access to UEFI RS. > >> > With r331241 without r331361 causes instant panic on loading efirt.ko. > >> > So all 3 (4) revs should be MFC'ed together. > >> > > >> > Sorry for delay. > >> > > >> > > >> > On Thu, 22 Mar 2018 10:34:33 -0500 > >> > Kyle Evans wrote: > >> > > >> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans > >> > > wrote: > >> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei > >> > wrote: > >> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > >> > > >>> Hi. > >> > > >>> For problem 2, try reverting r331241 alone. > >> > > >>> This worked for my ThinkPad T420. > >> > > >> > >> > > >> > >> > > >> I also hit this after updating to latest and was about to post > when > >> > > >> I > >> > > >> saw this thread - > >> > > >> > >> > > >> I build efirt into the kernel and it's now doing a panic on boot. > >> > > >> It > >> > > >> appears to be due to this recent addition in dev/efidev/efirt.c > by > >> > r331241: > >> > > >> > >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size / > >> > efihdr->descriptor_size, > >> > > >>> efihdr->descriptor_size, > >> > > >>> (vm_offset_t)efi_runtime->rt_gettime)) > >> > { > >> > > >> > >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is > still > >> > > >> a > >> > > >> phys addr here). > >> > > >> > >> > > > > >> > > > The following patch [1] (I can't guarantee how long he'll keep it > >> > > > available there) should fix this class of problems. > >> > > > > >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- > >> > EFI-environment-before-check-the-GetT.patch > >> > > > >> > > Now committed as of r331361. > >> > > _______________________________________________ > >> > > freebsd-current@freebsd.org mailing list > >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > >> > freebsd.org" > >> > > > >> > > >> > > >> > -- > >> > Tomoaki AOKI > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to > >> > "freebsd-current-unsubscribe@freebsd.org" > >> > > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > > I've booted that image on my zbook 15. I show in the boot that I can > > deliberately load efirt.ko ... and it doesn't help. I also show that I > can > > "type blind" after the system boots ... so everything but the screen is > > working. > > > > In case you can't quite make it out, I hit right cursor twice (move to > the > > "live cd" choice) and hit enter. Then I type "root" enter and then > "reboot" > > ... > > That is interesting indeed... that's perhaps the polar opposite of > what was being experienced before- it looks like it's setting a higher > resolution but the firmware isn't actually putting it into the higher > resolution. The firmware then lies to us about what resolution it's > actually in, so we tell the kernel the wrong thing. > > You should be able to confirm this, as I recall, by bumping into the > loader prompt and inspecting the output of `gop get`. That should > report a higher resolution than it's actually in. > > > https://youtu.be/tlmaVJ-3aq0 > > > > (The rock sound track is just free audio to mask a barking dog and a > radio > > in the background.) > > > > This was a most enjoyable soundtrack. > From owner-freebsd-current@freebsd.org Tue Apr 3 20:17:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45A52F7CD5A for ; Tue, 3 Apr 2018 20:17:53 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5A7C710A9 for ; Tue, 3 Apr 2018 20:17:52 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f49.google.com with SMTP id q9-v6so2520124lfk.9 for ; Tue, 03 Apr 2018 13:17:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=349v1PZ+Dv4NOMkxT36gKL/JPl6bQB4lIS+c+4VXLD8=; b=JKL0PujzxzhvKqp9WZc5ZRXgGOqEcd4iMfTAZdo15MR4G8YGP8JNZ5Cm7d4lxtSItc KL2S6WGm0Sh+t0M64GQJZBylymv5j/lL+sJPLySiYYzJ7/g1Rfy65I3chs0imT6Y2SEu eoV/bey1Td7R3BVgwhCC/0ZR+lzR3wpaZb+fSnXGJ75sTcDD2T6pmmt2B3XRDzXSTgvP s9rX3nHTLWjdzPcGPhWhi1ixxlnJi0GU9+32t4hDfu5BuB0x/a80KxE3xHJYuYW2vUpR PeSBJ3lomHo4uDciI7JPDEdAfmjpsdMHQJxfuP+KpQyTH0XojL+hlMBuoG/WrvUw6lu7 chWw== X-Gm-Message-State: ALQs6tA4MhA9LtS6otOm5RIWIVLedoRRhX1JVQXZg4Dz62YAK6YbhmKh 0nZuiKjZs2PP/8CZxfN4N8rEAsbx X-Google-Smtp-Source: AIpwx49RMVSKyrHsCrEh07EbvQz1LvKJg7t62njn7pLgU5ssDUNzf4yFGyAkbDvgZTIVW1nfd9aVag== X-Received: by 10.46.29.1 with SMTP id d1mr9508540ljd.22.1522786664672; Tue, 03 Apr 2018 13:17:44 -0700 (PDT) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com. [209.85.215.44]) by smtp.gmail.com with ESMTPSA id l187-v6sm683588lfg.15.2018.04.03.13.17.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 13:17:44 -0700 (PDT) Received: by mail-lf0-f44.google.com with SMTP id q9-v6so2520064lfk.9 for ; Tue, 03 Apr 2018 13:17:44 -0700 (PDT) X-Received: by 10.46.148.72 with SMTP id o8mr9473832ljh.74.1522786663917; Tue, 03 Apr 2018 13:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 3 Apr 2018 13:17:23 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Kyle Evans Date: Tue, 3 Apr 2018 15:17:23 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Zaphod Beeblebrox Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:17:53 -0000 Hi, Right- so, `gop set 0` should've immediately cleared your screen and put it into 1920x1080, full stop. If it did not, I think that's indicative of some kind of interestingly broken firmware... Regardless! We're clearly bad at trying to set a mode before the kernel starts, so r331904 sets the default max resolution in such a way that we just don't change the resolution by default anymore and interested parties can bump that up if they want to try it. This Thursday's snapshots should have this included. I think if we're going to change modes as a default, we should have some way for vt/efifb to use EFIRT or be notified by EFIRT of supported resolutions so that vt/efifb can hopefully just handle it all and do it properly. This approach would be more similar I guess to how KMS drivers operate, and less fragile than what we're seeing with these different approaches we've taken. On Tue, Apr 3, 2018 at 3:05 PM, Zaphod Beeblebrox wrote: > I did as you asked. You can see the result at: > https://owncloud.towernet.ca/s/6K3pGknCyGTi7du > > ... but the long and short of it is that even though the loader is printing > in the center of the screen (text mode?), it sees the 1920x1080 mode as the > "mode 0" ... I even tried "gop set 0" ... which it accepted, but then > continuing to boot produced what you see in the video. > > I think, since it's in the cetner of the screen, that we're looking at 80x25 > text... which is ... 800 x 600 -ish? The kernel definately wants graphics > again ... but ... I dunno ... is it getting it? Is the 80x25 text mode > emulated on a bitmapped screen? > > > On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans wrote: >> >> On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox >> wrote: >> > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet >> > wrote: >> >> >> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso >> >> >> >> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 >> >> >> >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI >> >> >> >> wrote: >> >> >> >> > Confirmed both loader (with boot1) part and efirt.ko part. >> >> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. >> >> > >> >> > No benefit (VGA resolution) but no new harm (no panic nor silent >> >> > reboot). >> >> > >> >> > *Maybe gracefully falling back to mode 0. >> >> > >> >> > As I'm on x11/nvidia-driver, completely no test is done with >> >> > drm-next. >> >> > >> >> > One more to mention. >> >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after >> >> > r331114, amd64 and works OK as on head. >> >> > Additional cherry-picking of r331365 is OK, too. >> >> > >> >> > Without r330868, my ThinkPad silently reboots within about 10-60 >> >> > minutes range, maybe by actual access to UEFI RS. >> >> > With r331241 without r331361 causes instant panic on loading >> >> > efirt.ko. >> >> > So all 3 (4) revs should be MFC'ed together. >> >> > >> >> > Sorry for delay. >> >> > >> >> > >> >> > On Thu, 22 Mar 2018 10:34:33 -0500 >> >> > Kyle Evans wrote: >> >> > >> >> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans >> >> > > wrote: >> >> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei >> >> > wrote: >> >> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >> >> > > >>> Hi. >> >> > > >>> For problem 2, try reverting r331241 alone. >> >> > > >>> This worked for my ThinkPad T420. >> >> > > >> >> >> > > >> >> >> > > >> I also hit this after updating to latest and was about to post >> >> > > >> when >> >> > > >> I >> >> > > >> saw this thread - >> >> > > >> >> >> > > >> I build efirt into the kernel and it's now doing a panic on >> >> > > >> boot. >> >> > > >> It >> >> > > >> appears to be due to this recent addition in dev/efidev/efirt.c >> >> > > >> by >> >> > r331241: >> >> > > >> >> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size / >> >> > efihdr->descriptor_size, >> >> > > >>> efihdr->descriptor_size, >> >> > > >>> (vm_offset_t)efi_runtime->rt_gettime)) >> >> > { >> >> > > >> >> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is >> >> > > >> still >> >> > > >> a >> >> > > >> phys addr here). >> >> > > >> >> >> > > > >> >> > > > The following patch [1] (I can't guarantee how long he'll keep it >> >> > > > available there) should fix this class of problems. >> >> > > > >> >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- >> >> > EFI-environment-before-check-the-GetT.patch >> >> > > >> >> > > Now committed as of r331361. >> >> > > _______________________________________________ >> >> > > freebsd-current@freebsd.org mailing list >> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> >> > freebsd.org" >> >> > > >> >> > >> >> > >> >> > -- >> >> > Tomoaki AOKI >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to >> >> > "freebsd-current-unsubscribe@freebsd.org" >> >> > >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to >> >> "freebsd-current-unsubscribe@freebsd.org" >> > >> > I've booted that image on my zbook 15. I show in the boot that I can >> > deliberately load efirt.ko ... and it doesn't help. I also show that I >> > can >> > "type blind" after the system boots ... so everything but the screen is >> > working. >> > >> > In case you can't quite make it out, I hit right cursor twice (move to >> > the >> > "live cd" choice) and hit enter. Then I type "root" enter and then >> > "reboot" >> > ... >> >> That is interesting indeed... that's perhaps the polar opposite of >> what was being experienced before- it looks like it's setting a higher >> resolution but the firmware isn't actually putting it into the higher >> resolution. The firmware then lies to us about what resolution it's >> actually in, so we tell the kernel the wrong thing. >> >> You should be able to confirm this, as I recall, by bumping into the >> loader prompt and inspecting the output of `gop get`. That should >> report a higher resolution than it's actually in. >> >> > https://youtu.be/tlmaVJ-3aq0 >> > >> > (The rock sound track is just free audio to mask a barking dog and a >> > radio >> > in the background.) >> > >> >> This was a most enjoyable soundtrack. > > Kyle Evans, Web/Database Developer College of Engineering, Kansas State University kevans91@ksu.edu (785) 532-4643 0012 Seaton Hall On Tue, Apr 3, 2018 at 3:05 PM, Zaphod Beeblebrox wrote: > I did as you asked. You can see the result at: > https://owncloud.towernet.ca/s/6K3pGknCyGTi7du > > ... but the long and short of it is that even though the loader is printing > in the center of the screen (text mode?), it sees the 1920x1080 mode as the > "mode 0" ... I even tried "gop set 0" ... which it accepted, but then > continuing to boot produced what you see in the video. > > I think, since it's in the cetner of the screen, that we're looking at 80x25 > text... which is ... 800 x 600 -ish? The kernel definately wants graphics > again ... but ... I dunno ... is it getting it? Is the 80x25 text mode > emulated on a bitmapped screen? > > > On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans wrote: >> >> On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox >> wrote: >> > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet >> > wrote: >> >> >> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso >> >> >> >> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 >> >> >> >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI >> >> >> >> wrote: >> >> >> >> > Confirmed both loader (with boot1) part and efirt.ko part. >> >> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. >> >> > >> >> > No benefit (VGA resolution) but no new harm (no panic nor silent >> >> > reboot). >> >> > >> >> > *Maybe gracefully falling back to mode 0. >> >> > >> >> > As I'm on x11/nvidia-driver, completely no test is done with >> >> > drm-next. >> >> > >> >> > One more to mention. >> >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after >> >> > r331114, amd64 and works OK as on head. >> >> > Additional cherry-picking of r331365 is OK, too. >> >> > >> >> > Without r330868, my ThinkPad silently reboots within about 10-60 >> >> > minutes range, maybe by actual access to UEFI RS. >> >> > With r331241 without r331361 causes instant panic on loading >> >> > efirt.ko. >> >> > So all 3 (4) revs should be MFC'ed together. >> >> > >> >> > Sorry for delay. >> >> > >> >> > >> >> > On Thu, 22 Mar 2018 10:34:33 -0500 >> >> > Kyle Evans wrote: >> >> > >> >> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans >> >> > > wrote: >> >> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei >> >> > wrote: >> >> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >> >> > > >>> Hi. >> >> > > >>> For problem 2, try reverting r331241 alone. >> >> > > >>> This worked for my ThinkPad T420. >> >> > > >> >> >> > > >> >> >> > > >> I also hit this after updating to latest and was about to post >> >> > > >> when >> >> > > >> I >> >> > > >> saw this thread - >> >> > > >> >> >> > > >> I build efirt into the kernel and it's now doing a panic on >> >> > > >> boot. >> >> > > >> It >> >> > > >> appears to be due to this recent addition in dev/efidev/efirt.c >> >> > > >> by >> >> > r331241: >> >> > > >> >> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size / >> >> > efihdr->descriptor_size, >> >> > > >>> efihdr->descriptor_size, >> >> > > >>> (vm_offset_t)efi_runtime->rt_gettime)) >> >> > { >> >> > > >> >> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is >> >> > > >> still >> >> > > >> a >> >> > > >> phys addr here). >> >> > > >> >> >> > > > >> >> > > > The following patch [1] (I can't guarantee how long he'll keep it >> >> > > > available there) should fix this class of problems. >> >> > > > >> >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the- >> >> > EFI-environment-before-check-the-GetT.patch >> >> > > >> >> > > Now committed as of r331361. >> >> > > _______________________________________________ >> >> > > freebsd-current@freebsd.org mailing list >> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> >> > freebsd.org" >> >> > > >> >> > >> >> > >> >> > -- >> >> > Tomoaki AOKI >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to >> >> > "freebsd-current-unsubscribe@freebsd.org" >> >> > >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to >> >> "freebsd-current-unsubscribe@freebsd.org" >> > >> > I've booted that image on my zbook 15. I show in the boot that I can >> > deliberately load efirt.ko ... and it doesn't help. I also show that I >> > can >> > "type blind" after the system boots ... so everything but the screen is >> > working. >> > >> > In case you can't quite make it out, I hit right cursor twice (move to >> > the >> > "live cd" choice) and hit enter. Then I type "root" enter and then >> > "reboot" >> > ... >> >> That is interesting indeed... that's perhaps the polar opposite of >> what was being experienced before- it looks like it's setting a higher >> resolution but the firmware isn't actually putting it into the higher >> resolution. The firmware then lies to us about what resolution it's >> actually in, so we tell the kernel the wrong thing. >> >> You should be able to confirm this, as I recall, by bumping into the >> loader prompt and inspecting the output of `gop get`. That should >> report a higher resolution than it's actually in. >> >> > https://youtu.be/tlmaVJ-3aq0 >> > >> > (The rock sound track is just free audio to mask a barking dog and a >> > radio >> > in the background.) >> > >> >> This was a most enjoyable soundtrack. > > From owner-freebsd-current@freebsd.org Tue Apr 3 20:48:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC8B2F7F1FD for ; Tue, 3 Apr 2018 20:48:26 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3550C7332D for ; Tue, 3 Apr 2018 20:48:26 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f47.google.com with SMTP id u3-v6so22128659lff.5 for ; Tue, 03 Apr 2018 13:48:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZtCHwn9TnY2PqHIEmq9Z29+H92r2Cs230tk0ZSOEMdM=; b=cJ3W5eZzHs+7a4jCg71eypzIRhI7kE/QCt0psbpn+Kz1Xc/cgVa+erUN4I8frO41U0 soH0BqjKLwVEeeR3HbNUEb1za+lh37f0cgwNA5RQean9LjvmMyBDa8S14rslAChpYn0N 0gYC+8WtkQT9rdsIvPQG+acwvbJnYr2ECJTdF/CyTEwcSJmK2Qb4E1gtEC+lvowG7d3K PL69pLFbzmo4HJDPXFEr3MQSPr8ktXoPR4bg3PuIw9VYIbhVtErUFkvaA/yNj73PoSiW mnoTWDFVJQJ0C9Vw/AUyzFJd11fjaq91CNFO4GtxzoJU7N24/pyFghDJGpqk4pB76amH 5lZg== X-Gm-Message-State: ALQs6tAM6zoEJlJXtGWobbm4qrS4NBjpYnjD0oEAcstk7aKiPl+fl+Ul elg6aSgTkaSKFWj8rsyZw2UmSXmY X-Google-Smtp-Source: AIpwx48EFZddkG19/y8aSAgfABexpT17n2UlE+dJSW7+gW0dqZRu3UmShKPrGfGAWmakwUMR+SBszg== X-Received: by 2002:a19:511d:: with SMTP id f29-v6mr9216464lfb.39.1522788504021; Tue, 03 Apr 2018 13:48:24 -0700 (PDT) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. [209.85.215.48]) by smtp.gmail.com with ESMTPSA id f24sm613610ljj.76.2018.04.03.13.48.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 13:48:23 -0700 (PDT) Received: by mail-lf0-f48.google.com with SMTP id q9-v6so2630179lfk.9 for ; Tue, 03 Apr 2018 13:48:23 -0700 (PDT) X-Received: by 2002:a19:b516:: with SMTP id e22-v6mr9597809lff.47.1522788503674; Tue, 03 Apr 2018 13:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 3 Apr 2018 13:48:03 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Kyle Evans Date: Tue, 3 Apr 2018 15:48:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Zaphod Beeblebrox Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:48:27 -0000 On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote: > Hi, > > Right- so, `gop set 0` should've immediately cleared your screen and > put it into 1920x1080, full stop. If it did not, I think that's > indicative of some kind of interestingly broken firmware... > > Regardless! We're clearly bad at trying to set a mode before the > kernel starts, so r331904 sets the default max resolution in such a > way that we just don't change the resolution by default anymore and > interested parties can bump that up if they want to try it. This > Thursday's snapshots should have this included. After reviewing the video again and discussing it with manu, I don't think that commit's going to solve your problem at all... we'll need to re-think this one a bit more. > I think if we're going to change modes as a default, we should have > some way for vt/efifb to use EFIRT or be notified by EFIRT of > supported resolutions so that vt/efifb can hopefully just handle it > all and do it properly. This approach would be more similar I guess to > how KMS drivers operate, and less fragile than what we're seeing with > these different approaches we've taken. > From owner-freebsd-current@freebsd.org Wed Apr 4 01:01:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45A5FF81B07 for ; Wed, 4 Apr 2018 01:01:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D64D97EBDA; Wed, 4 Apr 2018 01:01:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w3412E7C070492 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Apr 2018 01:02:15 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w3410vJ6034923 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2018 18:00:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Tue, 3 Apr 2018 18:00:51 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Andriy Gapon cc: Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: Message-ID: References: <20180306173455.oacyqlbib4sbafqd@ler-imac.lerctr.org> <201803061816.w26IGaW5050053@pdx.rh.CN85.dnsmgr.net> <20180306193645.vv3ogqrhauivf2tr@ler-imac.lerctr.org> <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:01:09 -0000 On 1 Apr, Don Lewis wrote: > On 27 Mar, Andriy Gapon wrote: >> On 24/03/2018 01:21, Bryan Drewery wrote: >>> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>>> >>>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >>>>> Also, if you could try going back to r328953 or r326346 and let me know if >>>>> the problem exists in either. That would be very helpful. If anyone is >>>>> willing to debug this with me contact me directly and I will send some >>>>> test patches or debugging info after you have done the above steps. >>>> >>>> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). >>>> I initially got around the problem by reverting that commit but either >>>> it or something very similar is still present in 11-stable r331053. >>>> >>>> I've seen it in my main server (32GB RAM) but haven't managed to reproduce >>>> it in smaller VBox guests - one difficulty I faced was artificially filling >>>> ARC. >> >> First, it looks like maybe several different issues are being discussed and >> possibly conflated in this thread. I see reports related to ZFS, I see reports >> where ZFS is not used at all. Some people report problems that appeared very >> recently while others chime in with "yes, yes, I've always had this problem". >> This does not help to differentiate between problems and to analyze them. >> >>> Looking at the ARC change you referred to from r325851 >>> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure >>> is completely broken. >> >> Does your being convinced come from the code review or from experiments? >> If the former, could you please share your analysis? >> >>> On my 78GB RAM system with ARC limited to 40GB and >>> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I >>> can get swap up near 50GB and yet the ARC remains at 40GB through it >>> all. It's always been slow to give up memory for package builds but it >>> really seems broken right now. >> >> Well, there are multiple angles. Maybe it's ARC that does not react properly, >> or maybe it's not being asked properly. >> >> It would be useful to monitor the system during its transition to the state that >> you reported. There are some interesting DTrace probes in ARC, specifically >> arc-available_memory and arc-needfree are first that come to mind. Their >> parameters and how frequently they are called are of interest. VM parameters >> could be of interest as well. >> >> A rant. >> >> Basically, posting some numbers and jumping to conclusions does not help at all. >> Monitoring, graphing, etc does help. >> ARC is a complex dynamic system. >> VM (pagedaemon, UMA caches) is a complex dynamic system. >> They interact in a complex dynamic ways. >> Sometimes a change in ARC is incorrect and requires a fix. >> Sometimes a change in VM is incorrect and requires a fix. >> Sometimes a change in VM requires a change in ARC. >> These three kinds of problems can all appear as a "problem with ARC". >> >> For instance, when vm.lowmem_period was introduced you wouldn't find any mention >> of ZFS/ARC. But it does affect period between arc_lowmem() calls. >> >> Also, pin-pointing a specific commit requires proper bisecting and proper >> testing to correctly attribute systemic behavior changes to code changes. > > I just upgraded my main package build box (12.0-CURRENT, 8 cores, 32 GB > RAM) from r327616 to r331716. I was seeing higher swap usage and larger > ARC sizes before the upgrade than I remember from the distant past, but > ARC was still at least somewhat responsive to memory pressure and I > didn't notice any performance issues. > > After the upgrade, ARC size seems to be pretty unresponsive to memory > demand. Currently the machine is near the end of a poudriere run to > build my usual set of ~1800 ports. The only currently running build is > chromium and the machine is paging heavily. Settings of interest are: > USE_TMPFS="wrkdir data localbase" > ALLOW_MAKE_JOBS=yes > > last pid: 96239; load averages: 1.86, 1.76, 1.83 up 3+14:47:00 12:38:11 > 108 processes: 3 running, 105 sleeping > CPU: 18.6% user, 0.0% nice, 2.4% system, 0.0% interrupt, 79.0% idle > Mem: 129M Active, 865M Inact, 61M Laundry, 29G Wired, 1553K Buf, 888M Free > ARC: 23G Total, 8466M MFU, 10G MRU, 5728K Anon, 611M Header, 3886M Other > 17G Compressed, 32G Uncompressed, 1.88:1 Ratio > Swap: 40G Total, 17G Used, 23G Free, 42% Inuse, 4756K In > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN > 96239 nobody 1 76 0 140M 93636K CPU5 5 0:01 82.90% clang- > 96238 nobody 1 75 0 140M 92608K CPU7 7 0:01 80.81% clang- > 5148 nobody 1 20 0 590M 113M swread 0 0:31 0.29% clang- > 57290 root 1 20 0 12128K 2608K zio->i 7 8:11 0.28% find > 78958 nobody 1 20 0 838M 299M swread 0 0:23 0.19% clang- > 97840 nobody 1 20 0 698M 140M swread 4 0:27 0.13% clang- > 96066 nobody 1 20 0 463M 104M swread 1 0:32 0.12% clang- > 11050 nobody 1 20 0 892M 154M swread 2 0:39 0.12% clang- > > Pre-upgrade I was running r327616, which is newer than either of the > commits that Jeff mentioned above. It seems like there has been a > regression since then. > > I also don't recall seeing this problem on my Ryzen box, though it has > 2x the core count and 2x the RAM. The last testing that I did on it was > with r329844. I reconfigured my Ryzen box to be more similar to my default package builder by disabling SMT and half of the RAM, to limit it to 8 cores and 32 GB and then started bisecting to try to track down the problem. For each test, I first filled ARC by tarring /usr/ports/distfiles to /dev/null. The commit range that I was searching was r329844 to r331716. I narrowed the range to r329844 to r329904. With r329904 and newer, ARC is totally unresponsive to memory pressure and the machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired RAM, so there is not much leftover for getting useful work done. Active memory and free memory both hover under 1GB each. Looking at the commit logs over this range, the most likely culprit is: r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines Add a generic Proportional Integral Derivative (PID) controller algorithm and use it to regulate page daemon output. This provides much smoother and more responsive page daemon output, anticipating demand and avoiding pageout stalls by increasing the number of pages to match the workload. This is a reimplementation of work done by myself and mlaier at Isilon. It is quite possible that the recent fixes to the PID controller will fix the problem. Not that r329844 was trouble free ... I left tar running over lunchtime to fill ARC and the OOM killer nuked top, tar, ntpd, both of my ssh sessions into the machine, and multiple instances of getty while I was away. I was able to log in again and successfully run poudriere, and ARC did respond to the memory pressure and cranked itself down to about 5 GB by the end of the run. I did not see the same problem with tar when I did the same with r329904. From owner-freebsd-current@freebsd.org Wed Apr 4 01:24:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8071F83752 for ; Wed, 4 Apr 2018 01:24:10 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E7E480010; Wed, 4 Apr 2018 01:24:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3X9hfPJ2LLkoz3X9ifB89S; Tue, 03 Apr 2018 19:24:08 -0600 X-Authority-Analysis: v=2.3 cv=OeS28CbY c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=Kd1tUaAdevIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=8fqvCxzDAAAA:8 a=sGrq7PPEvxWp16kddGsA:9 a=5bzJm3nuKtSYrKue:21 a=Uy1ke3g2fX7XpUPD:21 a=pILNOxqGKmIA:10 a=YqfClZkjNve_kGh8EgYA:9 a=xLCaijx8jdLD70l0:21 a=i6VEl9GyXKE1H_Rv:21 a=G1ViwICIU4wCaw8C:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=xrUD0wEA3vlMLTxm4nS9:22 Received: from [25.85.100.44] (unknown [24.244.29.139]) by spqr.komquats.com (Postfix) with ESMTPSA id 643D51076; Tue, 3 Apr 2018 18:24:04 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Strange ARC/Swap/CPU on yesterday's -CURRENT Date: Tue, 3 Apr 2018 19:24:04 -0600 To: Bryan Drewery , Peter Jeremy , Jeff Roberson CC: FreeBSD current , Andriy Gapon Message-Id: <20180404012404.643D51076@spqr.komquats.com> X-CMAE-Envelope: MS4wfP2HhqiknxuX/TyPGjp8lYBQQ0eOBbGljLQLhgPQU0IiQ1OZchIWaml8yIygRsoBysHvZwGkarwdmcYNmylwe5UZoZ65TTBRwlv8USafgWCAsEw5X4/0 9xP4mTj8kqq4n124C+y3Gqqk1AqewXiGWzxGu+fh0WfQzn82qxCIkQlPtVFbLedy22JVaPHcD9OMbUThBDkZKAhCKXdj3kLToXisp3O89Hoa1Kstt+uTD0wP rMUZOxIx5b2QrtZcXSPpSNvlZotrvFtw79ZYBpFuwwIoxeGFl/wc9dABZWXT8fyV Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:24:10 -0000 +1 However under certain circumstances it will release some memory. To reprodu= ce, when bsdtar unpacks some tarballs (when building certain ports) tar wil= l use 12 GB or more forcing ARC to release memory. BTW, I haven't stopped to grok whether the bsdtar issue is local to me or a= nother problem yet. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Bryan Drewery Sent: 23/03/2018 17:23 To: Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT On 3/20/2018 12:07 AM, Peter Jeremy wrote: >=20 > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wr= ote: >> Also, if you could try going back to r328953 or r326346 and let me know = if=20 >> the problem exists in either. That would be very helpful. If anyone is= =20 >> willing to debug this with me contact me directly and I will send some=20 >> test patches or debugging info after you have done the above steps. >=20 > I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). > I initially got around the problem by reverting that commit but either > it or something very similar is still present in 11-stable r331053. >=20 > I've seen it in my main server (32GB RAM) but haven't managed to reproduc= e > it in smaller VBox guests - one difficulty I faced was artificially filli= ng > ARC. >=20 Looking at the ARC change you referred to from r325851 https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure is completely broken. On my 78GB RAM system with ARC limited to 40GB and doing a poudriere build of all LLVM and GCC packages at once in tmpfs I can get swap up near 50GB and yet the ARC remains at 40GB through it all. It's always been slow to give up memory for package builds but it really seems broken right now. --=20 Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Wed Apr 4 01:27:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A957F83A28 for ; Wed, 4 Apr 2018 01:27:11 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACC5C801A1; Wed, 4 Apr 2018 01:27:10 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JvnERG43LardnqDIyHUJxY4MsmzXRHCOGWOajUYqs2U=; b=qTWwEDVpi+JFHSquOHoizYgIFk tdtJnMf2bsoc5olUKXw6OplYbiY3iVHiVmBKw8GZ86HuqEk0lEX8wFDISyodtfxuKHHlThWuluWxM enpsG0hqIqVGzqYCNWZRtboLb40ia+pgbBoiNW9lQf22szYeUJE4rPI1YPFjBKTcSFc8=; Received: from [2600:1700:210:b18f:3427:71c7:7f27:d86c] (port=63630 helo=[192.168.200.50]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1f3XCe-0000OW-8m; Tue, 03 Apr 2018 20:27:08 -0500 User-Agent: Microsoft-MacOutlook/10.d.0.180401 Date: Tue, 03 Apr 2018 20:27:06 -0500 Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT From: Larry Rosenman To: Cy Schubert , Bryan Drewery , Peter Jeremy , Jeff Roberson CC: FreeBSD current , Andriy Gapon Message-ID: <2086F174-5F14-4812-A55F-F376993E9589@lerctr.org> Thread-Topic: Strange ARC/Swap/CPU on yesterday's -CURRENT References: <20180404012404.643D51076@spqr.komquats.com> In-Reply-To: <20180404012404.643D51076@spqr.komquats.com> X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:27:11 -0000 When my full backups run (1st Sunday -> Monday of the month) the box become= s unusable after 5-10 hours of that backup with LOTS of SWAP usage And ARC using 100+G.=20 Is anyone looking into this? --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =EF=BB=BFOn 4/3/18, 8:24 PM, "Cy Schubert" wrote: +1 =20 However under certain circumstances it will release some memory. To rep= roduce, when bsdtar unpacks some tarballs (when building certain ports) tar = will use 12 GB or more forcing ARC to release memory. =20 BTW, I haven't stopped to grok whether the bsdtar issue is local to me = or another problem yet. =20 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. =20 Cy Schubert or The need of the many outweighs the greed of the few. --- =20 -----Original Message----- From: Bryan Drewery Sent: 23/03/2018 17:23 To: Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT =20 On 3/20/2018 12:07 AM, Peter Jeremy wrote: >=20 > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >> Also, if you could try going back to r328953 or r326346 and let me k= now if=20 >> the problem exists in either. That would be very helpful. If anyon= e is=20 >> willing to debug this with me contact me directly and I will send so= me=20 >> test patches or debugging info after you have done the above steps. >=20 > I ran into this on 11-stable and tracked it to r326619 (MFC of r32585= 1). > I initially got around the problem by reverting that commit but eithe= r > it or something very similar is still present in 11-stable r331053. >=20 > I've seen it in my main server (32GB RAM) but haven't managed to repr= oduce > it in smaller VBox guests - one difficulty I faced was artificially f= illing > ARC. >=20 =20 Looking at the ARC change you referred to from r325851 https://reviews.freebsd.org/D12163, I am convinced that ARC backpressur= e is completely broken. On my 78GB RAM system with ARC limited to 40GB an= d doing a poudriere build of all LLVM and GCC packages at once in tmpfs I can get swap up near 50GB and yet the ARC remains at 40GB through it all. It's always been slow to give up memory for package builds but it really seems broken right now. =20 --=20 Regards, Bryan Drewery =20 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-current@freebsd.org Wed Apr 4 01:47:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B01A6F84C47 for ; Wed, 4 Apr 2018 01:47:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1867680CCE; Wed, 4 Apr 2018 01:47:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3XWDfPPihLkoz3XWEfBBmf; Tue, 03 Apr 2018 19:47:22 -0600 X-Authority-Analysis: v=2.3 cv=OeS28CbY c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=Kd1tUaAdevIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=8fqvCxzDAAAA:8 a=7Ku_9JyV4qsk_o-Ohk0A:9 a=gwJYkg3bk64PVVus:21 a=RnkS0W7mmbt9ixsp:21 a=CjuIK1q_8ugA:10 a=yJeIQVEa5b5VMVsl9ZYA:9 a=qtpcrbx-0IhQCRVI:21 a=s0mIYAx8frL3NTph:21 a=kKMX0Zkevfrez679:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=xrUD0wEA3vlMLTxm4nS9:22 Received: from [25.85.100.44] (unknown [24.244.29.245]) by spqr.komquats.com (Postfix) with ESMTPSA id A64BC1101; Tue, 3 Apr 2018 18:47:20 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Strange ARC/Swap/CPU on yesterday's -CURRENT Date: Tue, 3 Apr 2018 19:47:21 -0600 To: Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson CC: FreeBSD current Message-Id: <20180404014720.A64BC1101@spqr.komquats.com> X-CMAE-Envelope: MS4wfJ/HXm6UQchj3AbYQXru1sYwqQ3hmeKpLamkPjkF8sbm4bn4Pke4Iwa5cATYDQZzdSldHQWoQbcVBTBqIN/FWyeRqG18+GL9TK72mKMj2FJNSzuKN8MB MCjmaPg8yALWfYmTwFcRF/roFOeodb65tWMS+FJvvxtTk5CUkCTEfjljF4XPdzSApGDkh4sj4AMENcYnN10pbU1lfsmnPoRPrSxS33qUgeQeEpSJD04W1MhR mDTWkNbJ5vmdLQ9rNAayEctl1faKsTv9NoO4pKcJYspTu3M9VDEe3rcZ1puUNZnc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:47:24 -0000 Agreed. I've come to the same conclusion that there may be multiple issues. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Andriy Gapon Sent: 27/03/2018 08:02 To: Bryan Drewery; Peter Jeremy; Jeff Roberson Cc: FreeBSD current Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT On 24/03/2018 01:21, Bryan Drewery wrote: > On 3/20/2018 12:07 AM, Peter Jeremy wrote: >> >> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson w= rote: >>> Also, if you could try going back to r328953 or r326346 and let me know= if=20 >>> the problem exists in either. That would be very helpful. If anyone i= s=20 >>> willing to debug this with me contact me directly and I will send some= =20 >>> test patches or debugging info after you have done the above steps. >> >> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). >> I initially got around the problem by reverting that commit but either >> it or something very similar is still present in 11-stable r331053. >> >> I've seen it in my main server (32GB RAM) but haven't managed to reprodu= ce >> it in smaller VBox guests - one difficulty I faced was artificially fill= ing >> ARC. First, it looks like maybe several different issues are being discussed and possibly conflated in this thread. I see reports related to ZFS, I see rep= orts where ZFS is not used at all. Some people report problems that appeared ve= ry recently while others chime in with "yes, yes, I've always had this problem= ". This does not help to differentiate between problems and to analyze them. > Looking at the ARC change you referred to from r325851 > https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure > is completely broken. Does your being convinced come from the code review or from experiments? If the former, could you please share your analysis? > On my 78GB RAM system with ARC limited to 40GB and > doing a poudriere build of all LLVM and GCC packages at once in tmpfs I > can get swap up near 50GB and yet the ARC remains at 40GB through it > all. It's always been slow to give up memory for package builds but it > really seems broken right now. Well, there are multiple angles. Maybe it's ARC that does not react proper= ly, or maybe it's not being asked properly. It would be useful to monitor the system during its transition to the state= that you reported. There are some interesting DTrace probes in ARC, specificall= y arc-available_memory and arc-needfree are first that come to mind. Their parameters and how frequently they are called are of interest. VM paramete= rs could be of interest as well. A rant. Basically, posting some numbers and jumping to conclusions does not help at= all. Monitoring, graphing, etc does help. ARC is a complex dynamic system. VM (pagedaemon, UMA caches) is a complex dynamic system. They interact in a complex dynamic ways. Sometimes a change in ARC is incorrect and requires a fix. Sometimes a change in VM is incorrect and requires a fix. Sometimes a change in VM requires a change in ARC. These three kinds of problems can all appear as a "problem with ARC". For instance, when vm.lowmem_period was introduced you wouldn't find any me= ntion of ZFS/ARC. But it does affect period between arc_lowmem() calls. Also, pin-pointing a specific commit requires proper bisecting and proper testing to correctly attribute systemic behavior changes to code changes. --=20 Andriy Gapon _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Apr 4 01:53:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B8D7F852BF for ; Wed, 4 Apr 2018 01:53:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC719811EE; Wed, 4 Apr 2018 01:53:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3XcQfPRW4Lkoz3XcSfBCqi; Tue, 03 Apr 2018 19:53:49 -0600 X-Authority-Analysis: v=2.3 cv=OeS28CbY c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=Kd1tUaAdevIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=6VqBrpBaAAAA:8 a=8fqvCxzDAAAA:8 a=lzb0MAms_pIzW377eeoA:9 a=RXG5mFhLMQbsAcR_:21 a=z37ykU1UKxJ3DLQO:21 a=QEXdDO2ut3YA:10 a=kcW0WbjXQlUA:10 a=45Xs7ifGvxIA:10 a=9KCo1u1gBHjnrNLiqAMA:9 a=dEruVAzBn2s-0MCJ:21 a=2uO3SawNETqDo4BZ:21 a=rB7BF9cxiKwZdF4_:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=l6wOqGboJC1rSQv2Z1Bd:22 a=xrUD0wEA3vlMLTxm4nS9:22 Received: from [25.85.100.44] (unknown [24.244.29.245]) by spqr.komquats.com (Postfix) with ESMTPSA id AFFFC1121; Tue, 3 Apr 2018 18:53:45 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Strange ARC/Swap/CPU on yesterday's -CURRENT Date: Tue, 3 Apr 2018 19:53:46 -0600 To: Larry Rosenman , Bryan Drewery , Peter Jeremy , Jeff Roberson CC: FreeBSD current , Andriy Gapon Message-Id: <20180404015345.AFFFC1121@spqr.komquats.com> X-CMAE-Envelope: MS4wfMp1rYncW65iSAeFbdpWRrkTH1OffBP7uvCB98ExIoyui3TwA7tuew4rBiVkz+OnMCmnYSbA1oy9S8gRvq5KdVuRr0xjFxrhZ74EEBlZs64TXujGRS8f MzEs+8lZnq3M+C0sEmpcQ+1qHXUjISCNsftio3LGmeh+l6L8ROSBryeDG8Ykc3+HmMu0rttmVuOd7aXlY5EPH4Q5VbBySpZ599sqsDGlnMyNERaYtX0SUJG8 SQkvW/d2cgkojSn0C8C5BYIN/5LkAPiFQTPxf3O8xVyyv/z+TFaxpqkPzrtikx1poa+mbDWGTPljXtY8cb+G4q95Lz1HvS3YGwdvUr8CdEM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:53:51 -0000 Try arbitrarily reducing arc_max through sysctl. ARC is immediately reduced= and free memory increased however wired pages remains the same. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Larry Rosenman Sent: 03/04/2018 19:27 To: Cy Schubert; Bryan Drewery; Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT When my full backups run (1st Sunday -> Monday of the month) the box become= s unusable after 5-10 hours of that backup with LOTS of SWAP usage And ARC using 100+G.=20 Is anyone looking into this? --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =EF=BB=BFOn 4/3/18, 8:24 PM, "Cy Schubert" wrote: +1 =20 However under certain circumstances it will release some memory. To rep= roduce, when bsdtar unpacks some tarballs (when building certain ports) tar= will use 12 GB or more forcing ARC to release memory. =20 BTW, I haven't stopped to grok whether the bsdtar issue is local to me = or another problem yet. =20 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. =20 Cy Schubert or The need of the many outweighs the greed of the few. --- =20 -----Original Message----- From: Bryan Drewery Sent: 23/03/2018 17:23 To: Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT =20 On 3/20/2018 12:07 AM, Peter Jeremy wrote: >=20 > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >> Also, if you could try going back to r328953 or r326346 and let me k= now if=20 >> the problem exists in either. That would be very helpful. If anyon= e is=20 >> willing to debug this with me contact me directly and I will send so= me=20 >> test patches or debugging info after you have done the above steps. >=20 > I ran into this on 11-stable and tracked it to r326619 (MFC of r32585= 1). > I initially got around the problem by reverting that commit but eithe= r > it or something very similar is still present in 11-stable r331053. >=20 > I've seen it in my main server (32GB RAM) but haven't managed to repr= oduce > it in smaller VBox guests - one difficulty I faced was artificially f= illing > ARC. >=20 =20 Looking at the ARC change you referred to from r325851 https://reviews.freebsd.org/D12163, I am convinced that ARC backpressur= e is completely broken. On my 78GB RAM system with ARC limited to 40GB an= d doing a poudriere build of all LLVM and GCC packages at once in tmpfs I can get swap up near 50GB and yet the ARC remains at 40GB through it all. It's always been slow to give up memory for package builds but it really seems broken right now. =20 --=20 Regards, Bryan Drewery =20 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-current@freebsd.org Wed Apr 4 02:46:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5626AF883D9 for ; Wed, 4 Apr 2018 02:46:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC09D83BE8; Wed, 4 Apr 2018 02:46:23 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=p79vU2gtp9OBBzPMvm2hxe0dY6JgmPGkLzy4+twZ6a4=; b=pygZBG0+IqR2hvIWXjw8p1BNuu Rdzj0EYHFFvLZAG2m10amfkW7d7173wg6ODPC/Yz0CeI9aO9U1M/DV1fekoOSks58Yp80tAOUAyiE MwKHVR+VyqhOguTmuZqUqSx5Omnfb9IjB/awI6ZWf+WbjC68HS6cbRRS4m+AJEliJXQw=; Received: from [2600:1700:210:b18f:3427:71c7:7f27:d86c] (port=49209 helo=[192.168.200.50]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1f3YRK-00025p-Ez; Tue, 03 Apr 2018 21:46:22 -0500 User-Agent: Microsoft-MacOutlook/10.d.0.180401 Date: Tue, 03 Apr 2018 21:46:21 -0500 Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT From: Larry Rosenman To: Cy Schubert , Bryan Drewery , Peter Jeremy , Jeff Roberson CC: FreeBSD current , Andriy Gapon Message-ID: Thread-Topic: Strange ARC/Swap/CPU on yesterday's -CURRENT References: <20180404015345.AFFFC1121@spqr.komquats.com> In-Reply-To: <20180404015345.AFFFC1121@spqr.komquats.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:46:24 -0000 Thanks for that hint. I thought that arc_max was a tunable, but now knowin= g it's sysctl, that helps a lot. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =EF=BB=BFOn 4/3/18, 8:54 PM, "Cy Schubert" wrote: Try arbitrarily reducing arc_max through sysctl. ARC is immediately red= uced and free memory increased however wired pages remains the same. =20 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. =20 Cy Schubert or The need of the many outweighs the greed of the few. --- =20 -----Original Message----- From: Larry Rosenman Sent: 03/04/2018 19:27 To: Cy Schubert; Bryan Drewery; Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT =20 When my full backups run (1st Sunday -> Monday of the month) the box be= comes unusable after 5-10 hours of that backup with LOTS of SWAP usage And ARC using 100+G.=20 =20 Is anyone looking into this? =20 =20 =20 --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =EF=BB=BFOn 4/3/18, 8:24 PM, "Cy Schubert" wrote: =20 +1 =20 However under certain circumstances it will release some memory. To= reproduce, when bsdtar unpacks some tarballs (when building certain ports) = tar will use 12 GB or more forcing ARC to release memory. =20 BTW, I haven't stopped to grok whether the bsdtar issue is local to= me or another problem yet. =20 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. =20 Cy Schubert or The need of the many outweighs the greed of the few. --- =20 -----Original Message----- From: Bryan Drewery Sent: 23/03/2018 17:23 To: Peter Jeremy; Jeff Roberson Cc: FreeBSD current; Andriy Gapon Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT =20 On 3/20/2018 12:07 AM, Peter Jeremy wrote: >=20 > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >> Also, if you could try going back to r328953 or r326346 and let = me know if=20 >> the problem exists in either. That would be very helpful. If a= nyone is=20 >> willing to debug this with me contact me directly and I will sen= d some=20 >> test patches or debugging info after you have done the above ste= ps. >=20 > I ran into this on 11-stable and tracked it to r326619 (MFC of r3= 25851). > I initially got around the problem by reverting that commit but e= ither > it or something very similar is still present in 11-stable r33105= 3. >=20 > I've seen it in my main server (32GB RAM) but haven't managed to = reproduce > it in smaller VBox guests - one difficulty I faced was artificial= ly filling > ARC. >=20 =20 Looking at the ARC change you referred to from r325851 https://reviews.freebsd.org/D12163, I am convinced that ARC backpre= ssure is completely broken. On my 78GB RAM system with ARC limited to 40G= B and doing a poudriere build of all LLVM and GCC packages at once in tmp= fs I can get swap up near 50GB and yet the ARC remains at 40GB through i= t all. It's always been slow to give up memory for package builds bu= t it really seems broken right now. =20 --=20 Regards, Bryan Drewery =20 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" =20 =20 =20 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-current@freebsd.org Wed Apr 4 04:23:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0961F8D738 for ; Wed, 4 Apr 2018 04:23:07 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50CEA87684; Wed, 4 Apr 2018 04:23:07 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id d6so22667516iog.1; Tue, 03 Apr 2018 21:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+j//cLfi5u6G80UlaN+sYZs9F6Uaser6Gkf4pLIrfZE=; b=BsAHaUrnpruqaEF6LHbG+eX0klkn7pTSy4+Rb+vbR6aDgwgelctHP2raQHvMPFF9Qd q4oFUoW4et/zOMuNrXUYHu6ZdGMuUqoMQGrwZAT3ZHgiq9LldAfM5WVXQWnu9DLO9FPf SeDzz+j6Jya08Yxp5DrSPfqw7V7OJKBUcHXxHfG9TtyJHXc4QsFUScVAemSEH0fya4Kn 8i/dPsmYQx1I/4n8ZE4PJuPyYlMCN6j/MQZQKq2YNNRGLcWaxu3vuotK/81Km+j5FpgZ flE39Tba3zIbqd3arb5gxXF54yipl9fsKqiFXx2LxTsr1GCojZpeVGF3NvA96JOH5KTi SDQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+j//cLfi5u6G80UlaN+sYZs9F6Uaser6Gkf4pLIrfZE=; b=DgP2g+6/C9GABPodQi5ONUpK8CoeRQM0Gulc1zW5Nw8OWbl8XUItJbGoR70aBXwI8T 3xkNC2x/j0i9osgAc4PbhPDz+H9Y3B7gglXFm1gDQC1TPFDHzjk5Dec5W8UGwPD8yteN /4Yn6x2/P+cXyHWaFz7ctM2LAEufFvVcDzMhx7/y7exP00uyFOCWp/KBWdJFoys3pQ0L ArLfQH2nb7eVAfhvnaJXoCglEOgfKPgXZRCfCqgcBGSFWLImmGIC8CftUtFYgP1/mOOj nnSN17uOpDGAndtEH2mdvjsH/LFw0W2NpKKR0d8NAF5HodNowX82miott69ihys9+MnX I8Lg== X-Gm-Message-State: ALQs6tCNDe2boD8IrUi+wDnRO2p3GXrC7TaYz8x1Gjn401iUaW2iQ6d+ heQKWtwzhkvZK/08ryWpUBoDw8+rfYqZbYwY1w== X-Google-Smtp-Source: AIpwx4/uKKRqLy1Rf8/lUSVKjZzmRzjD65xyv4LBCD60z4WiMzR1phFbkm2Tv0kPPRvZFXsdRurrQ30Mzstl9qy2FkE= X-Received: by 10.107.8.32 with SMTP id 32mr14077961ioi.136.1522815786336; Tue, 03 Apr 2018 21:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Tue, 3 Apr 2018 21:23:05 -0700 (PDT) In-Reply-To: References: <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> From: Zaphod Beeblebrox Date: Wed, 4 Apr 2018 00:23:05 -0400 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Kyle Evans Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:23:08 -0000 If you're thinking on it, you should know that the DVD version works. The difference, AFAICT, is that it simply calls loader.efi directly. Ie: bootx64.efi is loader.efi, not boot1.efi. Loader.efi doesn't seem to change the screen mode when it starts. When the kernel starts afterwards, this all just works. I assume loader.efi works here because CD9660 is a format supported by EFI. Thus loader.efi can directly read it. That and/or loader can work with the device is was started from. When I start boot1.efi on this system, it changes mode, then it continues. ... so if you've got a boot1.efi that doesn't change mode, can you post that binary for me to try ... ? On Tue, Apr 3, 2018 at 4:48 PM, Kyle Evans wrote: > On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote: > > Hi, > > > > Right- so, `gop set 0` should've immediately cleared your screen and > > put it into 1920x1080, full stop. If it did not, I think that's > > indicative of some kind of interestingly broken firmware... > > > > Regardless! We're clearly bad at trying to set a mode before the > > kernel starts, so r331904 sets the default max resolution in such a > > way that we just don't change the resolution by default anymore and > > interested parties can bump that up if they want to try it. This > > Thursday's snapshots should have this included. > > After reviewing the video again and discussing it with manu, I don't > think that commit's going to solve your problem at all... we'll need > to re-think this one a bit more. > > > I think if we're going to change modes as a default, we should have > > some way for vt/efifb to use EFIRT or be notified by EFIRT of > > supported resolutions so that vt/efifb can hopefully just handle it > > all and do it properly. This approach would be more similar I guess to > > how KMS drivers operate, and less fragile than what we're seeing with > > these different approaches we've taken. > > > From owner-freebsd-current@freebsd.org Wed Apr 4 04:43:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CCCFF8E981 for ; Wed, 4 Apr 2018 04:43:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B61F788611; Wed, 4 Apr 2018 04:43:04 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w344iA3B071297 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Apr 2018 04:44:12 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w344gswt042547 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2018 21:42:55 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Tue, 3 Apr 2018 21:42:48 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Andriy Gapon cc: Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: Message-ID: References: <20180306173455.oacyqlbib4sbafqd@ler-imac.lerctr.org> <201803061816.w26IGaW5050053@pdx.rh.CN85.dnsmgr.net> <20180306193645.vv3ogqrhauivf2tr@ler-imac.lerctr.org> <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:43:05 -0000 On 3 Apr, Don Lewis wrote: > On 1 Apr, Don Lewis wrote: >> On 27 Mar, Andriy Gapon wrote: >>> On 24/03/2018 01:21, Bryan Drewery wrote: >>>> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>>>> >>>>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson wrote: >>>>>> Also, if you could try going back to r328953 or r326346 and let me know if >>>>>> the problem exists in either. That would be very helpful. If anyone is >>>>>> willing to debug this with me contact me directly and I will send some >>>>>> test patches or debugging info after you have done the above steps. >>>>> >>>>> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). >>>>> I initially got around the problem by reverting that commit but either >>>>> it or something very similar is still present in 11-stable r331053. >>>>> >>>>> I've seen it in my main server (32GB RAM) but haven't managed to reproduce >>>>> it in smaller VBox guests - one difficulty I faced was artificially filling >>>>> ARC. >>> >>> First, it looks like maybe several different issues are being discussed and >>> possibly conflated in this thread. I see reports related to ZFS, I see reports >>> where ZFS is not used at all. Some people report problems that appeared very >>> recently while others chime in with "yes, yes, I've always had this problem". >>> This does not help to differentiate between problems and to analyze them. >>> >>>> Looking at the ARC change you referred to from r325851 >>>> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure >>>> is completely broken. >>> >>> Does your being convinced come from the code review or from experiments? >>> If the former, could you please share your analysis? >>> >>>> On my 78GB RAM system with ARC limited to 40GB and >>>> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I >>>> can get swap up near 50GB and yet the ARC remains at 40GB through it >>>> all. It's always been slow to give up memory for package builds but it >>>> really seems broken right now. >>> >>> Well, there are multiple angles. Maybe it's ARC that does not react properly, >>> or maybe it's not being asked properly. >>> >>> It would be useful to monitor the system during its transition to the state that >>> you reported. There are some interesting DTrace probes in ARC, specifically >>> arc-available_memory and arc-needfree are first that come to mind. Their >>> parameters and how frequently they are called are of interest. VM parameters >>> could be of interest as well. >>> >>> A rant. >>> >>> Basically, posting some numbers and jumping to conclusions does not help at all. >>> Monitoring, graphing, etc does help. >>> ARC is a complex dynamic system. >>> VM (pagedaemon, UMA caches) is a complex dynamic system. >>> They interact in a complex dynamic ways. >>> Sometimes a change in ARC is incorrect and requires a fix. >>> Sometimes a change in VM is incorrect and requires a fix. >>> Sometimes a change in VM requires a change in ARC. >>> These three kinds of problems can all appear as a "problem with ARC". >>> >>> For instance, when vm.lowmem_period was introduced you wouldn't find any mention >>> of ZFS/ARC. But it does affect period between arc_lowmem() calls. >>> >>> Also, pin-pointing a specific commit requires proper bisecting and proper >>> testing to correctly attribute systemic behavior changes to code changes. >> >> I just upgraded my main package build box (12.0-CURRENT, 8 cores, 32 GB >> RAM) from r327616 to r331716. I was seeing higher swap usage and larger >> ARC sizes before the upgrade than I remember from the distant past, but >> ARC was still at least somewhat responsive to memory pressure and I >> didn't notice any performance issues. >> >> After the upgrade, ARC size seems to be pretty unresponsive to memory >> demand. Currently the machine is near the end of a poudriere run to >> build my usual set of ~1800 ports. The only currently running build is >> chromium and the machine is paging heavily. Settings of interest are: >> USE_TMPFS="wrkdir data localbase" >> ALLOW_MAKE_JOBS=yes >> >> last pid: 96239; load averages: 1.86, 1.76, 1.83 up 3+14:47:00 12:38:11 >> 108 processes: 3 running, 105 sleeping >> CPU: 18.6% user, 0.0% nice, 2.4% system, 0.0% interrupt, 79.0% idle >> Mem: 129M Active, 865M Inact, 61M Laundry, 29G Wired, 1553K Buf, 888M Free >> ARC: 23G Total, 8466M MFU, 10G MRU, 5728K Anon, 611M Header, 3886M Other >> 17G Compressed, 32G Uncompressed, 1.88:1 Ratio >> Swap: 40G Total, 17G Used, 23G Free, 42% Inuse, 4756K In >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN >> 96239 nobody 1 76 0 140M 93636K CPU5 5 0:01 82.90% clang- >> 96238 nobody 1 75 0 140M 92608K CPU7 7 0:01 80.81% clang- >> 5148 nobody 1 20 0 590M 113M swread 0 0:31 0.29% clang- >> 57290 root 1 20 0 12128K 2608K zio->i 7 8:11 0.28% find >> 78958 nobody 1 20 0 838M 299M swread 0 0:23 0.19% clang- >> 97840 nobody 1 20 0 698M 140M swread 4 0:27 0.13% clang- >> 96066 nobody 1 20 0 463M 104M swread 1 0:32 0.12% clang- >> 11050 nobody 1 20 0 892M 154M swread 2 0:39 0.12% clang- >> >> Pre-upgrade I was running r327616, which is newer than either of the >> commits that Jeff mentioned above. It seems like there has been a >> regression since then. >> >> I also don't recall seeing this problem on my Ryzen box, though it has >> 2x the core count and 2x the RAM. The last testing that I did on it was >> with r329844. > > I reconfigured my Ryzen box to be more similar to my default package > builder by disabling SMT and half of the RAM, to limit it to 8 cores > and 32 GB and then started bisecting to try to track down the problem. > For each test, I first filled ARC by tarring /usr/ports/distfiles to > /dev/null. The commit range that I was searching was r329844 to > r331716. I narrowed the range to r329844 to r329904. With r329904 > and newer, ARC is totally unresponsive to memory pressure and the > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired > RAM, so there is not much leftover for getting useful work done. Active > memory and free memory both hover under 1GB each. Looking at the > commit logs over this range, the most likely culprit is: > > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines > > Add a generic Proportional Integral Derivative (PID) controller algorithm and > use it to regulate page daemon output. > > This provides much smoother and more responsive page daemon output, anticipating > demand and avoiding pageout stalls by increasing the number of pages to match > the workload. This is a reimplementation of work done by myself and mlaier at > Isilon. > > > It is quite possible that the recent fixes to the PID controller will > fix the problem. Not that r329844 was trouble free ... I left tar > running over lunchtime to fill ARC and the OOM killer nuked top, tar, > ntpd, both of my ssh sessions into the machine, and multiple instances > of getty while I was away. I was able to log in again and successfully > run poudriere, and ARC did respond to the memory pressure and cranked > itself down to about 5 GB by the end of the run. I did not see the same > problem with tar when I did the same with r329904. I just tried r331966 and see no improvement. No OOM process kills during the tar run to fill ARC, but with ARC filled, the machine is thrashing itself at the start of the poudriere run while trying to build ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to memory demand. I've seen no decrease in ARC size or wired memory since starting poudriere. last pid: 75652; load averages: 0.46, 0.27, 0.25 up 0+02:03:48 21:33:00 48 processes: 1 running, 47 sleeping CPU: 0.7% user, 0.0% nice, 0.8% system, 0.1% interrupt, 98.4% idle Mem: 4196K Active, 328K Inact, 148K Laundry, 30G Wired, 506M Free ARC: 29G Total, 309M MFU, 28G MRU, 3767K Anon, 103M Header, 79M Other 27G Compressed, 29G Uncompressed, 1.05:1 Ratio Swap: 80G Total, 234M Used, 80G Free, 2348K In, 420K Out PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1340 root 1 52 0 13048K 1024K nanslp 6 0:10 0.72% sh 41806 nobody 1 20 0 133M 1440K swread 6 0:17 0.31% cc 42554 nobody 1 20 0 129M 1048K swread 6 0:12 0.22% cc 934 dl 1 20 0 19124K 592K select 6 0:03 0.14% sshd 938 dl 1 20 0 13596K 740K CPU7 7 0:07 0.12% top 40784 nobody 1 20 0 5024K 104K select 5 0:00 0.03% make 41142 nobody 1 20 0 5024K 124K select 6 0:00 0.01% make 638 root 1 20 0 11344K 252K swread 7 0:00 0.01% syslogd 41428 nobody 1 20 0 5024K 124K select 4 0:00 0.01% make 40782 nobody 1 20 0 5024K 124K select 4 0:00 0.01% make 41164 nobody 1 20 0 5024K 124K select 7 0:00 0.01% make 1050 root 1 23 0 13032K 468K select 0 0:06 0.00% sh 848 root 1 20 0 11400K 492K nanslp 5 0:00 0.00% cron 36198 root 1 20 0 13048K 396K select 7 0:00 0.00% sh From owner-freebsd-current@freebsd.org Wed Apr 4 04:45:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FA8FF8EBA6 for ; Wed, 4 Apr 2018 04:45:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F90488771 for ; Wed, 4 Apr 2018 04:45:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w344kTaC071302 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Apr 2018 04:46:30 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w344gsww042547 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2018 21:45:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Tue, 3 Apr 2018 21:45:13 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Cy Schubert cc: Larry Rosenman , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current , Andriy Gapon In-Reply-To: <20180404015345.AFFFC1121@spqr.komquats.com> Message-ID: References: <20180404015345.AFFFC1121@spqr.komquats.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:45:22 -0000 On 3 Apr, Cy Schubert wrote: > Try arbitrarily reducing arc_max through sysctl. ARC is immediately > reduced and free memory increased however wired pages remains the > same. One thing that I've noticed is that with r329844 and earlier is that there can be a difference of multiple GB between the ARC size and the amount of wired memory. With r329904 and newer the difference seems to be pretty steady at 1 GB. From owner-freebsd-current@freebsd.org Wed Apr 4 13:19:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B80E0F8E29C for ; Wed, 4 Apr 2018 13:19:51 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4040F7A912; Wed, 4 Apr 2018 13:19:51 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd07.aul.t-online.de (fwd07.aul.t-online.de [172.20.27.150]) by mailout09.t-online.de (Postfix) with SMTP id A41F4425ACFB; Wed, 4 Apr 2018 15:19:43 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (rIQ1sTZYohnT6btbQrgVDXah6LVOVA1-TCxo2yIxWLYgcdhxhGoCeKt9n4eeNkSgLy@[84.154.99.226]) by fwd07.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f3iK3-1o6jEO0; Wed, 4 Apr 2018 15:19:31 +0200 Subject: Is kern.sched.preempt_thresh=0 a sensible default? (was: Re: Extremely low disk throughput under high compute load) From: Stefan Esser To: "M. Warner Losh" Cc: FreeBSD Current References: <1d188cb0-ebc8-075f-ed51-57641ede1fd6@freebsd.org> Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Message-ID: <49fa8de4-e164-0642-4e01-a6188992c32e@freebsd.org> Date: Wed, 4 Apr 2018 15:19:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1d188cb0-ebc8-075f-ed51-57641ede1fd6@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: rIQ1sTZYohnT6btbQrgVDXah6LVOVA1-TCxo2yIxWLYgcdhxhGoCeKt9n4eeNkSgLy X-TOI-MSGID: ec6d4659-8586-4ac6-8349-bd582f9c7fc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 13:19:52 -0000 Am 02.04.18 um 00:18 schrieb Stefan Esser: > Am 01.04.18 um 18:33 schrieb Warner Losh: >> On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser > > wrote: >> >> My i7-2600K based system with 24 GB RAM was in the midst of a buildworld -j8 >> (starting from a clean state) which caused a load average of 12 for more than >> 1 hour, when I decided to move a directory structure holding some 10 GB to its >> own ZFS file system. File sizes varied, but were mostly in the range 0f 500KB. >> >> I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus there >> was nearly no disk activity caused by the buildworld. >> >> The copying proceeded at a rate of at most 10 MB/s, but most of the time less >> than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus a >> much better priority than the compute bound compiler processes, but it got >> just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled >> at such a low rate, that it only managed to issue a few controller writes per >> second. >> >> The system is healthy and does not show any problems or anomalies under >> normal use (e.g., file copies are fast, without the high compute load). >> >> This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging. >> >> Is this a regression in -CURRENT? >> >> Does 'sync' push a lot of I/O to the disk? > > Each sync takes 0.7 to 1.5 seconds to complete, but since reading is so > slow, not much is written. > > Normal gstat output for the 3 drives the RAIDZ1 consists of: > > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 2 2 84 39.1 0 0 0.0 7.8 ada0 > 0 4 4 92 66.6 0 0 0.0 26.6 ada1 > 0 6 6 259 66.9 0 0 0.0 36.2 ada3 > dT: 1.058s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 1 1 60 70.6 0 0 0.0 6.7 ada0 > 0 3 3 68 71.3 0 0 0.0 20.2 ada1 > 0 6 6 242 65.5 0 0 0.0 28.8 ada3 > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 5 5 192 44.8 0 0 0.0 22.4 ada0 > 0 6 6 160 61.9 0 0 0.0 26.5 ada1 > 0 6 6 172 43.7 0 0 0.0 26.2 ada3 > > This includes the copy process and the reads caused by "make -j 8 world" > (but I assume that all the source files are already cached in ARC). I have identified the cause of the extremely low I/O performance (2 to 6 read operations scheduled per second). The default value of kern.sched.preempt_thresh=0 does not give any CPU to the I/O bound process unless a (long) time slice expires (kern.sched.quantum=94488 on my system with HZ=1000) or one of the CPU bound processes voluntarily gives up the CPU (or exits). Any non-zero value of preemt_thresh lets the system perform I/O in parallel with the CPU bound processes, again. I'm not sure about the bias relative to the PRI values displayed by top, but for me a process with PRI above 72 (in top) should be eligible for preemption. What value of preempt_thresh should I use to get that behavior? And, more important: Is preempt_thresh=0 a reasonable default??? This prevents I/O bound processes from making reasonable progress if all CPU cores/threads are busy. In my case, performance dropped from > 10 MB/s to just a few hundred KB per second, i.e. by a factor of 30. (The %busy values in my previous mail are misleading: At 10 MB/s the disk was about 70% busy ...) Should preempt_thresh be set to some (possibly high, to only preempt long running processes) value? Regards, STefan From owner-freebsd-current@freebsd.org Wed Apr 4 12:50:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A579DF8BE4D for ; Wed, 4 Apr 2018 12:50:15 +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 45CBA789B3 for ; Wed, 4 Apr 2018 12:50:15 +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 6A8F326218 for ; Wed, 4 Apr 2018 12:50:14 +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 w34CoEQC022835 for ; Wed, 4 Apr 2018 12:50:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w34CoEFk022834 for freebsd-current@FreeBSD.org; Wed, 4 Apr 2018 12:50:14 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-current@FreeBSD.org Subject: [Bug 227259] accept() does not wakeup on shutdown()/close() Date: Wed, 04 Apr 2018 12:50:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-Mailman-Approved-At: Wed, 04 Apr 2018 13:43:39 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 12:50:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227259 rozhuk.im@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-current@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 4 12:52:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBC82F8C163 for ; Wed, 4 Apr 2018 12:52:07 +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 607D578DA2 for ; Wed, 4 Apr 2018 12:52:07 +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 B4B6B2635C for ; Wed, 4 Apr 2018 12:52:06 +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 w34Cq63j031173 for ; Wed, 4 Apr 2018 12:52:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w34Cq6iS031172 for freebsd-current@FreeBSD.org; Wed, 4 Apr 2018 12:52:06 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-current@FreeBSD.org Subject: [Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps Date: Wed, 04 Apr 2018 12:52:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: 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-Mailman-Approved-At: Wed, 04 Apr 2018 13:43:46 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 12:52:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227259 rozhuk.im@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|accept() does not wakeup on |accept()/poll() and |shutdown()/close() |shutdown()/close() - not | |work as in FreeBSD10, may | |broke many apps --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 4 12:56:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EEF9F8C646 for ; Wed, 4 Apr 2018 12:56:35 +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 27C0779291 for ; Wed, 4 Apr 2018 12:56:35 +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 6D8F426370 for ; Wed, 4 Apr 2018 12:56:34 +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 w34CuYrc040839 for ; Wed, 4 Apr 2018 12:56:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w34CuYsi040838 for freebsd-current@FreeBSD.org; Wed, 4 Apr 2018 12:56:34 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-current@FreeBSD.org Subject: [Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps Date: Wed, 04 Apr 2018 12:56:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-Mailman-Approved-At: Wed, 04 Apr 2018 13:43:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 12:56:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227259 --- Comment #2 from rozhuk.im@gmail.com --- I do not understand why shutdown() does not generates POLLHUP/EV_EOF (EV_ER= ROR then add shutdowned socket) for poll() and kqueue(). --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 4 13:08:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7250FF8D3D9 for ; Wed, 4 Apr 2018 13:08:33 +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 074E679C3D for ; Wed, 4 Apr 2018 13:08:33 +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 2DD76264EA for ; Wed, 4 Apr 2018 13:08:32 +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 w34D8Wow079562 for ; Wed, 4 Apr 2018 13:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w34D8WjS079560 for freebsd-current@FreeBSD.org; Wed, 4 Apr 2018 13:08:32 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-current@FreeBSD.org Subject: [Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps Date: Wed, 04 Apr 2018 13:08:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-Mailman-Approved-At: Wed, 04 Apr 2018 13:44:02 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 13:08:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227259 --- Comment #3 from rozhuk.im@gmail.com --- Why close() does not wakes thread that sleep on accept()? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 4 14:37:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B70FF93A13 for ; Wed, 4 Apr 2018 14:37:39 +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 27FB27EE4B for ; Wed, 4 Apr 2018 14:37:39 +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 66F7327141 for ; Wed, 4 Apr 2018 14:37:38 +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 w34Ebcgx006583 for ; Wed, 4 Apr 2018 14:37:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w34Ebcse006581 for freebsd-current@FreeBSD.org; Wed, 4 Apr 2018 14:37:38 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-current@FreeBSD.org Subject: [Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps Date: Wed, 04 Apr 2018 14:37:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-Mailman-Approved-At: Wed, 04 Apr 2018 15:38:51 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:37:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227259 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-current@FreeBSD.org |cem@freebsd.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 4 16:23:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 914F5F9AA33 for ; Wed, 4 Apr 2018 16:23:36 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15F3A83E7C; Wed, 4 Apr 2018 16:23:35 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-wm0-f49.google.com with SMTP id r131so44083349wmb.2; Wed, 04 Apr 2018 09:23:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tXRi+KyQXeJnQqZgexrNdAPpMYhbhAhG4+YWqWs8dtY=; b=p6Ib7pRxf6uhhY9HSXr5X0XRmOzCUBzAScw2Xg7MdROGTb5Paq87bpR4YqkRqdfVXE E5GVyjZ6CVPnUjODgVBZsv0gqtlNHzAiVWlHyJPNDjlCK6zJxnaW8EQxhvtjOAXja2LP 6RTvh+K3AX4UT2Lxw67UXnnzY2GJbTHmGkTsyGj6Kzw0r+e/QgyyLmehj64hZBk+PC9W Fm/8SrcpRYyLKjVAnVa+zn92Aro4y3WH2UsMslj3a0JNrd5g2uIRCjoGbZl5Dkr2PA/i mCF53Y1+oV3Gg7OaoxzsfxVd5ePiL8qpORTehs9Sq7Nm9vQjYKrjaJ+UfuY98X0SwEj+ 30jA== X-Gm-Message-State: AElRT7HSiJOHBH+kTQseJjpZRx7ffjIPEu8FpDHbL35XnOowZJD4xUte BOcOh4Wr1pHW4B39JGOhWsZEVDvO X-Google-Smtp-Source: AIpwx491ZXb46CgUe5J/aWa5EVlL5XLU7EKPQCZsOqGTa/B4LRMLGLdTgk0xams1a5UbOCgugGcsAw== X-Received: by 10.80.189.193 with SMTP id z1mr20719795edh.119.1522857450149; Wed, 04 Apr 2018 08:57:30 -0700 (PDT) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com. [209.85.128.175]) by smtp.gmail.com with ESMTPSA id m31sm3357649ede.35.2018.04.04.08.57.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 08:57:29 -0700 (PDT) Received: by mail-wr0-f175.google.com with SMTP id u46so23541877wrc.11; Wed, 04 Apr 2018 08:57:29 -0700 (PDT) X-Received: by 2002:a19:c4c8:: with SMTP id u191-v6mr11922568lff.109.1522857449670; Wed, 04 Apr 2018 08:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Wed, 4 Apr 2018 08:57:08 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Wed, 4 Apr 2018 10:57:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Kyle Evans Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:23:36 -0000 On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans wrote: > Hello! > > A number of changes have gone in recently pertaining to UEFI booting > and UEFI runtime services. The changes with the most damaging > potential are: > > We now put UEFI runtime services into virtual address mode, fixing > runtime services with U-Boot/UEFI as well as the firmware > implementation in many Lenovos. The previously observed behavior was a > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic > just loading efirt.ko or compiling EFIRT into the kernel. > > Graphics mode selection is now done differently to avoid regression > caused by r327058 while still achieving the same effect. The observed > regression was that the kernel would usually end up drawing > incorrectly at the old resolution on a subset of the screen, due to > incorrect framebuffer information. > > Explicit testing of these changes, the latest of which happened in > r331326, and any feedback from this testing would be greatly > appreciated. Testing should be done with either `options EFIRT` in > your kernel config or efirt.ko loaded along with updated bootloader > bits. > > I otherwise plan to MFC commits involved with the above-mentioned > changes by sometime in the first week of April, likely no earlier than > two (2) weeks from now on April 4th. > > Thanks, > > Kyle Evans As partially promised, the non-graphics related changes have been MFC'd to stable/11 today as r332028. The graphics related changes are going to simmer longer and probably get ripped out, because we're bad at this. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Wed Apr 4 16:45:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C9DF9C0FE for ; Wed, 4 Apr 2018 16:45:20 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02F61851A6; Wed, 4 Apr 2018 16:45:19 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-wm0-f53.google.com with SMTP id w2so17678738wmw.1; Wed, 04 Apr 2018 09:45:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+syGdU2YzefcyGUv9KonOhLXPcd2l6/ROz2tf6+9DyM=; b=htHZVrbv45Jrs9qN3qfldCtN/vjJBvb5cKHNymlkoHecQSD/ovsIkQpskxjWtshaAt gUQj6KVBcBCfxKTlUc7wooTVdOGE3fI4Ba/ExpucjHJQ9Y2mDRcqkbF2tgNwDMoM2sSf Px6IAPVAy0vCLRxxoNu2OziQt03/lzsHZ7hISq0MApEJ6ARvCspThfGEAxB9VSQ0mHW1 qcoX1+p5xJ29jLOYL7ux5J5PKZ2dFbWr2IcQx+QfxZXNzv1POWlOhzP5Oy0Gs/+6U5he lNWeggsgnI15hMiw/Zvb/saAJJ2LxQ8075yH4109kgIMo7ogZjOT+w1a4ll75gJzJPU0 Ea7Q== X-Gm-Message-State: ALQs6tA8uK7yoqTja5aouKGP7hNN0701boGDbohgpqMWkKTQNKiZ67on HIO7Mg841LRir8keZAiD7Tz1YqJL X-Google-Smtp-Source: AIpwx4+g8fLWZ188HMNBGNGa9oMlq46YOwRC++5DUyiKq/+uIx0bAkf0UK4JAOuaaKKcjyI1bdwWdQ== X-Received: by 10.46.134.89 with SMTP id i25mr8739079ljj.121.1522860312923; Wed, 04 Apr 2018 09:45:12 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id w8sm955416ljj.11.2018.04.04.09.45.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 09:45:12 -0700 (PDT) Subject: Re: Is kern.sched.preempt_thresh=0 a sensible default? To: Stefan Esser , "M. Warner Losh" Cc: FreeBSD Current References: <1d188cb0-ebc8-075f-ed51-57641ede1fd6@freebsd.org> <49fa8de4-e164-0642-4e01-a6188992c32e@freebsd.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <32d6305b-3d57-4d37-ba1b-51631e994520@FreeBSD.org> Date: Wed, 4 Apr 2018 19:45:10 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <49fa8de4-e164-0642-4e01-a6188992c32e@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:45:20 -0000 On 04/04/2018 16:19, Stefan Esser wrote: > I have identified the cause of the extremely low I/O performance (2 to 6 read > operations scheduled per second). > > The default value of kern.sched.preempt_thresh=0 does not give any CPU to the > I/O bound process unless a (long) time slice expires (kern.sched.quantum=94488 > on my system with HZ=1000) or one of the CPU bound processes voluntarily gives > up the CPU (or exits). > > Any non-zero value of preemt_thresh lets the system perform I/O in parallel > with the CPU bound processes, again. Let me guess... you have a custom kernel configuration and, unlike GENERIC (assuming x86), it does not have 'options PREEMPTION'? -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Apr 4 17:23:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2A6EF9E6A6 for ; Wed, 4 Apr 2018 17:23:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36C308712E for ; Wed, 4 Apr 2018 17:23:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-wr0-f178.google.com with SMTP id 80so23993687wrb.2 for ; Wed, 04 Apr 2018 10:23:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jL/tF5COeU9t9NUO3v5ifZZ91JPzgCTQgusGyLT8cEg=; b=Ph6MsUTTryV1mLMsdC1IujoQX5acH74gw98iaMsVXr+OQYkOAeXu4uusutnkOxfw81 W6MDlLGt/lvmFWDn7LdIJTyCRlTCSEgYRPgcNqDPuIy5LPi7yuOnkZuc4FoZMUr8zKGn ZsgzTVCbnXLcCMkeY/5drmbIIhE/UjvvUgx/400G/xxzPp1sK8BzaXvE0pTiVg6HAQJ4 YoHkNdURuAFB399PIMS9RUFXdf48N2J8AgfewG9fWoXkZSicstM+Q9eC6TLC0SB5nA2q DC1qw/JfFvNDQodWcWSZBW6a1QHSp+xLqk/zaqRrBXhxULNgkq1P/liLGMOJ957BNG0A J5mw== X-Gm-Message-State: ALQs6tC0E/2jA15NMFHi0qKgw+71PSjs8gzUMzRxtcb4TXfyk/MFVDlq zTlWIOpRVyZ9g9A+yCLEW2Ie/R/s X-Google-Smtp-Source: AIpwx49a1kodAlkAU+QKtP5AowuxH2gyqNIup0V2zfOtkmc0e8Kz+FgO2U801tO5erFDEm3PdXcRSQ== X-Received: by 2002:a19:d2c1:: with SMTP id j184-v6mr6474183lfg.62.1522862220942; Wed, 04 Apr 2018 10:17:00 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 63-v6sm1097278lfr.61.2018.04.04.10.16.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:17:00 -0700 (PDT) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Millard Cc: freebsd-current@freebsd.org References: <20180317103915.081ca2dd@thor.intern.walstatt.dynvpn.de> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <1b31e36e-e84b-cc63-1422-d1e0ce2f03c8@FreeBSD.org> Date: Wed, 4 Apr 2018 20:16:58 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:23:34 -0000 On 01/04/2018 05:31, Mark Millard wrote: > I have a hypothesis for part of what top is > counting in the process/thread SWAP column > that might not be what one would expect. > > It appears to me that vnode-backed pages are > being re-classfied sometimes for inactive > processes, and this classification leads to > top classifying the pages as not-resident > but swapped (in that a "VN PAGER in" would > be required, in systat -vmstat terms). Not sure. To me it seems that top just uses wrong statistics to calculate the value. /* swap usage */ #define ki_swap(kip) \ ((kip)->ki_swrss > (kip)->ki_rssize ? (kip)->ki_swrss - (kip)->ki_rssize : 0) ki_rssize is the resident size of a process. ki_swrss is resident set size before last swap. Their difference is... exactly what? I cannot even meaningfully describe this value. But it is certainly _not_ the current swap utilization by the process. Here is my attempt at obtaining a more reasonable approximation of the. process swap use. But it is still wildly inaccurate. diff --git a/usr.bin/top/machine.c b/usr.bin/top/machine.c index 2d97d7f867f36..361a1542e6e16 100644 --- a/usr.bin/top/machine.c +++ b/usr.bin/top/machine.c @@ -233,12 +233,13 @@ static int carc_enabled; static int pageshift; /* log base 2 of the pagesize */ /* define pagetok in terms of pageshift */ - -#define pagetok(size) ((size) << pageshift) +#define pagetok(size) ((size) << (pageshift - LOG1024)) +#define btopage(size) ((size) >> pageshift) /* swap usage */ #define ki_swap(kip) \ - ((kip)->ki_swrss > (kip)->ki_rssize ? (kip)->ki_swrss - (kip)->ki_rssize : 0) + (btopage((kip)->ki_size) > (kip)->ki_rssize ? \ + btopage((kip)->ki_size) - (kip)->ki_rssize : 0) /* useful externals */ long percentages(int cnt, int *out, long *new, long *old, long *diffs); @@ -384,9 +385,6 @@ machine_init(struct statics *statics, char do_unames) pagesize >>= 1; } - /* we only need the amount of log(2)1024 for our conversion */ - pageshift -= LOG1024; - /* fill in the statics information */ statics->procstate_names = procstatenames; statics->cpustate_names = cpustatenames; @@ -1374,7 +1372,7 @@ static int sorted_state[] = { } while (0) #define ORDERKEY_SWAP(a, b) do { \ - int diff = (int)ki_swap(b) - (int)ki_swap(a); \ + int diff = (long)ki_swap(b) - (long)ki_swap(a); \ if (diff != 0) \ return (diff > 0 ? 1 : -1); \ } while (0) -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Apr 4 17:49:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7A6AF9FE77 for ; Wed, 4 Apr 2018 17:49:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4811768096; Wed, 4 Apr 2018 17:49:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id 71-v6so26675102ith.2; Wed, 04 Apr 2018 10:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=egaAu1voqDj+KOP75mHYmkGgANUhZqoenNto96mPgBE=; b=ktLOQcQUJG2uLrPWVCqPerLtu7Zyth/AK5SCZgy6a+70DuPJQ0ckWxnS55EhNoFYdB LD9GFIBVsS59w36pzAkWhC6IG2KOY86qO1xw4NDxazHkX1EUsVfrgh0rLyNOkVc6aySb e1n8AdgSM2CgxHxY/Gg5+C1caz/f5osUzQo2EvSys+iNrfDNRPxRdIwp9pHXelpdgnI9 EaUvwHaeeaat7II4J9k89Y07BG2bZvBZusZ/hYCSLMO9jOyXMwApKjhsg0Moukkh5hEW B9RKcL+8HD2RGSajjlwBprcSaV7DLoGfzUTTH6KxB6smw+S5XQxtmwwUKCOuODeDfVq9 996w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=egaAu1voqDj+KOP75mHYmkGgANUhZqoenNto96mPgBE=; b=YV4SICX/MpWrQ8xFcaxcDAqCprN/oJxOxRqVJxI9S87Hdr54QErSFFqf8+fDj/zQ2q 0ezZ2z3ZdKz0r76ndjSdIoHzOnU8xB9uPNC84gyzBsEopAn3lu4js2D5VbVBOwfsmgQ8 H9AsUYhX97oF6YtrGmqryiE5Sl7qi7M3o5A4hBA/hemIkqtownGvfy/XF6UQuXcolYhg eowP73X2kTpETkLxlmWPUiHAWo8UJx/c65WZgu1TMfz49s9FyC3I5uOUObH1KO1Pbn12 Asso84tEIi/1yi15Yu7FSGjPBRDYHxqfLFHAgFf3+B+XdyxRWeNF12ExSrMz5+PzQi+B TaZw== X-Gm-Message-State: ALQs6tC2PvuT/rRKOtrDCO1Kn4B5PjSYzgQxRVElX0mZVxjAxapwjIzv nDqHpQcyy5j/WJ8e7LqiXUvdAA== X-Google-Smtp-Source: AIpwx49MwKWOs+IkxfCpkPV5wSewAD9qvO3tBvGdQvq5Bya24YP396ljxjMA/y2VsAK2BK17od4uMA== X-Received: by 2002:a24:d8:: with SMTP id 207-v6mr10205701ita.3.1522864195260; Wed, 04 Apr 2018 10:49:55 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id k4-v6sm2662324ith.4.2018.04.04.10.49.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:49:54 -0700 (PDT) Sender: Mark Johnston Date: Wed, 4 Apr 2018 13:49:49 -0400 From: Mark Johnston To: Don Lewis Cc: Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT Message-ID: <20180404174949.GA12271@raichu> References: <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:49:57 -0000 On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: > On 3 Apr, Don Lewis wrote: > > I reconfigured my Ryzen box to be more similar to my default package > > builder by disabling SMT and half of the RAM, to limit it to 8 cores > > and 32 GB and then started bisecting to try to track down the problem. > > For each test, I first filled ARC by tarring /usr/ports/distfiles to > > /dev/null. The commit range that I was searching was r329844 to > > r331716. I narrowed the range to r329844 to r329904. With r329904 > > and newer, ARC is totally unresponsive to memory pressure and the > > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired > > RAM, so there is not much leftover for getting useful work done. Active > > memory and free memory both hover under 1GB each. Looking at the > > commit logs over this range, the most likely culprit is: > > > > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines > > > > Add a generic Proportional Integral Derivative (PID) controller algorithm and > > use it to regulate page daemon output. > > > > This provides much smoother and more responsive page daemon output, anticipating > > demand and avoiding pageout stalls by increasing the number of pages to match > > the workload. This is a reimplementation of work done by myself and mlaier at > > Isilon. > > > > > > It is quite possible that the recent fixes to the PID controller will > > fix the problem. Not that r329844 was trouble free ... I left tar > > running over lunchtime to fill ARC and the OOM killer nuked top, tar, > > ntpd, both of my ssh sessions into the machine, and multiple instances > > of getty while I was away. I was able to log in again and successfully > > run poudriere, and ARC did respond to the memory pressure and cranked > > itself down to about 5 GB by the end of the run. I did not see the same > > problem with tar when I did the same with r329904. > > I just tried r331966 and see no improvement. No OOM process kills > during the tar run to fill ARC, but with ARC filled, the machine is > thrashing itself at the start of the poudriere run while trying to build > ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to > memory demand. I've seen no decrease in ARC size or wired memory since > starting poudriere. Re-reading the ARC reclaim code, I see a couple of issues which might be at the root of the behaviour you're seeing. 1. zfs_arc_free_target is too low now. It is initialized to the page daemon wakeup threshold, which is slightly above v_free_min. With the PID controller, the page daemon uses a setpoint of v_free_target. Moreover, it now wakes up regularly rather than having wakeups be synchronized by a mutex, so it will respond quickly if the free page count dips below v_free_target. The free page count will dip below zfs_arc_free_target only in the face of sudden and extreme memory pressure now, so the FMT_LOTSFREE case probably isn't getting exercised. Try initializing zfs_arc_free_target to v_free_target. 2. In the inactive queue scan, we used to compute the shortage after running uma_reclaim() and the lowmem handlers (which includes a synchronous call to arc_lowmem()). Now it's computed before, so we're not taking into account the pages that get freed by the ARC and UMA. The following rather hacky patch may help. I note that the lowmem logic is now somewhat broken when multiple NUMA domains are configured, however, since it fires only when domain 0 has a free page shortage. Index: sys/vm/vm_pageout.c =================================================================== --- sys/vm/vm_pageout.c (revision 331933) +++ sys/vm/vm_pageout.c (working copy) @@ -1114,25 +1114,6 @@ boolean_t queue_locked; /* - * If we need to reclaim memory ask kernel caches to return - * some. We rate limit to avoid thrashing. - */ - if (vmd == VM_DOMAIN(0) && pass > 0 && - (time_uptime - lowmem_uptime) >= lowmem_period) { - /* - * Decrease registered cache sizes. - */ - SDT_PROBE0(vm, , , vm__lowmem_scan); - EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); - /* - * We do this explicitly after the caches have been - * drained above. - */ - uma_reclaim(); - lowmem_uptime = time_uptime; - } - - /* * The addl_page_shortage is the number of temporarily * stuck pages in the inactive queue. In other words, the * number of pages from the inactive count that should be @@ -1824,6 +1805,26 @@ atomic_store_int(&vmd->vmd_pageout_wanted, 1); /* + * If we need to reclaim memory ask kernel caches to return + * some. We rate limit to avoid thrashing. + */ + if (vmd == VM_DOMAIN(0) && + vmd->vmd_free_count < vmd->vmd_free_target && + (time_uptime - lowmem_uptime) >= lowmem_period) { + /* + * Decrease registered cache sizes. + */ + SDT_PROBE0(vm, , , vm__lowmem_scan); + EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); + /* + * We do this explicitly after the caches have been + * drained above. + */ + uma_reclaim(); + lowmem_uptime = time_uptime; + } + + /* * Use the controller to calculate how many pages to free in * this interval. */ From owner-freebsd-current@freebsd.org Wed Apr 4 18:17:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DC55F5715A for ; Wed, 4 Apr 2018 18:17:33 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BAF89694B0; Wed, 4 Apr 2018 18:17:32 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w34IIceS072883 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Apr 2018 18:18:39 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w34IHLhJ071518 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2018 11:17:22 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Wed, 4 Apr 2018 11:17:16 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston cc: Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: <20180404174949.GA12271@raichu> Message-ID: References: <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:17:33 -0000 On 4 Apr, Mark Johnston wrote: > On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >> On 3 Apr, Don Lewis wrote: >> > I reconfigured my Ryzen box to be more similar to my default package >> > builder by disabling SMT and half of the RAM, to limit it to 8 cores >> > and 32 GB and then started bisecting to try to track down the problem. >> > For each test, I first filled ARC by tarring /usr/ports/distfiles to >> > /dev/null. The commit range that I was searching was r329844 to >> > r331716. I narrowed the range to r329844 to r329904. With r329904 >> > and newer, ARC is totally unresponsive to memory pressure and the >> > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired >> > RAM, so there is not much leftover for getting useful work done. Active >> > memory and free memory both hover under 1GB each. Looking at the >> > commit logs over this range, the most likely culprit is: >> > >> > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines >> > >> > Add a generic Proportional Integral Derivative (PID) controller algorithm and >> > use it to regulate page daemon output. >> > >> > This provides much smoother and more responsive page daemon output, anticipating >> > demand and avoiding pageout stalls by increasing the number of pages to match >> > the workload. This is a reimplementation of work done by myself and mlaier at >> > Isilon. >> > >> > >> > It is quite possible that the recent fixes to the PID controller will >> > fix the problem. Not that r329844 was trouble free ... I left tar >> > running over lunchtime to fill ARC and the OOM killer nuked top, tar, >> > ntpd, both of my ssh sessions into the machine, and multiple instances >> > of getty while I was away. I was able to log in again and successfully >> > run poudriere, and ARC did respond to the memory pressure and cranked >> > itself down to about 5 GB by the end of the run. I did not see the same >> > problem with tar when I did the same with r329904. >> >> I just tried r331966 and see no improvement. No OOM process kills >> during the tar run to fill ARC, but with ARC filled, the machine is >> thrashing itself at the start of the poudriere run while trying to build >> ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to >> memory demand. I've seen no decrease in ARC size or wired memory since >> starting poudriere. > > Re-reading the ARC reclaim code, I see a couple of issues which might be > at the root of the behaviour you're seeing. > > 1. zfs_arc_free_target is too low now. It is initialized to the page > daemon wakeup threshold, which is slightly above v_free_min. With the > PID controller, the page daemon uses a setpoint of v_free_target. > Moreover, it now wakes up regularly rather than having wakeups be > synchronized by a mutex, so it will respond quickly if the free page > count dips below v_free_target. The free page count will dip below > zfs_arc_free_target only in the face of sudden and extreme memory > pressure now, so the FMT_LOTSFREE case probably isn't getting > exercised. Try initializing zfs_arc_free_target to v_free_target. Changing zfs_arc_free_target definitely helps. My previous poudriere run failed when poudriere timed out the ports-mgmt/pkg build after two hours. After changing this setting, poudriere seems to be running properly and ARC has dropped from 29GB to 26GB ten minutes into the run and I'm not seeing processes in the swread state. > 2. In the inactive queue scan, we used to compute the shortage after > running uma_reclaim() and the lowmem handlers (which includes a > synchronous call to arc_lowmem()). Now it's computed before, so we're > not taking into account the pages that get freed by the ARC and UMA. > The following rather hacky patch may help. I note that the lowmem > logic is now somewhat broken when multiple NUMA domains are > configured, however, since it fires only when domain 0 has a free > page shortage. I will try this next. > Index: sys/vm/vm_pageout.c > =================================================================== > --- sys/vm/vm_pageout.c (revision 331933) > +++ sys/vm/vm_pageout.c (working copy) > @@ -1114,25 +1114,6 @@ > boolean_t queue_locked; > > /* > - * If we need to reclaim memory ask kernel caches to return > - * some. We rate limit to avoid thrashing. > - */ > - if (vmd == VM_DOMAIN(0) && pass > 0 && > - (time_uptime - lowmem_uptime) >= lowmem_period) { > - /* > - * Decrease registered cache sizes. > - */ > - SDT_PROBE0(vm, , , vm__lowmem_scan); > - EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > - /* > - * We do this explicitly after the caches have been > - * drained above. > - */ > - uma_reclaim(); > - lowmem_uptime = time_uptime; > - } > - > - /* > * The addl_page_shortage is the number of temporarily > * stuck pages in the inactive queue. In other words, the > * number of pages from the inactive count that should be > @@ -1824,6 +1805,26 @@ > atomic_store_int(&vmd->vmd_pageout_wanted, 1); > > /* > + * If we need to reclaim memory ask kernel caches to return > + * some. We rate limit to avoid thrashing. > + */ > + if (vmd == VM_DOMAIN(0) && > + vmd->vmd_free_count < vmd->vmd_free_target && > + (time_uptime - lowmem_uptime) >= lowmem_period) { > + /* > + * Decrease registered cache sizes. > + */ > + SDT_PROBE0(vm, , , vm__lowmem_scan); > + EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > + /* > + * We do this explicitly after the caches have been > + * drained above. > + */ > + uma_reclaim(); > + lowmem_uptime = time_uptime; > + } > + > + /* > * Use the controller to calculate how many pages to free in > * this interval. > */ From owner-freebsd-current@freebsd.org Wed Apr 4 18:41:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DDD6F6B10F for ; Wed, 4 Apr 2018 18:41:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22F8A6A87F for ; Wed, 4 Apr 2018 18:41:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x241.google.com with SMTP id 71-v6so26876439ith.2 for ; Wed, 04 Apr 2018 11:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a8JoP5l7DTHhsf8XZVQv4O/QvZ8C+l98p5laPHsaS6Y=; b=m7NnrypY+NbvoTwo2ShXTIkRTx5xOx/5HYcXE/dHg4hELYUrXtTideVNXMIkXsv63J ppq5fTj5ODmfsFmYbA77cq0Za+IgzbcJsVF6HecaSnMfp9Apvps/Bq1ix/IzdvWl6FJ/ wT+aDqMPjfdcfz1Gw89p3q4+IA8u/Boi86atLu7+EX9DK6ttyhbT8sbWlSsxFRbDBga9 KADNbpUhrd354urKZfWauDlYGHAGgh4LDt0U00+nabqomlJT3Xa1Dv6B4W+2McpCHVEq RZxgtYJYjo0gwG9KJ5epLffN57iirO6RTJFqsh8U1L7Rs87H7KtXYKhBDzYKHLcnF8ht +6zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a8JoP5l7DTHhsf8XZVQv4O/QvZ8C+l98p5laPHsaS6Y=; b=UVb9KTTOHnf6VvxK2QVnFH4+jBv7Hy9ksSrWlMKBPgot77XpUtF038np28gOmwGXog gE0V3XqNafTJTdBch7qJhoc8eO/VyJANotf691Nl6h8gdfV16wkbGHn7CQfn3yamXx1Y iz2gHoR97njn1zSiIb4qRsrKnx4Feg+nIMs5zHRRtRlfMRTjx+qa+LKc+fMWecVD5oAD r0blkHFUnnkYW2OtTcRIp+Sk8HTUqpEnx8h+ul+SZ+UB95VGg5iJzqHGTog46oRmYnmq jJ9oOinDsRkz1s87yxJny2iIKCgBVrnlfwEODz0UlQk/4aBekpG/hQpIfnVR5L84Kxov sIfQ== X-Gm-Message-State: AElRT7En5L5cEM7XC1lHXj2lAlQ1jziDQWVe/Jmb1H2GJFSoE3iFOpYl 8fcOhIsyoH9iDlDOZGUXj6TCc+HsfU9r1RDvN+3O7yFC X-Google-Smtp-Source: AIpwx49FMtGdgqzah7664s1NPJHIFMVVz4GD0XyQfhQ+r/E0H6VTlMg8pT+WFWZyIYfdGwq5NmF0PS6jy6LFVbxvujk= X-Received: by 2002:a24:dfc3:: with SMTP id r186-v6mr10356808itg.114.1522867316572; Wed, 04 Apr 2018 11:41:56 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Wed, 4 Apr 2018 11:41:35 -0700 (PDT) In-Reply-To: <20180403162600.GA23894@troutmask.apl.washington.edu> References: <20180403162600.GA23894@troutmask.apl.washington.edu> From: Ed Maste Date: Wed, 4 Apr 2018 14:41:35 -0400 X-Google-Sender-Auth: F8KKV2B2GePwokqDhiI9Ad3yBfA Message-ID: Subject: Re: Can't load linux64.ko module To: Steve Kargl Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:41:57 -0000 On 3 April 2018 at 12:26, Steve Kargl wrote: > Booting a kernel from > % uname -a > FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \ > Thu Mar 22 13:41:30 AKDT 2018 \ > kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64 > > gives the following from dmesg > > % dmesg | grep linux > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > linker_load_file: /boot/kernel/linux64.ko - unsupported file type Are you loading the linuxulator bits from modules or trying to compile it into the kernel? Did your case work in the past but break recently? As a point of reference, my laptop is at r331538+0a541b719b64 (my WIP branch), and loading linux.ko and linux64.ko is successful. From owner-freebsd-current@freebsd.org Wed Apr 4 19:09:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9307F6E43E for ; Wed, 4 Apr 2018 19:09:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 708156E6C5; Wed, 4 Apr 2018 19:09:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w34J92Xk034371 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 12:09:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w34J9276034370; Wed, 4 Apr 2018 12:09:02 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 Apr 2018 12:09:02 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Can't load linux64.ko module Message-ID: <20180404190902.GA34292@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180403162600.GA23894@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 19:09:11 -0000 On Wed, Apr 04, 2018 at 02:41:35PM -0400, Ed Maste wrote: > On 3 April 2018 at 12:26, Steve Kargl wrote: > > Booting a kernel from > > % uname -a > > FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \ > > Thu Mar 22 13:41:30 AKDT 2018 \ > > kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64 > > > > gives the following from dmesg > > > > % dmesg | grep linux > > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > > linker_load_file: /boot/kernel/linux64.ko - unsupported file type > > Are you loading the linuxulator bits from modules or trying to compile > it into the kernel? Did your case work in the past but break recently? > > As a point of reference, my laptop is at r331538+0a541b719b64 (my WIP > branch), and loading linux.ko and linux64.ko is successful. kernel and world are from r331370. kernel config file contains options COMPAT_LINUX32 options COMPAT_LINUXKPI options LINPROCFS When booting, the kernel tries to load the module. A manual loading of the module results in % kldload /boot/kernel/linux64.ko kldload: an error occurred while loading module /boot/kernel/linux64.ko. Please check dmesg(8) for more details. sleepdirt:fvwm:root[203] dmesg | tail -2 link_elf_obj: symbol elf64_linux_vdso_fixup undefined linker_load_file: /boot/kernel/linux64.ko - unsupported file type Now, that I look at /sys/amd64/conf/NOTES again, I find that there is a COMPAT_LINUX as well as the COMPAT_LINUX32. I must have conflated that two options into being the same thing. I have to update the system for the recent security announcement, so I update everything and change my kernel config file. -- Steve From owner-freebsd-current@freebsd.org Wed Apr 4 20:19:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A77FF7355C for ; Wed, 4 Apr 2018 20:19:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B94871ABD; Wed, 4 Apr 2018 20:19:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w34KJtbx034749 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 13:19:55 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w34KJtwW034748; Wed, 4 Apr 2018 13:19:55 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 Apr 2018 13:19:55 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Can't load linux64.ko module Message-ID: <20180404201955.GA34736@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180403162600.GA23894@troutmask.apl.washington.edu> <20180404190902.GA34292@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404190902.GA34292@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:19:57 -0000 On Wed, Apr 04, 2018 at 12:09:02PM -0700, Steve Kargl wrote: > > kernel config file contains > > options COMPAT_LINUX32 > options COMPAT_LINUXKPI > options LINPROCFS > > When booting, the kernel tries to load the module. A manual > loading of the module results in > > % kldload /boot/kernel/linux64.ko > kldload: an error occurred while loading module /boot/kernel/linux64.ko. > Please check dmesg(8) for more details. > sleepdirt:fvwm:root[203] dmesg | tail -2 > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > linker_load_file: /boot/kernel/linux64.ko - unsupported file type > > Now, that I look at /sys/amd64/conf/NOTES again, I find that > there is a COMPAT_LINUX as well as the COMPAT_LINUX32. I must > have conflated that two options into being the same thing. > Hmmm, this is interesting. /sys/amd64/conf/NOTES contains Lines 270-271 # To enable Linuxulator support, one must also include COMPAT_LINUX in the # config as well. The other option is to load both as modules. And then lines 636-637 # Enable Linux ABI emulation #XXX#options COMPAT_LINUX with no explanation of the #XXX notations. So, building the kernel with COMPAT_LINUX gives ===> SLEEPDIRT mkdir -p /usr/obj/usr/src/amd64.amd64/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/SLEEPDIRT' /usr/src/sys/amd64/conf/SLEEPDIRT: unknown option "COMPAT_LINUX" *** [buildkernel] Error code 1 make[1]: stopped in /usr/src 1 error I guess XXX means Linux emulation isn't supported. Bummer. -- Steve From owner-freebsd-current@freebsd.org Wed Apr 4 21:13:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C228BF76C04 for ; Wed, 4 Apr 2018 21:13:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48AB87434F; Wed, 4 Apr 2018 21:13:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w34LDFZ8035045 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 14:13:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w34LDFro035044; Wed, 4 Apr 2018 14:13:15 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 Apr 2018 14:13:15 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Can't load linux64.ko module Message-ID: <20180404211315.GA35006@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180403162600.GA23894@troutmask.apl.washington.edu> <20180404190902.GA34292@troutmask.apl.washington.edu> <20180404201955.GA34736@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404201955.GA34736@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:13:18 -0000 On Wed, Apr 04, 2018 at 01:19:55PM -0700, Steve Kargl wrote: > On Wed, Apr 04, 2018 at 12:09:02PM -0700, Steve Kargl wrote: > > > > kernel config file contains > > > > options COMPAT_LINUX32 > > options COMPAT_LINUXKPI > > options LINPROCFS > > > > When booting, the kernel tries to load the module. A manual > > loading of the module results in > > > > % kldload /boot/kernel/linux64.ko > > kldload: an error occurred while loading module /boot/kernel/linux64.ko. > > Please check dmesg(8) for more details. > > sleepdirt:fvwm:root[203] dmesg | tail -2 > > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > > linker_load_file: /boot/kernel/linux64.ko - unsupported file type > > > > Now, that I look at /sys/amd64/conf/NOTES again, I find that > > there is a COMPAT_LINUX as well as the COMPAT_LINUX32. I must > > have conflated that two options into being the same thing. > > OK, so where is elf64_linux_vdso_fixup suppose to come from? cd /boot/kernel foreach i (*.ko) nm $i | grep linux_vdso_fixup end 0000000000018f40 t elf32_linux_vdso_fixup 0000000000017cd0 t elf32_linux_vdso_fixup U elf64_linux_vdso_fixup nm kernel | grep linux_vdso ffffffff80f3cb88 d __set_sysinit_set_sym_elf_linux_vdso_init_sys_init ffffffff80f3e140 d __set_sysuninit_set_sym_elf_linux_vdso_uninit_sys_uninit ffffffff80a3eae0 T elf32_linux_vdso_fixup ffffffff80a3ebe0 T elf32_linux_vdso_reloc ffffffff80a3e9e0 T elf32_linux_vdso_sym_init ffffffff81180e70 B elf32_linux_vdso_syms ffffffff80f32ae0 d elf_linux_vdso_init_sys_init ffffffff80f32af8 d elf_linux_vdso_uninit_sys_uninit ffffffff80a292d0 t linux_vdso_deinstall ffffffff80a29210 t linux_vdso_install -- Steve From owner-freebsd-current@freebsd.org Wed Apr 4 21:34:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A4AF78541 for ; Wed, 4 Apr 2018 21:34:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E34B75558; Wed, 4 Apr 2018 21:34:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w34LYrCL035193 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 14:34:53 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w34LYrBX035192; Wed, 4 Apr 2018 14:34:53 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 Apr 2018 14:34:53 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Can't load linux64.ko module Message-ID: <20180404213453.GA35165@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180403162600.GA23894@troutmask.apl.washington.edu> <20180404190902.GA34292@troutmask.apl.washington.edu> <20180404201955.GA34736@troutmask.apl.washington.edu> <20180404211315.GA35006@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404211315.GA35006@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:34:55 -0000 On Wed, Apr 04, 2018 at 02:13:15PM -0700, Steve Kargl wrote: > > OK, so where is elf64_linux_vdso_fixup suppose to come from? > The answer is compat/linux/linux_vdso.c where we find #if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) #define __ELF_WORD_SIZE 32 #else #define __ELF_WORD_SIZE 64 #endif having COMPAT_LINUX32 in my kernel config file gives me elf32_linux_vdso_fixup. It seems that one cannot have a kernel that supports both 32 and 64-bit linux software. linux(4) states for an amd64 kernel use: options COMPAT_LINUX32 Alternatively, to load the ABI as a module at boot time, place the following line in loader.conf(5): linux_load="YES" It turns out that I have 'linux_load=YES" in /etc/loader.conf. When I boot the kernel built with COMPAT_LINUX32 prevents the kldload of linux64.ko. Oh well, learn something new everyday. -- Steve From owner-freebsd-current@freebsd.org Thu Apr 5 02:03:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18BD3F89EE3 for ; Thu, 5 Apr 2018 02:03:56 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (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 B17DF80396 for ; Thu, 5 Apr 2018 02:03:55 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: RDah654VM1mG.rSyk_VxuloTp_uki6IzZYbogWMfqrXpyEkDMrhe5cvXfHSE7lf 5qz5y0wJqxW5B8XMJ1leRlMghmSttiZ0Zq7IWMVEOST56ZKaRduLXRtGmcqU0JC6uJ8KbvHP72S7 MW_aEuA4E.R2MK6e8JhnA4kr1iZZ7LpT5eBdG4Oy3wMBy7ykEdAfcYEBEIXfmA8cBoyhgKESQdiM bA3NFOYx5FF_J8up_1zY4Kclh8agZU5vRwq2CSwnTrM34ZAzksEELGwAkFx2tjUdQj79kYOeSLfl lDt1vkv8PYE2OP0EapPxfQs.l5dBFIDX6YNPjIZbSwkUgZUU4P4ZGciiJD6rnhpzOBBePn._Q6IV tuK2sC4erfyXUuNtzETT4PdkRvoy87O2jQX4hPkOcTSMlix_VgzkGVCE7.NH44TMjOpS50c7PU1q 1u5VC5hfainNgK8YK6uinIA3hNd5zNzTIog.TtskUvbuNF6_Il.Y8dMWqnEp4aPcAUHgB6Y0IrsJ g.Ks2WInUSIL6wquPXlNQbUJrY89kjQcQRV3x Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Thu, 5 Apr 2018 02:03:49 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80ef4856253093b6a58029cc12d03959; Thu, 05 Apr 2018 02:03:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT From: Mark Millard In-Reply-To: <1b31e36e-e84b-cc63-1422-d1e0ce2f03c8@FreeBSD.org> Date: Wed, 4 Apr 2018 19:03:43 -0700 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180317103915.081ca2dd@thor.intern.walstatt.dynvpn.de> <1b31e36e-e84b-cc63-1422-d1e0ce2f03c8@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 02:03:56 -0000 On 2018-Apr-4, at 10:16 AM, Andriy Gapon wrote: > On 01/04/2018 05:31, Mark Millard wrote: >> I have a hypothesis for part of what top is >> counting in the process/thread SWAP column >> that might not be what one would expect. >>=20 >> It appears to me that vnode-backed pages are >> being re-classfied sometimes for inactive >> processes, and this classification leads to >> top classifying the pages as not-resident >> but swapped (in that a "VN PAGER in" would >> be required, in systat -vmstat terms). >=20 > Not sure. > To me it seems that top just uses wrong statistics to calculate the = value. >=20 > /* swap usage */ > #define ki_swap(kip) \ > ((kip)->ki_swrss > (kip)->ki_rssize ? (kip)->ki_swrss - = (kip)->ki_rssize : 0) >=20 > ki_rssize is the resident size of a process. > ki_swrss is resident set size before last swap. >=20 > Their difference is... exactly what? > I cannot even meaningfully describe this value. > But it is certainly _not_ the current swap utilization by the process. >=20 > Here is my attempt at obtaining a more reasonable approximation of = the. process > swap use. But it is still wildly inaccurate. >=20 > . . . If I get time this weekend, I'll try the patch. Thanks. I've classically seen things like (picking on java here): (no patch yet, so SWAP 0K shows) PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 78694 root 44 52 0 14779M 92720K 0K uwait 22 0:06 = 9.91% [java] when Swap: . . . 0 Used . . . (or some figure much smaller than SIZE-RES) showed. (SIZE is ki_size and RES is ki_rssize as I remember.) It suggests some form of reserved-but-not-allocated contribution to ki_size (SIZE), space not resident nor swapped out to a swap partition. Possibly vnode-backed (potential "VN PAGER in and out" contributions instead of "SWAP PAGER" ones, in systat -vmstat terms)? Are such cases examples of what you were counting as "wildly inaccurate"? Or do you count vnode-backed but not resident as perfectly good examples of SWAP in use? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Apr 5 09:09:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B28EAF97873 for ; Thu, 5 Apr 2018 09:09:59 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E7AC71529 for ; Thu, 5 Apr 2018 09:09:58 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-wr0-f182.google.com with SMTP id d1so27140800wrj.13 for ; Thu, 05 Apr 2018 02:09:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CNzC23n9BX+ApXFb/0uLped2+k2WP0hjZJ5lGmYjWUY=; b=HbeuyXdV+f6Xv7kgBQUwK8E7Ref+Ja3Ta5a6HfvbA6LorV+eSCpNy28B6YXc571uot dWevWlB+qf+T4URZU99FbZqkFmNjOU3v+ve29ABcu1i65erNP4oRin7F0w4Kqjp7jPcM 9q+hHZJfPpdBUoQJupV4/Gex6tBhZMVsMmqIEIes7mHg1WAngr3g51s0vw+WJXAFQTCW 6Wj4S/HUb6sKjLl+wQ3AovV2Ty/VYWzq86WkRCVgwfmM2PUg+5SJlrF69IaooU/NmGz1 5/0DI3on+5/3y3D4kWq67Yany/0kVb04qDFFScyMr7hXZOp1FIvJNPHTqPfEQrgE6H9i 8B+w== X-Gm-Message-State: ALQs6tBByExreV0jZnC01QsAki1mOYfYR6KXn5hTiDmikNwd4IUd8oFF 3qRcbJX+BwdT81RbDKDAO8lZ0HZB X-Google-Smtp-Source: AIpwx49YYAkSzwc961bkXI6gDlG0zgrOTceIOMF9bPdpKJrdo/3w8N1VzQVDz1yItzdsuhQ2Vp9Kzw== X-Received: by 2002:a19:7385:: with SMTP id h5-v6mr13551216lfk.67.1522919003751; Thu, 05 Apr 2018 02:03:23 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id u12sm1202473lji.87.2018.04.05.02.03.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 02:03:22 -0700 (PDT) Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Millard Cc: freebsd-current@freebsd.org References: <20180317103915.081ca2dd@thor.intern.walstatt.dynvpn.de> <1b31e36e-e84b-cc63-1422-d1e0ce2f03c8@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <14a14c1a-129c-0733-34c8-8eefae3fd084@FreeBSD.org> Date: Thu, 5 Apr 2018 12:03:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 09:09:59 -0000 On 05/04/2018 05:03, Mark Millard wrote: > I've classically seen things like (picking on java here): > (no patch yet, so SWAP 0K shows) > > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME CPU COMMAND > 78694 root 44 52 0 14779M 92720K 0K uwait 22 0:06 9.91% [java] > > when Swap: . . . 0 Used . . . (or some figure much > smaller than SIZE-RES) showed. (SIZE is ki_size and > RES is ki_rssize as I remember.) It suggests some > form of reserved-but-not-allocated contribution to > ki_size (SIZE), space not resident nor swapped out > to a swap partition. Possibly vnode-backed (potential > "VN PAGER in and out" contributions instead of "SWAP > PAGER" ones, in systat -vmstat terms)? > > Are such cases examples of what you were counting > as "wildly inaccurate"? Or do you count vnode-backed > but not resident as perfectly good examples of SWAP > in use? Apologies, but I didn't quite get your question... Instead, I think I now understand better what top actually reports. I think that it reports swap usage based on the archaic swapout algorithm where a whole process is moved to swap when a memory shortage arises. And then the process can be gradually swapped in. So, ki_swrss - ki_rssize is an estimate of how much process's memory still left in swap (the difference between the resident size before the full swapout and the current resident size). Of course, now we have the modern swapout where individual inactive dirty anonymous pages can be paged out to swap (the classic whole-process swapout still can happen, but is quite rare), but top is not aware of that. -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Apr 5 12:40:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02F19F82335 for ; Thu, 5 Apr 2018 12:40:05 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6936794ED; Thu, 5 Apr 2018 12:40:04 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd06.aul.t-online.de (fwd06.aul.t-online.de [172.20.26.150]) by mailout11.t-online.de (Postfix) with SMTP id 1E7B74276116; Thu, 5 Apr 2018 14:31:38 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (E28Fi2ZG8hmMTmv6WpCiQT-FYm5QdhL9DxdTg2gOGtf5-oSGB3YBIe5u0+jWAj0wBT@[84.154.99.226]) by fwd06.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f4434-3fNFHk0; Thu, 5 Apr 2018 14:31:26 +0200 Subject: Re: Is kern.sched.preempt_thresh=0 a sensible default? To: Andriy Gapon , "M. Warner Losh" Cc: FreeBSD Current References: <1d188cb0-ebc8-075f-ed51-57641ede1fd6@freebsd.org> <49fa8de4-e164-0642-4e01-a6188992c32e@freebsd.org> <32d6305b-3d57-4d37-ba1b-51631e994520@FreeBSD.org> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Message-ID: <93efc3e1-7ac3-fedc-a71e-66c99f8e8c1e@freebsd.org> Date: Thu, 5 Apr 2018 14:31:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <32d6305b-3d57-4d37-ba1b-51631e994520@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: E28Fi2ZG8hmMTmv6WpCiQT-FYm5QdhL9DxdTg2gOGtf5-oSGB3YBIe5u0+jWAj0wBT X-TOI-MSGID: b1137ebe-952c-40b1-8096-8825a7d0a42f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:40:05 -0000 Am 04.04.18 um 18:45 schrieb Andriy Gapon: > On 04/04/2018 16:19, Stefan Esser wrote: >> I have identified the cause of the extremely low I/O performance (2 to 6 read >> operations scheduled per second). >> >> The default value of kern.sched.preempt_thresh=0 does not give any CPU to the >> I/O bound process unless a (long) time slice expires (kern.sched.quantum=94488 >> on my system with HZ=1000) or one of the CPU bound processes voluntarily gives >> up the CPU (or exits). >> >> Any non-zero value of preemt_thresh lets the system perform I/O in parallel >> with the CPU bound processes, again. > > Let me guess... you have a custom kernel configuration and, unlike GENERIC > (assuming x86), it does not have 'options PREEMPTION'? Yes, thank you for pointing that out!!! I used to have PREEMPTION and FULL_PREEMPTION in my kernel configuration, and apparently have deleted both options when only FULL_PREEMPTION was supposed to go ... After looking at sched_ule.c and top/machine.c it appears, that the value of preempt_thresh corresponds to the PRI value as shown by top (or ps -l) plus PZERO which is calculated as (PRI_MIN_KERN=80) + 20. What I do not understand, though, is that the decision about a preemption is only based on the calculated new priority of the thread, but not at all on the priority of other running threads (except the idle thread). On my system, a "real" batch job (i.e. one that does not voluntarily give up the CPU due to I/O) seems to have a PRI value of 80 to 100 (growing over time), while an interactive process has a PRI of 20, a maximally "niced" interactive process has 52. So, I'd expect a reasonable default value of preempt_thresh to be slightly above 120 (e.g. 124) to prevent I/O heavy threads from stealing each other the CPU too often, and to prevent "niced" processes from doing the same ... The two values configured into the kernel (80 for PREEMPTION and 255 for FULL_PREEMPTION) seem to be extremes, but something in between (e.g. 124) is not offered (can only be configured via sysctl without any information for the correspondence between the threshold value and the PRI value in any document I've found, besides the kernel sources ...). Is PRI_MIN_KERN=80 really a good default value for the preemption threshold? Regards, STefan From owner-freebsd-current@freebsd.org Thu Apr 5 20:43:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54EE2FA1864 for ; Thu, 5 Apr 2018 20:43:40 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EC09170A46 for ; Thu, 5 Apr 2018 20:43:39 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A697EFA1863; Thu, 5 Apr 2018 20:43:39 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 952BBFA1862 for ; Thu, 5 Apr 2018 20:43:39 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB1F70A43 for ; Thu, 5 Apr 2018 20:43:39 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from localhost (vpn.classit.ro [31.14.161.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id 23E744663D6 for ; Thu, 5 Apr 2018 23:36:02 +0300 (EEST) Date: Thu, 5 Apr 2018 23:35:47 +0300 From: Ion-Mihai Tetcu To: current@FreeBSD.org Subject: failing to install 11.1R on VMWare Message-ID: <20180405233547.000061b5@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 180405-10, 2018-04-05), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:43:40 -0000 Hi, I'm trying to install FreeBSD on : VMWare ESXi, 6.0.0, 5050593 Guest OS: FreeBSD (64-bit) Compatibility: ESXi 6.0 and later (VM version 11) For 11.1R I'm getting the boot menu, then: /boot/kernel/kernel text=014972f8 elf64_loadimage: read failed can't load file: '/boot/kernel/kernel': input/output error ... (for 10.4R similar just with a different address). SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the other available options with the same result). VMWare docs list both 10 and 11 as being compatible with this version of ESXi. Any pointers to get through this will be greatly appreciated, I didn't found anything on the net, and I need a sane system to play with when I'm getting tired of the ton of Linux distros I'm forced to use. Tnx, -- IOnut Tetcu --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-current@freebsd.org Thu Apr 5 22:39:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6EF4F87516 for ; Thu, 5 Apr 2018 22:39:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BE3275530 for ; Thu, 5 Apr 2018 22:39:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w35McqTl043156 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Apr 2018 15:38:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w35McqFo043155 for freebsd-current@freebsd.org; Thu, 5 Apr 2018 15:38:52 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 15:38:52 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: clang manual page? Message-ID: <20180405223852.GA43120@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 22:39:01 -0000 Is anyone working on fixing the clang manual to actually document the available options? % man clang (search for -std=) -std= Specify the language standard to compile for. OK, what does mean? -- Steve From owner-freebsd-current@freebsd.org Thu Apr 5 23:30:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D280BF8AF00 for ; Thu, 5 Apr 2018 23:30:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F687772ED for ; Thu, 5 Apr 2018 23:30:47 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5b045e1f-3929-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 5b045e1f-3929-11e8-91c6-33ffc249f3e8; Thu, 05 Apr 2018 23:30:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w35NUZx6088586; Thu, 5 Apr 2018 17:30:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1522971035.49673.250.camel@freebsd.org> Subject: Re: clang manual page? From: Ian Lepore To: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org Date: Thu, 05 Apr 2018 17:30:35 -0600 In-Reply-To: <20180405223852.GA43120@troutmask.apl.washington.edu> References: <20180405223852.GA43120@troutmask.apl.washington.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 23:30:48 -0000 On Thu, 2018-04-05 at 15:38 -0700, Steve Kargl wrote: > Is anyone working on fixing the clang manual to actually > document the available options? > > % man clang > (search for -std=) >        -std= >               Specify the language standard to compile for. > > OK, what does mean? > clang --help has more info than the manpage, but it's still light on details. -- Ian From owner-freebsd-current@freebsd.org Fri Apr 6 00:15:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 494E5F8DF33 for ; Fri, 6 Apr 2018 00:15:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D01E778D98; Fri, 6 Apr 2018 00:15:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w360FE61043849 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Apr 2018 17:15:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w360FEaA043848; Thu, 5 Apr 2018 17:15:14 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 17:15:14 -0700 From: Steve Kargl To: Conrad Meyer Cc: freebsd-current Subject: Re: clang manual page? Message-ID: <20180406001514.GA43793@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:15:16 -0000 This assumes that a gcc(1) is available on the system. % man gcc No manual entry for gcc If the system compiler is clang/clang++, then it ought to be documented better than it currently is. Ian's suggests for 'clang --help' is even worse % clang --help | grep -- -std -cl-std= OpenCL language standard to compile for. -std= Language standard to compile for -stdlib= C++ standard library to use Does == ? -- steve On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote: > To a first order approximation, the manual page for clang is gcc(1). > > Conrad > > On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl > wrote: > > Is anyone working on fixing the clang manual to actually > > document the available options? > > > > % man clang > > (search for -std=) > > -std= > > Specify the language standard to compile for. > > > > OK, what does mean? > > > > -- > > Steve > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Apr 6 00:23:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78F09F8EB1C for ; Fri, 6 Apr 2018 00:23:58 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14C5C7949B; Fri, 6 Apr 2018 00:23:57 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-it0-x232.google.com with SMTP id v194-v6so6577907itb.0; Thu, 05 Apr 2018 17:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iETe6MAs666ZH+43UUXhQEYN1yymPTPu21ykKyJ1r+I=; b=TGO5QcHTjBkfAVzjznhnyPJi+tX+BO8oMGl2xNfDBQJsY7JGc6VhhOYG3GcgRxm8Ni aW0ulP4tWfhGUD3xJNnDHMEFDoD60D41nDxLUVHKy9BqGSs2t2/cvsYOax+4DWScBvRs 8q4CgdL5PE4oakLodFnHaNLF/+bUELRl9PKv96PseZseKhznsVPLmU8aPd4OlyO/qySU Bp+IL9vUwA5ub0aDvRDXDs6LM+q7yWG9ozdxkp46eE5NOJxImOZPglYzKRdW+nz+5nTN RCd3hCa/Dl0D1fhE2IPgZVVCiHvISS4HVSHgxfrF6aYDP1bAUYPpR9qjyq7dRxv7F5gX 5s5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iETe6MAs666ZH+43UUXhQEYN1yymPTPu21ykKyJ1r+I=; b=uQtBT2JbTdD+zUncVY7rQTFXWQqxbOUCP9gpMx59HO3FJWNmSyFNm3iMWn65Kv+lN0 Jb7kBJXTzJN+0PwzWikKYSed0KkbE9lasIjHExFmLqElU7LVkygkNCp8LggrwMPk8V/v xuzGohPOyPMPJ/L22w4NBDNZbOhh2lkDniyFqAyUezYcCIy72TJU0h0oARFVQqkqXo7Y 5U5jwFDBPnTGzAaDXa/fXUx7AMK7nYCOqnP+slT1J8JL8Vy0Bagj/nB3dqho2CeKfNrV 4idzKI+Xrl7uwCJ2gADA8iasqyTR4Wp+WZylXDYoVhuXe+dmOKOJUnnrKb82xySo8ebv k3Zg== X-Gm-Message-State: ALQs6tCAZsU8UFxeO8ckGMcd2eaf4XY7ciJ3bsRlUmT/lQ1xFEYCaXv6 gp3uDydzZnb4V4pgn5o74bK3v1/e5y42DvUSUg== X-Google-Smtp-Source: AIpwx49sLWJKqUpvCMcngli1nYkVLTOvy6wk8JDcjshSqe+YSokGMyspu/Ow/mH9ujfEQPYW/hZ/3rz9yQlx7KE5TbI= X-Received: by 2002:a24:1d94:: with SMTP id 142-v6mr6990479itj.39.1522974237288; Thu, 05 Apr 2018 17:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Thu, 5 Apr 2018 17:23:56 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Thu, 5 Apr 2018 20:23:56 -0400 Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Kyle Evans Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:23:58 -0000 As I said I would, I put the contents of /boot onto the FAT-formated EFI partition. This is suboptimal. The default is to use "kernel.old" ... etc ... which cannot be done on a FAT partition... at least not with our filesystem driver ... ... but with all of /boot on the EFI partition, simply starting loader.efi works. On Wed, Apr 4, 2018 at 11:57 AM, Kyle Evans wrote: > On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans wrote: > > Hello! > > > > A number of changes have gone in recently pertaining to UEFI booting > > and UEFI runtime services. The changes with the most damaging > > potential are: > > > > We now put UEFI runtime services into virtual address mode, fixing > > runtime services with U-Boot/UEFI as well as the firmware > > implementation in many Lenovos. The previously observed behavior was a > > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic > > just loading efirt.ko or compiling EFIRT into the kernel. > > > > Graphics mode selection is now done differently to avoid regression > > caused by r327058 while still achieving the same effect. The observed > > regression was that the kernel would usually end up drawing > > incorrectly at the old resolution on a subset of the screen, due to > > incorrect framebuffer information. > > > > Explicit testing of these changes, the latest of which happened in > > r331326, and any feedback from this testing would be greatly > > appreciated. Testing should be done with either `options EFIRT` in > > your kernel config or efirt.ko loaded along with updated bootloader > > bits. > > > > I otherwise plan to MFC commits involved with the above-mentioned > > changes by sometime in the first week of April, likely no earlier than > > two (2) weeks from now on April 4th. > > > > Thanks, > > > > Kyle Evans > > As partially promised, the non-graphics related changes have been > MFC'd to stable/11 today as r332028. > > The graphics related changes are going to simmer longer and probably > get ripped out, because we're bad at this. > > Thanks, > > Kyle Evans > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Apr 6 00:30:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EB1DF8F1CD for ; Fri, 6 Apr 2018 00:30:07 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD5BE797DD; Fri, 6 Apr 2018 00:30:06 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.2.7] (cpe-23-243-163-13.socal.res.rr.com [23.243.163.13]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id e1676f89 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Thu, 5 Apr 2018 17:30:04 -0700 (PDT) Subject: Re: clang manual page? To: sgk@troutmask.apl.washington.edu, Conrad Meyer Cc: freebsd-current References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> From: Pete Wright Message-ID: <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> Date: Thu, 5 Apr 2018 17:30:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180406001514.GA43793@troutmask.apl.washington.edu> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:30:07 -0000 On 04/05/2018 17:15, Steve Kargl wrote: > This assumes that a gcc(1) is available on the system. > > % man gcc > No manual entry for gcc > > If the system compiler is clang/clang++, then it ought to be > documented better than it currently is. Ian's suggests for > 'clang --help' is even worse > > % clang --help | grep -- -std > -cl-std= OpenCL language standard to compile for. > -std= Language standard to compile for > -stdlib= C++ standard library to use > > Does == ? > a quick google search turns up the following additional information: "clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, c17, gnu17, and various aliases for those modes. If no -std option is specified, clang defaults to gnu11 mode. Many C99 and C11 features are supported in earlier modes as a conforming extension, with a warning. Use |-pedantic-errors| to request an error if a feature from a later standard revision is used in an earlier mode." https://clang.llvm.org/docs/UsersManual.html -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Apr 6 00:47:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59899F9087D for ; Fri, 6 Apr 2018 00:47:29 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C84647A4B2; Fri, 6 Apr 2018 00:47:28 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id m13so31221452wrj.5; Thu, 05 Apr 2018 17:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rYiXb80W16pYrvOLN/hTbJFYn+/CB6iqhvu2PsouC4U=; b=kGowZHgtsSS9ZKKzbeTgfyGX41esv9PtOQK2ZmziVuNMyaYGhkZgFpiBA7lp2RdhrM ob7nOn6zxGRYbpu0AwjMJIWyMDljPLLdAE/sY5WC9zvnuOxJJ1xQkhoS7jF/wGVawK5h apenVgRtTFzWiFPJp11JgHaSzmOdSd9eqsJrUkzr6xMpvdp0c2Oc4PbxkTmQuppVEwXI 5JU49KESk6KSbL5Xv3NkDN/fUDyIvxepLhaUdRKeKoZZOpcWHiNfwdD13+M552j2R9xi fucKcsJtpxFA7FE/ofJmS6J4pg0GQn6Q2oORCMT2Q1XjhbcR+zyM3YwbCJJQCRxkxi5j Yv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rYiXb80W16pYrvOLN/hTbJFYn+/CB6iqhvu2PsouC4U=; b=F24zUDL5cArzEPI+5jxEXjB8oB30Tit/V5DFnDtN9oJXk4YWiquVsnvjtb4SVgLWPI Hi9oZ9+ZbxYsCHpuWczEQ4ynozd8KFO3z5l4RaO2HIajgbYbVEWO3P/5zv9bdCa+kePu tBE1YOJJMCv5v6F8ami14q8UTae7cC4cNCA5eT+PCtTHVFHwVNdmd5jwyfYTY3MHGe8I Dcg4xgfBUOv22S6o6bfQ8+Zc48Jw2gkMzIWJFdJlptQ3JspkTD+c8vVqTKCuhVUZpVck /GrgcSo+6qLwmyD5g3LSCBxo15r1IyCyC+ojMyjwQha6/qa0WhSbyBLHZUqDGy2WeHPi kBvg== X-Gm-Message-State: ALQs6tC0xm/XSrgMegdJa0pZONIwMk3DwdKsuUUjQHmWiHiafI0Acfbw SjDuj5xlpfGw0OGqpdtz0c2ShvPl8aJXqnOiO4Y= X-Google-Smtp-Source: AIpwx48cLKYS/YG4RQ8kNCRfntx+XvfrSjirPpfRnTZcMUZz4TVTp5/kokDAaTo6MGi6N0wqRe5Ijz3Tyetvtv3Sq4s= X-Received: by 2002:a19:1c0f:: with SMTP id c15-v6mr14439862lfc.44.1522975645828; Thu, 05 Apr 2018 17:47:25 -0700 (PDT) MIME-Version: 1.0 References: <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> In-Reply-To: From: Justin Hibbits Date: Fri, 06 Apr 2018 00:47:14 +0000 Message-ID: Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Don Lewis Cc: Mark Johnston , Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:47:29 -0000 On Wed, Apr 4, 2018, 13:20 Don Lewis wrote: > On 4 Apr, Mark Johnston wrote: > > On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: > >> On 3 Apr, Don Lewis wrote: > >> > I reconfigured my Ryzen box to be more similar to my default package > >> > builder by disabling SMT and half of the RAM, to limit it to 8 cores > >> > and 32 GB and then started bisecting to try to track down the problem. > >> > For each test, I first filled ARC by tarring /usr/ports/distfiles to > >> > /dev/null. The commit range that I was searching was r329844 to > >> > r331716. I narrowed the range to r329844 to r329904. With r329904 > >> > and newer, ARC is totally unresponsive to memory pressure and the > >> > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired > >> > RAM, so there is not much leftover for getting useful work done. > Active > >> > memory and free memory both hover under 1GB each. Looking at the > >> > commit logs over this range, the most likely culprit is: > >> > > >> > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 > lines > >> > > >> > Add a generic Proportional Integral Derivative (PID) controller > algorithm and > >> > use it to regulate page daemon output. > >> > > >> > This provides much smoother and more responsive page daemon output, > anticipating > >> > demand and avoiding pageout stalls by increasing the number of pages > to match > >> > the workload. This is a reimplementation of work done by myself and > mlaier at > >> > Isilon. > >> > > >> > > >> > It is quite possible that the recent fixes to the PID controller will > >> > fix the problem. Not that r329844 was trouble free ... I left tar > >> > running over lunchtime to fill ARC and the OOM killer nuked top, tar, > >> > ntpd, both of my ssh sessions into the machine, and multiple instances > >> > of getty while I was away. I was able to log in again and > successfully > >> > run poudriere, and ARC did respond to the memory pressure and cranked > >> > itself down to about 5 GB by the end of the run. I did not see the > same > >> > problem with tar when I did the same with r329904. > >> > >> I just tried r331966 and see no improvement. No OOM process kills > >> during the tar run to fill ARC, but with ARC filled, the machine is > >> thrashing itself at the start of the poudriere run while trying to build > >> ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to > >> memory demand. I've seen no decrease in ARC size or wired memory since > >> starting poudriere. > > > > Re-reading the ARC reclaim code, I see a couple of issues which might be > > at the root of the behaviour you're seeing. > > > > 1. zfs_arc_free_target is too low now. It is initialized to the page > > daemon wakeup threshold, which is slightly above v_free_min. With the > > PID controller, the page daemon uses a setpoint of v_free_target. > > Moreover, it now wakes up regularly rather than having wakeups be > > synchronized by a mutex, so it will respond quickly if the free page > > count dips below v_free_target. The free page count will dip below > > zfs_arc_free_target only in the face of sudden and extreme memory > > pressure now, so the FMT_LOTSFREE case probably isn't getting > > exercised. Try initializing zfs_arc_free_target to v_free_target. > > Changing zfs_arc_free_target definitely helps. My previous poudriere > run failed when poudriere timed out the ports-mgmt/pkg build after two > hours. After changing this setting, poudriere seems to be running > properly and ARC has dropped from 29GB to 26GB ten minutes into the run > and I'm not seeing processes in the swread state. > > > 2. In the inactive queue scan, we used to compute the shortage after > > running uma_reclaim() and the lowmem handlers (which includes a > > synchronous call to arc_lowmem()). Now it's computed before, so we're > > not taking into account the pages that get freed by the ARC and UMA. > > The following rather hacky patch may help. I note that the lowmem > > logic is now somewhat broken when multiple NUMA domains are > > configured, however, since it fires only when domain 0 has a free > > page shortage. > > I will try this next. > > > Index: sys/vm/vm_pageout.c > > =================================================================== > > --- sys/vm/vm_pageout.c (revision 331933) > > +++ sys/vm/vm_pageout.c (working copy) > > @@ -1114,25 +1114,6 @@ > > boolean_t queue_locked; > > > > /* > > - * If we need to reclaim memory ask kernel caches to return > > - * some. We rate limit to avoid thrashing. > > - */ > > - if (vmd == VM_DOMAIN(0) && pass > 0 && > > - (time_uptime - lowmem_uptime) >= lowmem_period) { > > - /* > > - * Decrease registered cache sizes. > > - */ > > - SDT_PROBE0(vm, , , vm__lowmem_scan); > > - EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > > - /* > > - * We do this explicitly after the caches have been > > - * drained above. > > - */ > > - uma_reclaim(); > > - lowmem_uptime = time_uptime; > > - } > > - > > - /* > > * The addl_page_shortage is the number of temporarily > > * stuck pages in the inactive queue. In other words, the > > * number of pages from the inactive count that should be > > @@ -1824,6 +1805,26 @@ > > atomic_store_int(&vmd->vmd_pageout_wanted, 1); > > > > /* > > + * If we need to reclaim memory ask kernel caches to return > > + * some. We rate limit to avoid thrashing. > > + */ > > + if (vmd == VM_DOMAIN(0) && > > + vmd->vmd_free_count < vmd->vmd_free_target && > > + (time_uptime - lowmem_uptime) >= lowmem_period) { > > + /* > > + * Decrease registered cache sizes. > > + */ > > + SDT_PROBE0(vm, , , vm__lowmem_scan); > > + EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > > + /* > > + * We do this explicitly after the caches have been > > + * drained above. > > + */ > > + uma_reclaim(); > > + lowmem_uptime = time_uptime; > > + } > > + > > + /* > > * Use the controller to calculate how many pages to free > in > > * this interval. > > */ > My powerpc64 embedded machine is virtually unusable since these vm changes. I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help at all. Eventually the machine hangs and just gets stuck in vmdaemon, with many processes in wait channel btalloc. - Justin > From owner-freebsd-current@freebsd.org Fri Apr 6 00:50:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4416F90B07 for ; Fri, 6 Apr 2018 00:50:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 716777A636; Fri, 6 Apr 2018 00:50:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w360o1os044109 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Apr 2018 17:50:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w360o1hp044108; Thu, 5 Apr 2018 17:50:01 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 17:50:01 -0700 From: Steve Kargl To: Pete Wright Cc: Conrad Meyer , freebsd-current Subject: Re: clang manual page? Message-ID: <20180406005001.GA43998@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:50:04 -0000 On Thu, Apr 05, 2018 at 05:30:04PM -0700, Pete Wright wrote: > > > On 04/05/2018 17:15, Steve Kargl wrote: > > This assumes that a gcc(1) is available on the system. > > > > % man gcc > > No manual entry for gcc > > > > If the system compiler is clang/clang++, then it ought to be > > documented better than it currently is. Ian's suggests for > > 'clang --help' is even worse > > > > % clang --help | grep -- -std > > -cl-std= OpenCL language standard to compile for. > > -std= Language standard to compile for > > -stdlib= C++ standard library to use > > > > Does == ? > > > a quick google search turns up the following additional information: > > "clang supports the -std option, which changes what language mode clang > uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, > c17, gnu17, and various aliases for those modes. If no -std option is > specified, clang defaults to gnu11 mode. Many C99 and C11 features are > supported in earlier modes as a conforming extension, with a warning. > Use |-pedantic-errors| to request an error if a feature from a later > standard revision is used in an earlier mode." > > https://clang.llvm.org/docs/UsersManual.html > Yeah, I know how to use google. The above leaves out the clang++ -std=, er, values. One can guess at some of the from https://clang.llvm.org/cxx_status.html. There is no mention of any of the gnu C++ . I'll also note that the above list does include -std=iso9899:1990, which clang appears to accept (but does clang silently igonore the option like other GCC options). An option as fundamental as -std= should be fully documented. A user should not have to resort to the almighty google to use the tools supplied by the system. -- Steve From owner-freebsd-current@freebsd.org Fri Apr 6 00:56:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80187F91406 for ; Fri, 6 Apr 2018 00:56:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 106DE7ABF5; Fri, 6 Apr 2018 00:56:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w360uOWV044166 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Apr 2018 17:56:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w360uOaI044165; Thu, 5 Apr 2018 17:56:24 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 17:56:24 -0700 From: Steve Kargl To: Conrad Meyer Cc: freebsd-current Subject: Re: clang manual page? Message-ID: <20180406005624.GB43998@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:56:26 -0000 I never said that you said it was in base. I'm noting that referring a user to a non-existent manual page is of little help. In fact, your 7 word response is an affirmation that the tools supplied in base should be properly documented. -- steve On Thu, Apr 05, 2018 at 05:42:58PM -0700, Conrad Meyer wrote: > I never said it was in base. > > On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl > wrote: > > This assumes that a gcc(1) is available on the system. > > > > % man gcc > > No manual entry for gcc > > > > If the system compiler is clang/clang++, then it ought to be > > documented better than it currently is. Ian's suggests for > > 'clang --help' is even worse > > > > % clang --help | grep -- -std > > -cl-std= OpenCL language standard to compile for. > > -std= Language standard to compile for > > -stdlib= C++ standard library to use > > > > Does == ? > > > > -- > > steve > > > > On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote: > >> To a first order approximation, the manual page for clang is gcc(1). > >> > >> Conrad > >> > >> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl > >> wrote: > >> > Is anyone working on fixing the clang manual to actually > >> > document the available options? > >> > > >> > % man clang > >> > (search for -std=) > >> > -std= > >> > Specify the language standard to compile for. > >> > > >> > OK, what does mean? > >> > > >> > -- > >> > Steve > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > -- > > Steve > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Apr 6 01:12:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41308F925F4 for ; Fri, 6 Apr 2018 01:12:05 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D43B87B727 for ; Fri, 6 Apr 2018 01:12:04 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-c23ff70000005264-1b-5ac6c95c82e6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id AD.23.21092.D59C6CA5; Thu, 5 Apr 2018 21:11:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w361BrGh015962; Thu, 5 Apr 2018 21:11:54 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w361BnOH025009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2018 21:11:52 -0400 Date: Thu, 5 Apr 2018 20:11:50 -0500 From: Benjamin Kaduk To: Steve Kargl Cc: freebsd-current Subject: Re: clang manual page? Message-ID: <20180406011149.GF80088@mit.edu> References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <20180406005624.GB43998@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180406005624.GB43998@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6noht78liUwf3j5hZz3nxgsrh19zmz A5PHjE/zWTx6d89jDmCK4rJJSc3JLEst0rdL4Mr4+f4Oe8EzlooF3+6wNDC+Yu5i5OSQEDCR mPzgJ1MXIxeHkMBiJontLR8YIZwNjBKfzlxlhXDOMEk0X+4DauHgYBFQkVj7rBCkm01ATeLx 3mZWEFtEwEjidU8/G4jNLGAo8f/DCkYQW1hAXmLFxidgcV4BHYlFL9vZQWwhgf1MEj8Pu0DE BSVOznzCAtGrJXHj30smkFXMAtISy/9xgIQ5BZwkzk59BDZGVEBZYm/fIfYJjAKzkHTPQtI9 C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjKAg5ZTk2cF45o3XIUYB DkYlHt6MiGNRQqyJZcWVuYcYJTmYlER5lU4AhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwOocB 5XhTEiurUovyYVLSHCxK4ryL9u+NEhJITyxJzU5NLUgtgsnKcHAoSfAWgAwVLEpNT61Iy8wp QUgzcXCCDOcBGn4TpIa3uCAxtzgzHSJ/ilFRSpx3DUhCACSRUZoH1wtKIhLZ+2teMYoDvSLM ++U4UBUPMAHBdb8CGswENHhC4hGQwSWJCCmpBkZT0VOFok9UF21+/M1TL5krfFHO9hwhI+lb GqV/Zt47U3l0T+kN12RjgYTQ1wcMHPcFslac+aH5hvswU/HTDLYZX1kmTJe7MH3r/NZFT7fd kyh4cO+qQlzacZF7H21+rHrw9vHxE7qPc9X58nLc/k6cPGF95MuKvT9cAjeGWuR9Waq0e9rn +2ePKbEUZyQaajEXFScCAGmshXv9AgAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 01:12:05 -0000 On Thu, Apr 05, 2018 at 05:56:24PM -0700, Steve Kargl wrote: > I never said that you said it was in base. I'm noting that > referring a user to a non-existent manual page is of little > help. In fact, your 7 word response is an affirmation that > the tools supplied in base should be properly documented. It would probably be more useful to file explicit bug reports (or even write a patch) about missing or poor documentation, than to proffer passive-aggressive inquiries on public mailing lists that merely suggest but do not explicitly state that the documentation is deficient. Thanks, Ben From owner-freebsd-current@freebsd.org Fri Apr 6 01:33:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3552EF93B4C for ; Fri, 6 Apr 2018 01:33:58 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA6397C552 for ; Fri, 6 Apr 2018 01:33:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f54.google.com with SMTP id t192-v6so3651129itc.1 for ; Thu, 05 Apr 2018 18:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=OygSN0hubDbpgLTOKIQquSer4hZp2EqcBuIeL9wzfO0=; b=LqHv15JA+dbbHSVRiu1WtquM1ktOlmgnMCie+5XoKlGwbNyNdqE8nZS40hqJEtrEk6 HvICiDrKwJ8OQ8foSZsEfI7yQzuZfNA4A2wQFq+oOcTHSdpiWExgtqk/hjwsTj78z+iT r1iJ/mkb7J4S2ZJgAxe8OvbJA2c73oItHlINjpepHoK7N7U+lVxpQa2CoQ/oAS0GOaUh rBQ65p1zSBgm6rz+j3X/aGbM3EG2sdSkTjo15GJio/k5Dm1L72yn7Uxl4yBKtc6KC65G asC/iAYYSqJIKDZNLJJnCny3OhWNUsRp0DNaCEnbRaMFbpiQeYpWRpgBCT1SmdARTLNh 88mA== X-Gm-Message-State: ALQs6tCaGD0WiaeIzcfl7zEDa9h0KDb+1RhPqMUJOgassC57ZCdEWAHJ A67dnus05XTvhPemrci7QpeWjMVV X-Google-Smtp-Source: AIpwx48vKplE+8aVphxl6xTWPUlwfPFBdoOXTk6ZVwFYAOvKUmgNu5d9AK1byNjM0LTbpDAo04D2RA== X-Received: by 2002:a24:94e:: with SMTP id 75-v6mr16139312itm.37.1522975379856; Thu, 05 Apr 2018 17:42:59 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id p68-v6sm4798847itc.13.2018.04.05.17.42.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 17:42:59 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id 142-v6so4779718itl.5 for ; Thu, 05 Apr 2018 17:42:59 -0700 (PDT) X-Received: by 2002:a24:c101:: with SMTP id e1-v6mr15974016itg.46.1522975379312; Thu, 05 Apr 2018 17:42:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.62.19 with HTTP; Thu, 5 Apr 2018 17:42:58 -0700 (PDT) In-Reply-To: <20180406001514.GA43793@troutmask.apl.washington.edu> References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> From: Conrad Meyer Date: Thu, 5 Apr 2018 17:42:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: clang manual page? To: sgk@troutmask.apl.washington.edu Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 01:33:58 -0000 I never said it was in base. On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl wrote: > This assumes that a gcc(1) is available on the system. > > % man gcc > No manual entry for gcc > > If the system compiler is clang/clang++, then it ought to be > documented better than it currently is. Ian's suggests for > 'clang --help' is even worse > > % clang --help | grep -- -std > -cl-std= OpenCL language standard to compile for. > -std= Language standard to compile for > -stdlib= C++ standard library to use > > Does == ? > > -- > steve > > On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote: >> To a first order approximation, the manual page for clang is gcc(1). >> >> Conrad >> >> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl >> wrote: >> > Is anyone working on fixing the clang manual to actually >> > document the available options? >> > >> > % man clang >> > (search for -std=) >> > -std= >> > Specify the language standard to compile for. >> > >> > OK, what does mean? >> > >> > -- >> > Steve >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Apr 6 02:07:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AB2FF96054 for ; Fri, 6 Apr 2018 02:07:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9662B7DB83 for ; Fri, 6 Apr 2018 02:07:41 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f177.google.com with SMTP id b20so32913375iof.5 for ; Thu, 05 Apr 2018 19:07:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ap8sT7wHCNs8k9AtoaZ0jngrt7E0AzidiazZLtVsnxI=; b=Ch8/Amkqct9IU7+l12rVdWKRBHn/bYMG1usfSivW7BTBkIxLIAoVW7BTrJ2DuOh2gU rkcQtCPSJMTOQ/HcP8Y7ba4pQ1WAf/S39iynareXY/aC7Z/1NyUmR6X015QohthTy4th 7S45u1Hra9udHqIETrwy+nRptLeVabTeneG7mqZ3YENHbGH8/SZ7jwrniVtM9Fdiot+j zKLP46ARWsGdMlVWLJI6YkNqZdMnptvja3XMwCUUPCtYC9qOJcExmqu6Fn8mOYkcxTJF Qc9rGCVkj0yNdETlKziycsy6YKNdiFJtF/KZ8nIOGFQU+72VS+2wunFl3Sr8VnnOtxYH WVVQ== X-Gm-Message-State: AElRT7HP3M4YyHPVkmJm74oWP0kmJer54o4LnFEVbWYxGdbl8ilZqyKW PUeqDrDtIIS6tyKaERJdmisccy9J X-Google-Smtp-Source: AIpwx49KcBgVkPFYngGlJY74vrsiPRzIhI+BcYJCjOmF4oBqzzwOn5D/SRdFtGTibNwEvgECsoL69Q== X-Received: by 10.107.57.133 with SMTP id g127mr20922884ioa.52.1522971458689; Thu, 05 Apr 2018 16:37:38 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id c103sm5648254ioj.49.2018.04.05.16.37.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 16:37:38 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id p139so8578287iod.0 for ; Thu, 05 Apr 2018 16:37:38 -0700 (PDT) X-Received: by 10.107.168.78 with SMTP id r75mr22419242ioe.143.1522971458462; Thu, 05 Apr 2018 16:37:38 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.62.19 with HTTP; Thu, 5 Apr 2018 16:37:38 -0700 (PDT) In-Reply-To: <20180405223852.GA43120@troutmask.apl.washington.edu> References: <20180405223852.GA43120@troutmask.apl.washington.edu> From: Conrad Meyer Date: Thu, 5 Apr 2018 16:37:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: clang manual page? To: sgk@troutmask.apl.washington.edu Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 02:07:42 -0000 To a first order approximation, the manual page for clang is gcc(1). Conrad On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl wrote: > Is anyone working on fixing the clang manual to actually > document the available options? > > % man clang > (search for -std=) > -std= > Specify the language standard to compile for. > > OK, what does mean? > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Apr 6 02:26:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8037F9754E for ; Fri, 6 Apr 2018 02:26:16 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19B7D7E736 for ; Fri, 6 Apr 2018 02:26:15 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: DF1h9EcVM1nfcy.2TjM_VtIib3WHXoc9.IbnlYCpXdQ9MnVaPGarf43bB7KZfHn DgXqqxAjYA_3UjXRy5KQImFCODA5bTDbp0V34ItwKiUlaKuoM8Oq6pwafTd2zZ2fGzqdrWMOfdHG SeHav2X6GNQzSMrtwe21fAKoGYaccWSKfVCh2ddo5VToXAb.X8LYZ9PD31MkpVDT2BEPH4r3bQz8 SJdVjenFPsHlPXWH0ieUo9Hq8YR9Vq9M2LQLYvtrGH635YuZfjZd33Fc89RI8mWqepVN3WJLx50f v0wLoL8sgxP4JvOO4.oi8CCIMa6SyQWuUdcK9dQbnZ.f_T4_1fDAFZ45TGjM4VG2GaXDn0vX3E89 A2gsw.fz53U3V298tjaLKuGsYBPSFnvIDYe68UUMPdSqY0iAxSc89OS1egcEEH_y4Y3hL4TPJy98 yLy_Rkx0usZHY2Xi3l68lQpt0HlYGHTJsEHTxmgjwl0HoLG7kyvYhTDISJ0sF1QfO_AkYY1KpPU0 ZN7FJpkRRTZ3t4bSiNutpNEHuTP0vknfSOjP5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 6 Apr 2018 02:26:14 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7f2c846933d88de3e3ef1d175f746870; Fri, 06 Apr 2018 02:05:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. From: Mark Millard In-Reply-To: <08B7C130-A38D-473A-8A73-CA79ED1A0044@yahoo.com> Date: Thu, 5 Apr 2018 19:05:55 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> <20180325183421.GA74365@raichu> <44821CA4-19C2-4265-8E83-568452DF6471@yahoo.com> <20180325200934.GC74365@raichu> <45B4FCDA-C743-4F35-B819-9CB064C20038@yahoo.com> <08B7C130-A38D-473A-8A73-CA79ED1A0044@yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 02:26:16 -0000 On 2018-Mar-26, at 6:35 AM, Mark Millard = wrote: > [Unfortunately, I'd not be able to get back to this > for many hours. I do not want to leave the machine > at the db> prompt that long. So this is all there > will be.] >=20 > It got a different crash last night, after a little over 12 > hours of poudriere bulk -a activity, again while I was > sleeping. Hand typed: >=20 > kernel trap 12 with interrupts disabled >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 13; apic id =3D 0d > fault virtual address =3D 0x20 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80b70867 > stack pointer =3D 0x28:0xfffffe00ebab8880 > frame pointer =3D 0x28:0xfffffe00ebab8890 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 44 (dom0) > [ thread pid 44 tid 100277 ] > Stopped at turnstile_broadcast+0x47: movq 0x20(%rbx,%rax,1),%rcx >=20 > (So an offset from a null pointer, apparently.) >=20 > bt shows: >=20 > Tracing pid 44 tid 100277 td 0xfffff8010f938560 > turnstile_broadcast() at turnstile_broadcast+0x47/frame = 0xfffffe00ebab8890 > __mtx_unlock_sleep() at __mtx_unlock_sleep+0xb9/frame = 0xfffffe00ebab88c0 > vm_pageout_page_lock() at vm_pageout_page_lock+0x179/frame = 0xfffffe00ebab8960 > vm_pageout_worker() at vm_pageout_worker+0xd3a/frame = 0xfffffe00ebab8a50 > vm_pageout() at vm_pageout+0x133/frame 0xfffffe00ebab8a70 > fork_exit() at fork_exit+0x83/frame 0xfffffe00ebab8ab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00ebab8ab0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >=20 > Dump again failed, the same way but with some byte > value differences. >=20 > (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 39 8c c7 00 00 08 00 > (da1:storvsc1:0:0:0) CAM status Command timeout > (da1:storvsc1:0:0:0) Error 5, Retries exhausted > Aborting dump to to I/O error. >=20 > ** DUMP FAILED (ERROR 5) ** > Cannot dump: unknown error (error=3D5) >=20 > So this appears to be repeatable (for the Optane > swap/page partition?). >=20 > show reg: >=20 > cs 0x20 > ds 0x3b ll+0x1a > es 0x3b ll+0x1a > fs 0x13 > gs 0x1b > ss 0x28 ll+0x7 > rax 0 > rcx 0xfffff8010f938501 > rdx 0xfffff8010f938501 > rbx 0xfffffe00ebab8880 > rsp 0xfffffe00ebab8800 > rsi 0 > rdi 0 > r8 0 > r9 0 > r10 0 > r11 0 > r12 0 > r13 0xfffff8010f938560 > r14 0 > r15 0xffffffff81d67998 vm_dom+0x18 > rip 0xffffffff80b70867 turnstile_broadcast+0x47 > rflags 0x10056 > turnstile_broadcast+0x47: movq 0x20(%rbx,%rax,1),%rcx >=20 > Around where rbx points: >=20 > 0xfffffe00ebab8872: ab eb 0 fe ff ff 28 0 0 0 0 0 0 0 > 0xfffffe00ebab8880: 0 0 0 0 0 0 0 0 80 79 d6 81 ff ff > 0xfffffe00ebab888e: ff ff c0 88 ab eb 0 fe ff ff 9 20 af 80 > 0xfffffe00ebab889c: ff ff ff ff 0 7b 2 d8 f f8 ff ff 98 79 >=20 > And it looks like we have that null pointer above. >=20 > And I'm afraid that is it: I need to be off doing other things. 3 rounds of bulk -a spanning over 126 hours total and I've not had any more failures. Between rounds I updated /usr/src/ and did buildworld/buildkernel/install sequences so I'd not be far behind head. I'm giving up on directly trying to replicate either of the two types of failures that I'd reported. At least I know to "show panic" now. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Apr 6 02:33:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B238F97E82 for ; Fri, 6 Apr 2018 02:33:37 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE79C7ED0C; Fri, 6 Apr 2018 02:33:36 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-c0bff70000005264-b4-5ac6dc7fb4da Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CD.B6.21092.F7CD6CA5; Thu, 5 Apr 2018 22:33:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w362XYqb007598; Thu, 5 Apr 2018 22:33:35 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w362XVv9013104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2018 22:33:33 -0400 Date: Thu, 5 Apr 2018 21:33:30 -0500 From: Benjamin Kaduk To: Steve Kargl Cc: Ed Maste , FreeBSD Current Subject: Re: Can't load linux64.ko module Message-ID: <20180406023330.GI80088@mit.edu> References: <20180403162600.GA23894@troutmask.apl.washington.edu> <20180404190902.GA34292@troutmask.apl.washington.edu> <20180404201955.GA34736@troutmask.apl.washington.edu> <20180404211315.GA35006@troutmask.apl.washington.edu> <20180404213453.GA35165@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404213453.GA35165@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixCmqrVt/51iUwc+b+haLbhxmtpjz5gOT xa27z5kdmD1mfJrP4tG7ex5zAFMUl01Kak5mWWqRvl0CV8bcs7dYC1ZyVbzcN5W1gbGfo4uR k0NCwETi1MU3jCC2kMBiJomGhR5djFxA9gZGiZ+nNzNBOGeYJE5eP8gMUsUioCJxq6mXDcRm E1CTeLy3mRXEFhEwknjd0w8WZxaIlOif9gIsLiygKbFx+TUWEJtXQEdi1pRzLBBDXzBJTL6x hA0iIShxcuYTFohmLYkb/14CbeYAsqUllv8Du5RTwEnizrYJYOWiAsoSe/sOsU9gFJiFpHsW ku5ZCN0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBAesJM8OxjNvvA4x CnAwKvHwZkQcixJiTSwrrsw9xCjJwaQkynv9DFCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK9z GFCONyWxsiq1KB8mJc3BoiTOu2j/3ighgfTEktTs1NSC1CKYrAwHh5IE76rbQI2CRanpqRVp mTklCGkmDk6Q4TxAwxeC1PAWFyTmFmemQ+RPMSpKifMeBkkIgCQySvPgekEJRSJ7f80rRnGg V4R5/4BU8QCTEVz3K6DBTECDJyQeARlckoiQkmpgvH1ebIaT8Da9h6xnXxzJlhfY0lny38tf ZBrT7X9h6tIeW9/O99BW8tW5PensfdX/kzxWyH4oD1YvO7fxk9XhFxv+W8osmW/BHF8xderq ggUFPuVCooqmt7e4ma/d4JSiMqezwljuqHmE3cFVRveLdjjqTfYJvXJ08RXGxfYz3hzSN1VR PiK+Q4mlOCPRUIu5qDgRAGGheFYDAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 02:33:37 -0000 On Wed, Apr 04, 2018 at 02:34:53PM -0700, Steve Kargl wrote: > > The answer is compat/linux/linux_vdso.c where we find > > #if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) > #define __ELF_WORD_SIZE 32 > #else > #define __ELF_WORD_SIZE 64 > #endif > > having COMPAT_LINUX32 in my kernel config file gives me > elf32_linux_vdso_fixup. It seems that one cannot have > a kernel that supports both 32 and 64-bit linux software. > > linux(4) states > > for an amd64 kernel use: > > options COMPAT_LINUX32 > > Alternatively, to load the ABI as a module at boot time, place the > following line in loader.conf(5): > > linux_load="YES" > > It turns out that I have 'linux_load=YES" in /etc/loader.conf. > When I boot the kernel built with COMPAT_LINUX32 prevents > the kldload of linux64.ko. Yes, building the linuxulator statically into the kernel forces only a single ABI to be possible. If dynamic modules are used for all three relevant modules, then it is possible to simultaneously support 32- and 64-bit linux code. This is (perhaps obliquely) documented at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-lbc-install.html which I added after a similar thread on -current last July. -Ben From owner-freebsd-current@freebsd.org Fri Apr 6 02:37:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EBFFF983AA for ; Fri, 6 Apr 2018 02:37:54 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7537EFEF for ; Fri, 6 Apr 2018 02:37:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id 71-v6so6870200ith.2 for ; Thu, 05 Apr 2018 19:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=wc/EaW0h4tsny9CFBt/8KTi6zxfiBG8v92D8Qp2FzDw=; b=sfJHumBz/QrLH98amzNchVwRxzmQMDKBCCHrDJ6NuKaxmCnUEaYD8Ec0lPI+WB/qfC Dwb4HHlp7EEGGvIFNplE8F1TedFv4vN/AJxt4hYOlDl7DJx2qAnUb8oSVm+ue3/XVlaE 3YTjyr6BM0UJa+l87UJvrdqZTPJWGuazR0qzjp51ZjmcvdeKvjSozms0Is0azfitL4Aw 0eUTCFuxQlV0v87s9mHbvUz4SNOVYW1ldhyF9kFJgW0qlsqgemtWzEGS6GP5wrbHQtTJ Jccf5GZnuQUa6SACwA/rg0VjXeVdtZH6S3Y2gfgEFY/iysdW+t5q2/m7ttM0q4DwYQqz HG/Q== X-Gm-Message-State: ALQs6tCKyE6/FGqZb3JyxdsAfOyoYDzDibiRBQZb9mEy8OlGpS1e+whJ 0If3Fz32sp7KRl+RDv9Wi73Zh+8m X-Google-Smtp-Source: AIpwx4/WjsSQHfHvWwkePGU8W3tqhZyt7QtFJhs3MMN7Jr+K+zFN2Q4Tbzidi+wg0YqJYWg7xNpjkA== X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr15986729itc.39.1522976509042; Thu, 05 Apr 2018 18:01:49 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id k4-v6sm4961652ith.4.2018.04.05.18.01.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 18:01:48 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id v13so32763566iob.6 for ; Thu, 05 Apr 2018 18:01:48 -0700 (PDT) X-Received: by 10.107.164.17 with SMTP id n17mr22379140ioe.173.1522976508488; Thu, 05 Apr 2018 18:01:48 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.62.19 with HTTP; Thu, 5 Apr 2018 18:01:48 -0700 (PDT) In-Reply-To: <20180406005624.GB43998@troutmask.apl.washington.edu> References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <20180406005624.GB43998@troutmask.apl.washington.edu> From: Conrad Meyer Date: Thu, 5 Apr 2018 18:01:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: clang manual page? To: sgk@troutmask.apl.washington.edu Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 02:37:54 -0000 I think we're on the same page about the deficiency of system Clang's manual page, if little else... On Thu, Apr 5, 2018 at 5:56 PM, Steve Kargl wrote: > I never said that you said it was in base. I'm noting that > referring a user to a non-existent manual page is of little > help. In fact, your 7 word response is an affirmation that > the tools supplied in base should be properly documented. > > -- > steve > > > > On Thu, Apr 05, 2018 at 05:42:58PM -0700, Conrad Meyer wrote: >> I never said it was in base. >> >> On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl >> wrote: >> > This assumes that a gcc(1) is available on the system. >> > >> > % man gcc >> > No manual entry for gcc >> > >> > If the system compiler is clang/clang++, then it ought to be >> > documented better than it currently is. Ian's suggests for >> > 'clang --help' is even worse >> > >> > % clang --help | grep -- -std >> > -cl-std= OpenCL language standard to compile for. >> > -std= Language standard to compile for >> > -stdlib= C++ standard library to use >> > >> > Does == ? >> > >> > -- >> > steve >> > >> > On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote: >> >> To a first order approximation, the manual page for clang is gcc(1). >> >> >> >> Conrad >> >> >> >> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl >> >> wrote: >> >> > Is anyone working on fixing the clang manual to actually >> >> > document the available options? >> >> > >> >> > % man clang >> >> > (search for -std=) >> >> > -std= >> >> > Specify the language standard to compile for. >> >> > >> >> > OK, what does mean? >> >> > >> >> > -- >> >> > Steve >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > >> > -- >> > Steve >> > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 >> > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Apr 6 03:00:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45452F99DE2 for ; Fri, 6 Apr 2018 03:00:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C601A80030; Fri, 6 Apr 2018 03:00:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w3630ujG044831 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Apr 2018 20:00:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w3630uV1044830; Thu, 5 Apr 2018 20:00:56 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 20:00:56 -0700 From: Steve Kargl To: Benjamin Kaduk Cc: freebsd-current Subject: Re: clang manual page? Message-ID: <20180406030056.GA44536@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <20180406005624.GB43998@troutmask.apl.washington.edu> <20180406011149.GF80088@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180406011149.GF80088@mit.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 03:00:58 -0000 On Thu, Apr 05, 2018 at 08:11:50PM -0500, Benjamin Kaduk wrote: > On Thu, Apr 05, 2018 at 05:56:24PM -0700, Steve Kargl wrote: > > I never said that you said it was in base. I'm noting that > > referring a user to a non-existent manual page is of little > > help. In fact, your 7 word response is an affirmation that > > the tools supplied in base should be properly documented. > > It would probably be more useful to file explicit bug reports > (or even write a patch) about missing or poor documentation, than > to proffer passive-aggressive inquiries on public mailing lists > that merely suggest but do not explicitly state that the > documentation is deficient. > There is nothing passive nor aggressive in asking about how to use the tools supplied in base because its accompanying documentation is substantially lacking in quality. It should be the responsibility of the individual (or individuals) who import new software into base to ensure that it has proper documentation. Of course, the assumption is that this individual has (or these individuals have) a familiarity with the software, which should facilitate writing said documentation. This started 8 year 10 months ago when clang pre-2.8 was committed without a manpage. The initial version of clang.1 appeared 7 year 6 months ago. FreeBSD is now at clang 6.0.0. I fully anticipate that the next import of clang will again have poor documentation. To preempt a retort about "stop complaining and contribute a fix", I'll note that all of my previous contributions that are in base have been accompanied by documentation. -- Steve From owner-freebsd-current@freebsd.org Fri Apr 6 05:20:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C801F80637 for ; Fri, 6 Apr 2018 05:20:51 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theravensnest.org [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEC168508D; Fri, 6 Apr 2018 05:20:50 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-156-0-78.range86-156.btcentralplus.com [86.156.0.78]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w365KRGk017312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Apr 2018 05:20:28 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host host86-156-0-78.range86-156.btcentralplus.com [86.156.0.78] claimed to be [192.168.1.65] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: clang manual page? From: David Chisnall In-Reply-To: <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> Date: Fri, 6 Apr 2018 06:20:41 +0100 Cc: sgk@troutmask.apl.washington.edu, Conrad Meyer , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 05:20:51 -0000 On 6 Apr 2018, at 01:30, Pete Wright wrote: >=20 >=20 > On 04/05/2018 17:15, Steve Kargl wrote: >> This assumes that a gcc(1) is available on the system. >>=20 >> % man gcc >> No manual entry for gcc >>=20 >> If the system compiler is clang/clang++, then it ought to be >> documented better than it currently is. Ian's suggests for >> 'clang --help' is even worse >>=20 >> % clang --help | grep -- -std >> -cl-std=3D OpenCL language standard to compile for. >> -std=3D Language standard to compile for >> -stdlib=3D C++ standard library to use >>=20 >> Does =3D=3D ? >>=20 > a quick google search turns up the following additional information: >=20 > "clang supports the -std option, which changes what language mode = clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, = gnu11, c17, gnu17, and various aliases for those modes. If no -std = option is specified, clang defaults to gnu11 mode. Many C99 and C11 = features are supported in earlier modes as a conforming extension, with = a warning. Use |-pedantic-errors| to request an error if a feature from = a later standard revision is used in an earlier mode." >=20 > https://clang.llvm.org/docs/UsersManual.html I believe that the clang user manual referenced here is written in = Sphynx, which is able to generate mandoc output as well as HTML. = Perhaps we should incorporate the generated file in the next import? David From owner-freebsd-current@freebsd.org Fri Apr 6 05:38:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE1FBF8183D for ; Fri, 6 Apr 2018 05:38:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBE985C06 for ; Fri, 6 Apr 2018 05:38:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 442C3F8183C; Fri, 6 Apr 2018 05:38:56 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31AEFF8183B for ; Fri, 6 Apr 2018 05:38:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF64D85C04; Fri, 6 Apr 2018 05:38:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w365cpw6001166; Thu, 5 Apr 2018 22:38:51 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w365cpRY001165; Thu, 5 Apr 2018 22:38:51 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804060538.w365cpRY001165@pdx.rh.CN85.dnsmgr.net> Subject: Re: failing to install 11.1R on VMWare In-Reply-To: <20180405233547.000061b5@FreeBSD.org> To: Ion-Mihai Tetcu Date: Thu, 5 Apr 2018 22:38:51 -0700 (PDT) CC: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 05:38:57 -0000 > Hi, > > > I'm trying to install FreeBSD on : > VMWare ESXi, 6.0.0, 5050593 > > Guest OS: FreeBSD (64-bit) > Compatibility: ESXi 6.0 and later (VM version 11) > > For 11.1R I'm getting the boot menu, then: > /boot/kernel/kernel text=014972f8 > elf64_loadimage: read failed > can't load file: '/boot/kernel/kernel': input/output error > ... > (for 10.4R similar just with a different address). > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the > other available options with the same result). > > VMWare docs list both 10 and 11 as being compatible with this version > of ESXi. > Any pointers to get through this will be greatly appreciated, I didn't > found anything on the net, and I need a sane system to play with when > I'm getting tired of the ton of Linux distros I'm forced to use. Try setting the BIOS emulation to BIOS instead of UEFI. And what image are you trying to boot from? Are you trying to boot from a cd attached via vsphere client? or is it a file on the server? I usually use a .ISO when working with ESXi and FreeBSD as a guest. I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Apr 6 06:22:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8D40F85E93 for ; Fri, 6 Apr 2018 06:22:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5582D87862; Fri, 6 Apr 2018 06:22:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w366MKdE045600 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Apr 2018 23:22:20 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w366MKE3045599; Thu, 5 Apr 2018 23:22:20 -0700 (PDT) (envelope-from sgk) Date: Thu, 5 Apr 2018 23:22:20 -0700 From: Steve Kargl To: David Chisnall Cc: Pete Wright , Conrad Meyer , freebsd-current Subject: Re: clang manual page? Message-ID: <20180406062219.GA45545@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 06:22:23 -0000 On Fri, Apr 06, 2018 at 06:20:41AM +0100, David Chisnall wrote: > On 6 Apr 2018, at 01:30, Pete Wright wrote: > > > > > > On 04/05/2018 17:15, Steve Kargl wrote: > >> This assumes that a gcc(1) is available on the system. > >> > >> % man gcc > >> No manual entry for gcc > >> > >> If the system compiler is clang/clang++, then it ought to be > >> documented better than it currently is. Ian's suggests for > >> 'clang --help' is even worse > >> > >> % clang --help | grep -- -std > >> -cl-std= OpenCL language standard to compile for. > >> -std= Language standard to compile for > >> -stdlib= C++ standard library to use > >> > >> Does == ? > >> > > a quick google search turns up the following additional information: > > > > "clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, c17, gnu17, and various aliases for those modes. If no -std option is specified, clang defaults to gnu11 mode. Many C99 and C11 features are supported in earlier modes as a conforming extension, with a warning. Use |-pedantic-errors| to request an error if a feature from a later standard revision is used in an earlier mode." > > > > https://clang.llvm.org/docs/UsersManual.html > > I believe that the clang user manual referenced here is written in Sphynx, which is able to generate mandoc output as well as HTML. Perhaps we should incorporate the generated file in the next import? > > David That would be a good start. But, after cruisng around the clang webpages, there is no clear set of for -std= in the User's manuals on the webpages. For example, "clang -std=iso9899:1990" apparently is valid, but google find no instances of this construct. A search of clang.llvm.org does not find this construct. Surprising doing something complete stupid give` % cc -std=fubar -c a.c error: invalid value 'fubar' in '-std=fubar' note: use 'c89', 'c90', or 'iso9899:1990' for 'ISO C 1990' standard note: use 'iso9899:199409' for 'ISO C 1990 with amendment 1' standard note: use 'gnu89' or 'gnu90' for 'ISO C 1990 with GNU extensions' standard note: use 'c99' or 'iso9899:1999' for 'ISO C 1999' standard note: use 'gnu99' for 'ISO C 1999 with GNU extensions' standard note: use 'c11' or 'iso9899:2011' for 'ISO C 2011' standard note: use 'gnu11' for 'ISO C 2011 with GNU extensions' standard note: use 'c17' or 'iso9899:2017' for 'ISO C 2017' standard note: use 'gnu17' for 'ISO C 2017 with GNU extensions' standard % clang++ -std=fubar a.cxx error: invalid value 'fubar' in '-std=fubar' note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard note: use 'c++11' for 'ISO C++ 2011 with amendments' standard note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard note: use 'c++14' for 'ISO C++ 2014 with amendments' standard note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard note: use 'c++17' for 'ISO C++ 2017 with amendments' standard note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard note: use 'c++2a' for 'Working draft for ISO C++ 2020' standard note: use 'gnu++2a' for 'Working draft for ISO C++ 2020 with GNU extensions' standard This information belongs in a manpage. -- Steve From owner-freebsd-current@freebsd.org Fri Apr 6 07:32:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 896E9F8C45A for ; Fri, 6 Apr 2018 07:32:21 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2125E6A72D for ; Fri, 6 Apr 2018 07:32:21 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CFA6FF8C459; Fri, 6 Apr 2018 07:32:20 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBEE9F8C458 for ; Fri, 6 Apr 2018 07:32:20 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 52F7D6A72B for ; Fri, 6 Apr 2018 07:32:20 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from localhost (vpn.classit.ro [31.14.161.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id 0A78F46660D; Fri, 6 Apr 2018 10:32:18 +0300 (EEST) Date: Fri, 6 Apr 2018 10:32:13 +0300 From: Ion-Mihai Tetcu To: "Rodney W. Grimes" Cc: current@freebsd.org Subject: Re: failing to install 11.1R on VMWare Message-ID: <20180406103213.00004eac@FreeBSD.org> In-Reply-To: <201804060538.w365cpRY001165@pdx.rh.CN85.dnsmgr.net> References: <20180405233547.000061b5@FreeBSD.org> <201804060538.w365cpRY001165@pdx.rh.CN85.dnsmgr.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 180405-12, 2018-04-05), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 07:32:21 -0000 On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) "Rodney W. Grimes" wrote: > > Hi, > > > > > > I'm trying to install FreeBSD on : > > VMWare ESXi, 6.0.0, 5050593 > > > > Guest OS: FreeBSD (64-bit) > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > For 11.1R I'm getting the boot menu, then: > > /boot/kernel/kernel text=014972f8 > > elf64_loadimage: read failed > > can't load file: '/boot/kernel/kernel': input/output error > > ... > > (for 10.4R similar just with a different address). > > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the > > other available options with the same result). > > > > VMWare docs list both 10 and 11 as being compatible with this > > version of ESXi. > > Any pointers to get through this will be greatly appreciated, I > > didn't found anything on the net, and I need a sane system to play > > with when I'm getting tired of the ton of Linux distros I'm forced > > to use. > > Try setting the BIOS emulation to BIOS instead of UEFI. The WM is set: Firmware: BIOS. Boot Delay: 0ms Force BIOS setup: No Failed boot recovery: Do not automatically retry after virtual machine fails to find a boot device EFI Secure Boot: Disabled > And what image are you trying to boot from? > Are you trying to boot from a cd attached via vsphere client? or > is it a file on the server? I've uploaded the ISOs on one of the data stores on the server, didn't even tried from the client. > I usually use a .ISO when working with ESXi and FreeBSD as a guest. I'll try with the vmdk image of the release now. > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0. Hm, I guess I could try on 6.5 as an other cluster with has hosts running VMware ESXi, 6.5.0, 4564106 -- IOnut --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-current@freebsd.org Fri Apr 6 11:25:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89EAAF9DD5B for ; Fri, 6 Apr 2018 11:25:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFAFD753C8; Fri, 6 Apr 2018 11:25:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 69FBB44DC2; Fri, 6 Apr 2018 13:25:55 +0200 (CEST) From: Dimitry Andric Message-Id: <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_95A0DA1D-D80C-491D-806D-2AAD8F0B5185"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: clang manual page? Date: Fri, 6 Apr 2018 13:25:54 +0200 In-Reply-To: <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> Cc: Pete Wright , Steve Kargl , Conrad Meyer , freebsd-current , Ed Maste To: David Chisnall References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 11:25:57 -0000 --Apple-Mail=_95A0DA1D-D80C-491D-806D-2AAD8F0B5185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Apr 2018, at 07:20, David Chisnall wrote: >=20 > On 6 Apr 2018, at 01:30, Pete Wright wrote: >>=20 >> On 04/05/2018 17:15, Steve Kargl wrote: >>> This assumes that a gcc(1) is available on the system. >>>=20 >>> % man gcc >>> No manual entry for gcc >>>=20 >>> If the system compiler is clang/clang++, then it ought to be >>> documented better than it currently is. Ian's suggests for >>> 'clang --help' is even worse >>>=20 >>> % clang --help | grep -- -std >>> -cl-std=3D OpenCL language standard to compile for. >>> -std=3D Language standard to compile for >>> -stdlib=3D C++ standard library to use >>>=20 >>> Does =3D=3D ? >>>=20 >> a quick google search turns up the following additional information: >>=20 >> "clang supports the -std option, which changes what language mode = clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, = gnu11, c17, gnu17, and various aliases for those modes. If no -std = option is specified, clang defaults to gnu11 mode. Many C99 and C11 = features are supported in earlier modes as a conforming extension, with = a warning. Use |-pedantic-errors| to request an error if a feature from = a later standard revision is used in an earlier mode." >>=20 >> https://clang.llvm.org/docs/UsersManual.html >=20 > I believe that the clang user manual referenced here is written in = Sphynx, which is able to generate mandoc output as well as HTML. = Perhaps we should incorporate the generated file in the next import? Yes, but that manual is also pretty much incomplete, so with the last import I decided to stay with the older perl doc based one. Upstream is pretty bad at writing detailed documentation, certainly in the form of man pages. With lld there wasn't even *any* form of command line documentation yet, which is why Ed slapped together a man page (that could probably still use more details). It should really be upstreamed, in Sphinx's RST format, or since they appear to gravitate towards Markdown now, maybe already in that format. For a clang man page I'd really prefer working with upstream to get some more details in there, like an exhaustive list of which -std=3D options are supported. But it's quite a lot of effort. -Dimitry --Apple-Mail=_95A0DA1D-D80C-491D-806D-2AAD8F0B5185 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsdZQgAKCRCwXqMKLiCW o/iMAKDMyrCe5xX5c+vesSqV82wWkrAiqwCgvnwsJq+rdKZj0ZFwjHON6lIMAPk= =a20P -----END PGP SIGNATURE----- --Apple-Mail=_95A0DA1D-D80C-491D-806D-2AAD8F0B5185-- From owner-freebsd-current@freebsd.org Fri Apr 6 12:32:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AF43F81472 for ; Fri, 6 Apr 2018 12:32:14 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B28C9788E0 for ; Fri, 6 Apr 2018 12:32:13 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id x9-v6so859368oig.7 for ; Fri, 06 Apr 2018 05:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:subject:date:message-id:mime-version; bh=gyFdAIp4ikvq17Vf3+id+I0ycKkXG0V1uvFsQaV+Tj4=; b=lLBOxeH45PMwbxq6LgjEeSBn+OXBc7Am3gc78NoeYLNAMcRfTJvhWp0tVY5ViwEKjN bCj8dSkKnKOlCv/FIyW3rOPc/rFMkHWFnUgDwNzteLQsoWksnXOdGY4F6nkiuKUeMCZl RDfTpE2dgukoChx+XXo13yMlNACZPlSnO9o6e5uN8OjJoArmjjOdzH/FS1KRlIA5yzUu BwW7huqOhKRM7iHDkDbOYDCo6B3CKpUjxY8YzMnmFPSRxkkog79PuCyY8Y1bZ3rHjHpS 0DpiOPwXrpkypK4QnE37mgVWOUvRbO/x/h2SUFYXDKFvUHh5rEQXzqfXiTK3m/xeLRL+ SOfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:subject:date:message-id :mime-version; bh=gyFdAIp4ikvq17Vf3+id+I0ycKkXG0V1uvFsQaV+Tj4=; b=CL8jnqns8iZrbqKO+c16iJZkJE1fQWZrBRcwdPeHieLkRQiVQ5Mjk+9kuNtRE81N2o wSm+P8VNAsNtjHWS/qhQJ4dNU4ADsRp9ALT8+pcbBtcCDCbAgnPxz+vjKWctW/cygaA0 517ul7F3kdMz0YeKZ9zQjuSUtyhs+NtBK5/JYrjduzokX6vE2iAdWwhzq240UIqCxRma VajU8WvXUVHAaQQKrj6VmAXdn7MlfFgIupYZ4ttmCSVt+ProCfTZRsqyl4fieOj+fCcZ Z5WuuBDNYNH0r0jHcVrz36bkk7vgTA8XBu+OccdyTWczkDoEaSg8lHkR6ontdHIRhwi5 tjKQ== X-Gm-Message-State: AElRT7Htu2yAZrs1w3X5dqNDulrot+9cqy56XjEuG7k7bSUZB8LUxj/Y daT0IL/kKUGf/ePKQrIM6KzCow== X-Google-Smtp-Source: AIpwx48INOLjCCm6O2uGXlwWVciJoiCKcN1cL7PpW3jIBzn8rw96Kg53BssnkgSpSaC6M4QWYCRidw== X-Received: by 2002:aca:b103:: with SMTP id a3-v6mr14230688oif.135.1523017932701; Fri, 06 Apr 2018 05:32:12 -0700 (PDT) Received: from jd.gmail.com ([81.174.250.12]) by smtp.gmail.com with ESMTPSA id i29-v6sm5824128ote.65.2018.04.06.05.32.10 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Apr 2018 05:32:11 -0700 (PDT) User-agent: mu4e 1.0; emacs 25.3.1 From: Johannes Lundberg To: freebsd-current Subject: netmap with ix/igb? Date: Fri, 06 Apr 2018 13:32:05 +0100 Message-ID: <86vad4tt16.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:32:14 -0000 Hi I'm having problems* using netmap with 12-CURRENT from late 2017. Anyone know if a newer kernel would work better? * 748.120847 nm_open [898] NIOCREGIF failed: Invalid argument ix0 748.120850 main [2479] Unable to open netmap:ix0: Invalid argument /Johannes From owner-freebsd-current@freebsd.org Fri Apr 6 12:46:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D746F82724 for ; Fri, 6 Apr 2018 12:46:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5783794CA for ; Fri, 6 Apr 2018 12:46:13 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1f4Qkv-000KqE-D9; Fri, 06 Apr 2018 14:46:13 +0200 Date: Fri, 6 Apr 2018 14:46:13 +0200 From: Kurt Jaeger To: Johannes Lundberg Cc: freebsd-current Subject: Re: netmap with ix/igb? Message-ID: <20180406124613.GA37752@home.opsec.eu> References: <86vad4tt16.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86vad4tt16.fsf@gmail.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:46:14 -0000 Hi! > I'm having problems* using netmap with 12-CURRENT from late 2017. Anyone > know if a newer kernel would work better? Something like this ? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317 Look in bugs.freebsd.org for ixgbe, there are several other issues. -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Fri Apr 6 15:08:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 160FCF8CAC5 for ; Fri, 6 Apr 2018 15:08:19 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9588680164 for ; Fri, 6 Apr 2018 15:08:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x231.google.com with SMTP id d6so2094328iog.1 for ; Fri, 06 Apr 2018 08:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DgOGwv5f/QW1YXNyK2c7YcdC4EXyKd1gJ39ACYvvJ0g=; b=QjN/wtQueAI1Mlfriop1xrkZ6eWfmP+5PEf6B5E2oKbYjgryqXDEJ/pqpt5RXxMd/w YifIiSROSAGkiZkilXIj0XmL85L8iTEn3SM2vtDs8WLf/dl5kMdKgPuujy/pYkhqWmj7 w3Mzr4f09t9BrtJs3vYOM/oksB1wE0sE1qmB+GAompTiMXA8JGCGj2buvyaSABAhYV46 TQBlSH2rRKjINGye8ErM83zHKGpKw8WwA+bBzDNVfLsQfasqfmJioOFfkDkvoFSq8axv mPt7bze3aggumwXn8qCVO4YIFf4KwonCkBw5CRDyc+K1Mj3gGKoy9oSCxOuGyOi++6fZ df3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=DgOGwv5f/QW1YXNyK2c7YcdC4EXyKd1gJ39ACYvvJ0g=; b=RdNoQ8wD32UxshtVaZpZXQXPSwTuu2rgN5YYIePgWmxllpSYeFpTcLWf9PJp2h7aW6 +1zzV8e3BFdViTOHaTtacVpH58sBVkIgbYZvKLREGBVhyx6FNYWotqS2gJG6tgb/+KPR 4tEiWTgtl+F1Q7tu0GktuLYXIYUUnjxoegda0iEPZYuf6PB2yhDatoAh0QZ1Z5RTFL7G c7m2QWTfLfCB/UJgQpt7GDAS58OeCWiATXOeA7LYz01MKnEWIav+DPwAXHd9XGQ6IjvA zQqQzK+uBj9xCZS7Jo2j1kno+lemXYPVPl3PFPyS8qzHF9uuPvfgiiJyFlB6CU7exQHp uCIA== X-Gm-Message-State: ALQs6tCTinuPbxnToNRTY9PMfcRp8RUWjgboKGMEc6QXMp1wE2KbDIf7 pzmW1Asu918mPONTUU2Slos= X-Google-Smtp-Source: AIpwx4+oJNXEjsFOTuKJAnVZfg6c7FYSDmt9wHnm61ZWcSLi6J50gUHZXhQvM7Cy5IgUNXGOjtcD8w== X-Received: by 10.107.8.32 with SMTP id 32mr23569455ioi.136.1523027297716; Fri, 06 Apr 2018 08:08:17 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id d11sm4157883ioc.13.2018.04.06.08.08.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 08:08:16 -0700 (PDT) Sender: Mark Johnston Date: Fri, 6 Apr 2018 11:08:14 -0400 From: Mark Johnston To: Justin Hibbits Cc: Jeff Roberson , FreeBSD current Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT Message-ID: <20180406150814.GB10017@raichu> References: <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:08:19 -0000 On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote: > My powerpc64 embedded machine is virtually unusable since these vm changes. > I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help > at all. Eventually the machine hangs and just gets stuck in vmdaemon, with > many processes in wait channel btalloc. You don't really have the same symptoms that Don is reporting. Threads being stuck in btalloc implies a KVA shortage. So: - What do you mean by "stuck in vmdaemon"? - Which commits specifically cause problems? Does reverting r329882 fix the hang? - Can you break to DDB and get "show page" output when the hang occurs? - What is the system doing to cause the hang to occur? From owner-freebsd-current@freebsd.org Fri Apr 6 15:25:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44FB1F8E369 for ; Fri, 6 Apr 2018 15:25:10 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A57CA81736; Fri, 6 Apr 2018 15:25:09 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id e5-v6so1090084lfb.7; Fri, 06 Apr 2018 08:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=72DRAhTNJtiE73UkqYK2PZcQraHGIEh1l+RX7zLyWYA=; b=L5rA2Qzs44EKo04t2SmhYDNZYjXbvFVZgpeRCSPh+dIfHBRIGziKpIPfgtiOOJsxKv D1vKv7Pkk8RN4kruvsc/6FVMyzyFZ+zW7xgpmrUBUNTyn2SA3MuiPR835iTWVKabuAsL CNQWxg4RWSnGwbA2JepSx09dafjTC35NcasigVRZvDeFktHTc6hLkka/gfv5sATfT0Om CMVzQv6oZV5mJaVdXuwmnD9bNeyF9XkZuVx9vLPCdvLmAeCdVRtKzNoS6wE8mBzD8m/e d+6i2dTAzu+zSh6aRbLu2AXbEmvMtOttG8Nl33lCymi4jFk9e3hGc2zS1C9ILUi35y5w PytQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=72DRAhTNJtiE73UkqYK2PZcQraHGIEh1l+RX7zLyWYA=; b=Uu2vO7ldGNmCBycy/Lpt8xMkJPuO2CwScymzJKf3k8YQxhHxWftRj4eSUtB6FekzzU XgpOFCo+RFmnZNcVVy4lDrszdI0U0Cz0Sk2zA7vOZ5fI+gvd0vx/nhUlgtYscHe9PG96 xeV+BecgmkPnNXIHpTDQ3SZi59q82CDPhMM8DI9qkKE2rM4wLkLSnjAmeI6/DGnGJzH5 yj1XgYFqrs+cFgFcaA4yqMQZ4H7VddDYWe+7wQY4zAm/Xihtj2BJADNv9pZALUydctBB WqtddpHcAgy7YZP+Od+lNo1GXVBVUHurhHC+oCWCHoaZQ/DiORDnw+9zht7+QTpR7JTT pzgQ== X-Gm-Message-State: AElRT7FkntggXWIR6mP/1sNm0N9HrSTnZnpcwTVQFkUFYb43pw/Mgihu jgNAck8y+eYqbqxRk3EFBq0oCgVHXwsHjRWPqQU= X-Google-Smtp-Source: AIpwx48f6oZ0+5vMBFFjJcbHLY+Dq8rm6VUi3dCVQnTX/T6SMp2oP2vuHfz7EwRUE+ESlwJ4Rj0IL/zHqC6IyoBipEk= X-Received: by 10.46.112.24 with SMTP id l24mr17310931ljc.104.1523028307358; Fri, 06 Apr 2018 08:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.85.13 with HTTP; Fri, 6 Apr 2018 08:25:06 -0700 (PDT) In-Reply-To: <20180406150814.GB10017@raichu> References: <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> From: Justin Hibbits Date: Fri, 6 Apr 2018 10:25:06 -0500 Message-ID: Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston Cc: Jeff Roberson , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:25:10 -0000 On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston wrote: > On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote: >> My powerpc64 embedded machine is virtually unusable since these vm changes. >> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help >> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with >> many processes in wait channel btalloc. > > You don't really have the same symptoms that Don is reporting. Okay. I latched onto the thread because it seemed similar. > Threads being stuck in btalloc implies a KVA shortage. So: > - What do you mean by "stuck in vmdaemon"? The machine hangs, and my ssh sessions get killed. I can't do anything at the console except break into kdb. When I do, the running thread is always vmdaemon. > - Which commits specifically cause problems? Does reverting r329882 fix the > hang? I'll try reverting it and report back. Thankfully I can buildkernel successfully on the machine before it hangs. Can't do more than that, though. > - Can you break to DDB and get "show page" output when the hang occurs? I'll reproduce and get numbers today, but I do know the free_count was high (6 digits), much higher than the free_min. when I checked yesterday. I'm surprised it's running out of KVA, I've never had the problem before with the same workloads, and has ~7.5GB KVA (almost the same size as the total RAM in the machine). > - What is the system doing to cause the hang to occur? Just a simple buildworld with 2 or 3 jobs (tried both). It's 100% reproducible. - Justin From owner-freebsd-current@freebsd.org Fri Apr 6 15:39:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39522F8F5AE for ; Fri, 6 Apr 2018 15:39:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CDDE082032 for ; Fri, 6 Apr 2018 15:39:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8E506F8F5A9; Fri, 6 Apr 2018 15:39:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BB82F8F5A8 for ; Fri, 6 Apr 2018 15:39:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB84A8202F; Fri, 6 Apr 2018 15:39:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w36FdRBJ003221; Fri, 6 Apr 2018 08:39:27 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w36FdRZc003220; Fri, 6 Apr 2018 08:39:27 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804061539.w36FdRZc003220@pdx.rh.CN85.dnsmgr.net> Subject: Re: failing to install 11.1R on VMWare In-Reply-To: <20180406103213.00004eac@FreeBSD.org> To: Ion-Mihai Tetcu Date: Fri, 6 Apr 2018 08:39:27 -0700 (PDT) CC: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:39:36 -0000 > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > "Rodney W. Grimes" wrote: > > > > Hi, > > > > > > > > > I'm trying to install FreeBSD on : > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > Guest OS: FreeBSD (64-bit) > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > For 11.1R I'm getting the boot menu, then: > > > /boot/kernel/kernel text=014972f8 > > > elf64_loadimage: read failed > > > can't load file: '/boot/kernel/kernel': input/output error > > > ... > > > (for 10.4R similar just with a different address). > > > > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the > > > other available options with the same result). > > > > > > VMWare docs list both 10 and 11 as being compatible with this > > > version of ESXi. > > > Any pointers to get through this will be greatly appreciated, I > > > didn't found anything on the net, and I need a sane system to play > > > with when I'm getting tired of the ton of Linux distros I'm forced > > > to use. > > > > Try setting the BIOS emulation to BIOS instead of UEFI. > > The WM is set: > Firmware: BIOS. > Boot Delay: 0ms > Force BIOS setup: No > Failed boot recovery: Do not automatically retry after virtual machine fails to find a boot device > EFI Secure Boot: Disabled Those all look good from my experience. > > And what image are you trying to boot from? > > Are you trying to boot from a cd attached via vsphere client? or > > is it a file on the server? > > I've uploaded the ISOs on one of the data stores on the server, didn't > even tried from the client. Ok, so that is also the same procedure I am trying. Now, which .ISO is it? Maybe you have a broken snapshots. Lots of bootcode work has been going on in -current. Can you try the 11.1 release ISO either i386 or amd64? I know that installs as I have done that many times. > > I usually use a .ISO when working with ESXi and FreeBSD as a guest. > > I'll try with the vmdk image of the release now. I have NOT ever tried that, so have no data there. > > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0. > > Hm, I guess I could try on 6.5 as an other cluster with has hosts > running VMware ESXi, 6.5.0, 4564106 It should just work, I have played with ESXi 6.0.0 at one time or another and would have a good recollection if I had issues booting any FreeBSD distributions on it. At present I do not have any 6.0.0 running, though I could fix that in a matter of minutes. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Apr 6 17:33:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA3A4F98972 for ; Fri, 6 Apr 2018 17:33:37 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEBA6ABC8; Fri, 6 Apr 2018 17:33:37 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w36HYiYl079898 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Apr 2018 17:34:46 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w36HXOrb072284 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 10:33:27 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Fri, 6 Apr 2018 10:33:26 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston cc: Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: <20180404174949.GA12271@raichu> Message-ID: References: <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:33:38 -0000 On 4 Apr, Mark Johnston wrote: > On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >> On 3 Apr, Don Lewis wrote: >> > I reconfigured my Ryzen box to be more similar to my default package >> > builder by disabling SMT and half of the RAM, to limit it to 8 cores >> > and 32 GB and then started bisecting to try to track down the problem. >> > For each test, I first filled ARC by tarring /usr/ports/distfiles to >> > /dev/null. The commit range that I was searching was r329844 to >> > r331716. I narrowed the range to r329844 to r329904. With r329904 >> > and newer, ARC is totally unresponsive to memory pressure and the >> > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired >> > RAM, so there is not much leftover for getting useful work done. Active >> > memory and free memory both hover under 1GB each. Looking at the >> > commit logs over this range, the most likely culprit is: >> > >> > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines >> > >> > Add a generic Proportional Integral Derivative (PID) controller algorithm and >> > use it to regulate page daemon output. >> > >> > This provides much smoother and more responsive page daemon output, anticipating >> > demand and avoiding pageout stalls by increasing the number of pages to match >> > the workload. This is a reimplementation of work done by myself and mlaier at >> > Isilon. >> > >> > >> > It is quite possible that the recent fixes to the PID controller will >> > fix the problem. Not that r329844 was trouble free ... I left tar >> > running over lunchtime to fill ARC and the OOM killer nuked top, tar, >> > ntpd, both of my ssh sessions into the machine, and multiple instances >> > of getty while I was away. I was able to log in again and successfully >> > run poudriere, and ARC did respond to the memory pressure and cranked >> > itself down to about 5 GB by the end of the run. I did not see the same >> > problem with tar when I did the same with r329904. >> >> I just tried r331966 and see no improvement. No OOM process kills >> during the tar run to fill ARC, but with ARC filled, the machine is >> thrashing itself at the start of the poudriere run while trying to build >> ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to >> memory demand. I've seen no decrease in ARC size or wired memory since >> starting poudriere. > > Re-reading the ARC reclaim code, I see a couple of issues which might be > at the root of the behaviour you're seeing. > > 1. zfs_arc_free_target is too low now. It is initialized to the page > daemon wakeup threshold, which is slightly above v_free_min. With the > PID controller, the page daemon uses a setpoint of v_free_target. > Moreover, it now wakes up regularly rather than having wakeups be > synchronized by a mutex, so it will respond quickly if the free page > count dips below v_free_target. The free page count will dip below > zfs_arc_free_target only in the face of sudden and extreme memory > pressure now, so the FMT_LOTSFREE case probably isn't getting > exercised. Try initializing zfs_arc_free_target to v_free_target. > > 2. In the inactive queue scan, we used to compute the shortage after > running uma_reclaim() and the lowmem handlers (which includes a > synchronous call to arc_lowmem()). Now it's computed before, so we're > not taking into account the pages that get freed by the ARC and UMA. > The following rather hacky patch may help. I note that the lowmem > logic is now somewhat broken when multiple NUMA domains are > configured, however, since it fires only when domain 0 has a free > page shortage. > > Index: sys/vm/vm_pageout.c > =================================================================== > --- sys/vm/vm_pageout.c (revision 331933) > +++ sys/vm/vm_pageout.c (working copy) > @@ -1114,25 +1114,6 @@ > boolean_t queue_locked; > > /* > - * If we need to reclaim memory ask kernel caches to return > - * some. We rate limit to avoid thrashing. > - */ > - if (vmd == VM_DOMAIN(0) && pass > 0 && > - (time_uptime - lowmem_uptime) >= lowmem_period) { > - /* > - * Decrease registered cache sizes. > - */ > - SDT_PROBE0(vm, , , vm__lowmem_scan); > - EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > - /* > - * We do this explicitly after the caches have been > - * drained above. > - */ > - uma_reclaim(); > - lowmem_uptime = time_uptime; > - } > - > - /* > * The addl_page_shortage is the number of temporarily > * stuck pages in the inactive queue. In other words, the > * number of pages from the inactive count that should be > @@ -1824,6 +1805,26 @@ > atomic_store_int(&vmd->vmd_pageout_wanted, 1); > > /* > + * If we need to reclaim memory ask kernel caches to return > + * some. We rate limit to avoid thrashing. > + */ > + if (vmd == VM_DOMAIN(0) && > + vmd->vmd_free_count < vmd->vmd_free_target && > + (time_uptime - lowmem_uptime) >= lowmem_period) { > + /* > + * Decrease registered cache sizes. > + */ > + SDT_PROBE0(vm, , , vm__lowmem_scan); > + EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES); > + /* > + * We do this explicitly after the caches have been > + * drained above. > + */ > + uma_reclaim(); > + lowmem_uptime = time_uptime; > + } > + > + /* > * Use the controller to calculate how many pages to free in > * this interval. > */ From owner-freebsd-current@freebsd.org Fri Apr 6 17:33:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA33AF98971 for ; Fri, 6 Apr 2018 17:33:37 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C7E46ABC7; Fri, 6 Apr 2018 17:33:37 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w36HYhgQ079897 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Apr 2018 17:34:46 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w36HXOrY072284 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 10:33:25 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Fri, 6 Apr 2018 10:33:19 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston cc: Andriy Gapon , Bryan Drewery , Peter Jeremy , Jeff Roberson , FreeBSD current In-Reply-To: Message-ID: References: <20180306221554.uyshbzbboai62rdf@dx240.localdomain> <20180307103911.GA72239@kloomba> <20180311004737.3441dbf9@thor.intern.walstatt.dynvpn.de> <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:33:38 -0000 On 4 Apr, Don Lewis wrote: > On 4 Apr, Mark Johnston wrote: >> On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >>> On 3 Apr, Don Lewis wrote: >>> > I reconfigured my Ryzen box to be more similar to my default package >>> > builder by disabling SMT and half of the RAM, to limit it to 8 cores >>> > and 32 GB and then started bisecting to try to track down the problem. >>> > For each test, I first filled ARC by tarring /usr/ports/distfiles to >>> > /dev/null. The commit range that I was searching was r329844 to >>> > r331716. I narrowed the range to r329844 to r329904. With r329904 >>> > and newer, ARC is totally unresponsive to memory pressure and the >>> > machine pages heavily. I see ARC sizes of 28-29GB and 30GB of wired >>> > RAM, so there is not much leftover for getting useful work done. Active >>> > memory and free memory both hover under 1GB each. Looking at the >>> > commit logs over this range, the most likely culprit is: >>> > >>> > r329882 | jeff | 2018-02-23 14:51:51 -0800 (Fri, 23 Feb 2018) | 13 lines >>> > >>> > Add a generic Proportional Integral Derivative (PID) controller algorithm and >>> > use it to regulate page daemon output. >>> > >>> > This provides much smoother and more responsive page daemon output, anticipating >>> > demand and avoiding pageout stalls by increasing the number of pages to match >>> > the workload. This is a reimplementation of work done by myself and mlaier at >>> > Isilon. >>> > >>> > >>> > It is quite possible that the recent fixes to the PID controller will >>> > fix the problem. Not that r329844 was trouble free ... I left tar >>> > running over lunchtime to fill ARC and the OOM killer nuked top, tar, >>> > ntpd, both of my ssh sessions into the machine, and multiple instances >>> > of getty while I was away. I was able to log in again and successfully >>> > run poudriere, and ARC did respond to the memory pressure and cranked >>> > itself down to about 5 GB by the end of the run. I did not see the same >>> > problem with tar when I did the same with r329904. >>> >>> I just tried r331966 and see no improvement. No OOM process kills >>> during the tar run to fill ARC, but with ARC filled, the machine is >>> thrashing itself at the start of the poudriere run while trying to build >>> ports-mgmt/pkg (39 minutes so far). ARC appears to be unresponsive to >>> memory demand. I've seen no decrease in ARC size or wired memory since >>> starting poudriere. >> >> Re-reading the ARC reclaim code, I see a couple of issues which might be >> at the root of the behaviour you're seeing. >> >> 1. zfs_arc_free_target is too low now. It is initialized to the page >> daemon wakeup threshold, which is slightly above v_free_min. With the >> PID controller, the page daemon uses a setpoint of v_free_target. >> Moreover, it now wakes up regularly rather than having wakeups be >> synchronized by a mutex, so it will respond quickly if the free page >> count dips below v_free_target. The free page count will dip below >> zfs_arc_free_target only in the face of sudden and extreme memory >> pressure now, so the FMT_LOTSFREE case probably isn't getting >> exercised. Try initializing zfs_arc_free_target to v_free_target. > > Changing zfs_arc_free_target definitely helps. My previous poudriere > run failed when poudriere timed out the ports-mgmt/pkg build after two > hours. After changing this setting, poudriere seems to be running > properly and ARC has dropped from 29GB to 26GB ten minutes into the run > and I'm not seeing processes in the swread state. > >> 2. In the inactive queue scan, we used to compute the shortage after >> running uma_reclaim() and the lowmem handlers (which includes a >> synchronous call to arc_lowmem()). Now it's computed before, so we're >> not taking into account the pages that get freed by the ARC and UMA. >> The following rather hacky patch may help. I note that the lowmem >> logic is now somewhat broken when multiple NUMA domains are >> configured, however, since it fires only when domain 0 has a free >> page shortage. > > I will try this next. The patch by itself is not sufficient to fix the problem for me. I didn't have any problems with using the patch as well as setting zfs_arc_free_target. As a matter of fact, that was the only poudriere run where I didn't have a guile-related build failure. Those tend to be fairly random, so it could just be luck. Performance-wise r331966 + zfs_arc_free_target completes the poudriere run about 2.6% faster than r329844. But I don't know if this is the PID controller or something else that changed in base over that interval. From owner-freebsd-current@freebsd.org Fri Apr 6 17:40:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 794A2F99295 for ; Fri, 6 Apr 2018 17:40:32 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA2AC6B27E for ; Fri, 6 Apr 2018 17:40:31 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 96D04F99292; Fri, 6 Apr 2018 17:40:31 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7411BF99290 for ; Fri, 6 Apr 2018 17:40:31 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id A5DDB6B27B for ; Fri, 6 Apr 2018 17:40:30 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from localhost (vpn.classit.ro [31.14.161.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id A194046755F; Fri, 6 Apr 2018 20:40:28 +0300 (EEST) Date: Fri, 6 Apr 2018 20:40:10 +0300 From: Ion-Mihai Tetcu To: "Rodney W. Grimes" Cc: current@freebsd.org Subject: Re: failing to install 11.1R on VMWare Message-ID: <20180406204010.00006e84@FreeBSD.org> In-Reply-To: <201804061539.w36FdRZc003220@pdx.rh.CN85.dnsmgr.net> References: <20180406103213.00004eac@FreeBSD.org> <201804061539.w36FdRZc003220@pdx.rh.CN85.dnsmgr.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 180406-4, 2018-04-06), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:40:32 -0000 On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > "Rodney W. Grimes" wrote: > > > > > > Hi, > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > /boot/kernel/kernel text=014972f8 > > > > elf64_loadimage: read failed > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > ... > > > > (for 10.4R similar just with a different address). > > > > > > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried > > > > with the other available options with the same result). > > > > > > > > VMWare docs list both 10 and 11 as being compatible with this > > > > version of ESXi. > > > > Any pointers to get through this will be greatly appreciated, I > > > > didn't found anything on the net, and I need a sane system to > > > > play with when I'm getting tired of the ton of Linux distros > > > > I'm forced to use. > > > > > > Try setting the BIOS emulation to BIOS instead of UEFI. > > > > The WM is set: > > Firmware: BIOS. > > Boot Delay: 0ms > > Force BIOS setup: No > > Failed boot recovery: Do not automatically retry after virtual > > machine fails to find a boot device EFI Secure Boot: Disabled > > Those all look good from my experience. > > > > And what image are you trying to boot from? > > > Are you trying to boot from a cd attached via vsphere client? or > > > is it a file on the server? > > > > I've uploaded the ISOs on one of the data stores on the server, > > didn't even tried from the client. > > Ok, so that is also the same procedure I am trying. > > Now, which .ISO is it? Maybe you have a broken snapshots. Lots of > bootcode work has been going on in -current. Can you try the 11.1 > release ISO either i386 or amd64? > > I know that installs as I have done that many times. FreeBSD-11.1-RELEASE-amd64-dvd1.iso FreeBSD-11.1-RELEASE-amd64-bootonly.iso Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the data store and checked the sha256 against the one on the ftp site and it's OK, so except if vshpere somehow corrupts files on upload and fixes them on download I think the image is OK. > > > I usually use a .ISO when working with ESXi and FreeBSD as a > > > guest. > > > > I'll try with the vmdk image of the release now. > > I have NOT ever tried that, so have no data there. > > > > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any > > > 6.0.0. > > > > Hm, I guess I could try on 6.5 as an other cluster with has hosts > > running VMware ESXi, 6.5.0, 4564106 > > It should just work, I have played with ESXi 6.0.0 at one > time or another and would have a good recollection if I had issues > booting any FreeBSD distributions on it. At present I do not have > any 6.0.0 running, though I could fix that in a matter of minutes. I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything else) and got the same result trying to boot the 10.4R boot-only ISO). Would it make any diff if I create the VM from scratch on that host? Tnx, -- IOnut Tetcu --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-current@freebsd.org Fri Apr 6 18:30:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FE1EF9CB2B for ; Fri, 6 Apr 2018 18:30:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A24F76DB2F for ; Fri, 6 Apr 2018 18:30:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5C8ACF9CB20; Fri, 6 Apr 2018 18:30:32 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37F81F9CB1F for ; Fri, 6 Apr 2018 18:30:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6940D6DAF8; Fri, 6 Apr 2018 18:30:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w36IUQwd004047; Fri, 6 Apr 2018 11:30:26 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w36IUQbj004046; Fri, 6 Apr 2018 11:30:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> Subject: Re: failing to install 11.1R on VMWare In-Reply-To: <20180406204010.00006e84@FreeBSD.org> To: Ion-Mihai Tetcu Date: Fri, 6 Apr 2018 11:30:26 -0700 (PDT) CC: current@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:30:33 -0000 > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > "Rodney W. Grimes" wrote: > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > "Rodney W. Grimes" wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > /boot/kernel/kernel text=014972f8 > > > > > elf64_loadimage: read failed > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > ... > > > > > (for 10.4R similar just with a different address). > > > > > > > > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried > > > > > with the other available options with the same result). > > > > > > > > > > VMWare docs list both 10 and 11 as being compatible with this > > > > > version of ESXi. > > > > > Any pointers to get through this will be greatly appreciated, I > > > > > didn't found anything on the net, and I need a sane system to > > > > > play with when I'm getting tired of the ton of Linux distros > > > > > I'm forced to use. > > > > > > > > Try setting the BIOS emulation to BIOS instead of UEFI. > > > > > > The WM is set: > > > Firmware: BIOS. > > > Boot Delay: 0ms > > > Force BIOS setup: No > > > Failed boot recovery: Do not automatically retry after virtual > > > machine fails to find a boot device EFI Secure Boot: Disabled > > > > Those all look good from my experience. > > > > > > And what image are you trying to boot from? > > > > Are you trying to boot from a cd attached via vsphere client? or > > > > is it a file on the server? > > > > > > I've uploaded the ISOs on one of the data stores on the server, > > > didn't even tried from the client. > > > > Ok, so that is also the same procedure I am trying. > > > > Now, which .ISO is it? Maybe you have a broken snapshots. Lots of > > bootcode work has been going on in -current. Can you try the 11.1 > > release ISO either i386 or amd64? > > > > I know that installs as I have done that many times. > > FreeBSD-11.1-RELEASE-amd64-dvd1.iso > FreeBSD-11.1-RELEASE-amd64-bootonly.iso > Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso > > I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the > data store and checked the sha256 against the one on the ftp site and > it's OK, so except if vshpere somehow corrupts files on upload and > fixes them on download I think the image is OK. And of somewhat known status, I usually use the disc1, but that should not matter... unless the dvd emulation is scewing things up. But the bootonly.iso should be fine, that is under 700MB > > > > I usually use a .ISO when working with ESXi and FreeBSD as a > > > > guest. > > > > > > I'll try with the vmdk image of the release now. > > > > I have NOT ever tried that, so have no data there. > > > > > > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any > > > > 6.0.0. > > > > > > Hm, I guess I could try on 6.5 as an other cluster with has hosts > > > running VMware ESXi, 6.5.0, 4564106 > > > > It should just work, I have played with ESXi 6.0.0 at one > > time or another and would have a good recollection if I had issues > > booting any FreeBSD distributions on it. At present I do not have > > any 6.0.0 running, though I could fix that in a matter of minutes. > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything > else) and got the same result trying to boot the 10.4R boot-only ISO). > Would it make any diff if I create the VM from scratch on that host? Um, moving .vmx files around between versions of vsphere has to be done with a good deal of care, and given your having "issues" to start with I would not add that complexity to this problem. Create an new empty vm on 6.5.0, and use HW level 8, that is portable accross 5.5 to 6.5. Also try sticking with ONLY IDE disks and cdrom, that might be causing an issue. Then if it fails send me the .vmx file for the VM so I can look at it for differences in what I am using to seeing. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Apr 6 18:39:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5994FF9D9D9 for ; Fri, 6 Apr 2018 18:39:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E3F6E6E7D5; Fri, 6 Apr 2018 18:39:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w36IdhAt079378 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Apr 2018 11:39:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w36Idg3o079376; Fri, 6 Apr 2018 11:39:42 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Apr 2018 11:39:42 -0700 From: Steve Kargl To: Dimitry Andric Cc: David Chisnall , Pete Wright , Conrad Meyer , freebsd-current , Ed Maste Subject: Re: clang manual page? Message-ID: <20180406183942.GB78891@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:39:45 -0000 On Fri, Apr 06, 2018 at 01:25:54PM +0200, Dimitry Andric wrote: > Yes, but that manual is also pretty much incomplete, so with the last > import I decided to stay with the older perl doc based one. Upstream > is pretty bad at writing detailed documentation, certainly in the form > of man pages. > Index: clang.1 =================================================================== --- clang.1 (revision 332114) +++ clang.1 (working copy) @@ -128,15 +128,72 @@ .UNINDENT .INDENT 0.0 .TP -.B \-std= -Specify the language standard to compile for. +.B \-std= +Specify the language standard to enforce. + +A partial list of validate +.B +for the C programming language is +.INDENT 7.0 +.INDENT 3.5 +\fIc89\fP ISO/IEC 9899:1990 +.sp +\fIc90\fP ISO/IEC 9899:1990 +.sp +\fIc99\fP ISO/IEC 9899:1999 +.sp +\fIc11\fP ISO/IEC 9899:2011 +.sp +\fIc17\fP Working draft for ISO/EIC 9899:2017 +.sp +\fIgnu89\fP ISO/IEC 9899:1990 with GNU extensions +.sp +\fIgnu90\fP ISO/IEC 9899:1990 with GNU extensions +.sp +\fIgnu99\fP ISO/IEC 9899:1999 with GNU extensions +.sp +\fIgnu11\fP ISO/IEC 9899:2011 with GNU extensions +.sp +\fIgnu17\fP Draft for ISO/EIC 9899:2017 with GNU extensions .UNINDENT +.UNINDENT + +A partial list of validate +.B +for the C++ programming language is +.INDENT 7.0 +.INDENT 3.5 +\fIc++98\fP ISO/IEC 14882:1998 with amendments +.sp +\fIc++03\fP ISO/IEC 14882:2003 with amendments +.sp +\fIc++11\fP ISO/IEC 14882:2011 with amendments +.sp +\fIc++14\fP ISO/IEC 14882:2014 with amendments +.sp +\fIc++17\fP ISO/IEC 14882:2017 with amendments +.sp +\fIc++2a\fP Draft ISO/IEC 14882:2020 +.sp +\fIgnu++98\fP ISO/IEC 14882:1998 with amendments and GNU extensions +.sp +\fIgnu++03\fP ISO/IEC 14882:2003 with amendments and GNU extensions +.sp +\fIgnu++11\fP ISO/IEC 14882:2011 with amendments and GNU extensions +.sp +\fIgnu++14\fP ISO/IEC 14882:2014 with amendments and GNU extensions +.sp +\fIgnu++17\fP ISO/IEC 14882:2017 with amendments and GNU extensions +.sp +\fIgnu++2a\fP Draft ISO/IEC 14882:2020 with GNU extensions +.UNINDENT +.UNINDENT +.UNINDENT .INDENT 0.0 .TP .B \-stdlib= Specify the C++ standard library to use; supported options are libstdc++ and libc++. If not specified, platform default will be used. -.UNINDENT .INDENT 0.0 .TP .B \-rtlib= -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Apr 6 18:54:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30E12F9EC28 for ; Fri, 6 Apr 2018 18:54:55 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A8C4B6F622 for ; Fri, 6 Apr 2018 18:54:54 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: by mailman.ysv.freebsd.org (Postfix) id 6D191F9EC21; Fri, 6 Apr 2018 18:54:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B349F9EC20 for ; Fri, 6 Apr 2018 18:54:54 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id A9B836F61F; Fri, 6 Apr 2018 18:54:53 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Fri, 06 Apr 2018 20:51:24 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 8233D34B-792D-4387-A725-5CF3CCBCC0DE.1 envelope-from (authenticated bits=0); Fri, 06 Apr 2018 20:51:22 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: failing to install 11.1R on VMWare From: Rainer Duffner In-Reply-To: <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> Date: Fri, 6 Apr 2018 20:53:32 +0200 Cc: Ion-Mihai Tetcu , current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A505F36-A0E6-4A64-A0B1-53D6A6AD927E@ultra-secure.de> References: <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3445.6.18) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=12 total_conn=5 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 5329, bad: 2, connections: 5836, history: 5327, asn_score: 293, asn_connections: 310, asn_good: 293, asn_bad: 0, pass:asn, asn_all_good, relaying X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:54:55 -0000 Can you export the empty VM and make it available for download = somewhere? If you zero the disks with dd before exporting, it should compress very = nicely. I only have Fusion to test, though. From owner-freebsd-current@freebsd.org Fri Apr 6 20:08:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DE3CF8243B for ; Fri, 6 Apr 2018 20:08:40 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4675073D02 for ; Fri, 6 Apr 2018 20:08:40 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id w36JwuGM081701 for ; Fri, 6 Apr 2018 14:58:56 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.204] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id 506821939AC for ; Fri, 6 Apr 2018 14:58:51 -0500 (CDT) Subject: Re: failing to install 11.1R on VMWare To: freebsd-current@freebsd.org References: <20180406103213.00004eac@FreeBSD.org> <201804061539.w36FdRZc003220@pdx.rh.CN85.dnsmgr.net> <20180406204010.00006e84@FreeBSD.org> From: Matthew Grooms Message-ID: <85ac38fc-ae34-fdaf-c9c9-a17fb53fd863@shrew.net> Date: Fri, 6 Apr 2018 14:58:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180406204010.00006e84@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Fri, 06 Apr 2018 14:58:56 -0500 (CDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 20:08:40 -0000 On 4/6/2018 12:40 PM, Ion-Mihai Tetcu wrote: > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > "Rodney W. Grimes" wrote: > >>> On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) >>> "Rodney W. Grimes" wrote: >>> >>>>> Hi, >>>>> >>>>> >>>>> I'm trying to install FreeBSD on : >>>>> VMWare ESXi, 6.0.0, 5050593 >>>>> >>>>> Guest OS: FreeBSD (64-bit) >>>>> Compatibility: ESXi 6.0 and later (VM version 11) >>>>> >>>>> For 11.1R I'm getting the boot menu, then: >>>>> /boot/kernel/kernel text=014972f8 >>>>> elf64_loadimage: read failed >>>>> can't load file: '/boot/kernel/kernel': input/output error >>>>> ... >>>>> (for 10.4R similar just with a different address). >>>>> >>>>> SCSI Adapatr for the VM is set to LSI Logic (but I've tried >>>>> with the other available options with the same result). >>>>> >>>>> VMWare docs list both 10 and 11 as being compatible with this >>>>> version of ESXi. >>>>> Any pointers to get through this will be greatly appreciated, I >>>>> didn't found anything on the net, and I need a sane system to >>>>> play with when I'm getting tired of the ton of Linux distros >>>>> I'm forced to use. >>>> Try setting the BIOS emulation to BIOS instead of UEFI. >>> The WM is set: >>> Firmware: BIOS. >>> Boot Delay: 0ms >>> Force BIOS setup: No >>> Failed boot recovery: Do not automatically retry after virtual >>> machine fails to find a boot device EFI Secure Boot: Disabled >> Those all look good from my experience. >> >>>> And what image are you trying to boot from? >>>> Are you trying to boot from a cd attached via vsphere client? or >>>> is it a file on the server? >>> I've uploaded the ISOs on one of the data stores on the server, >>> didn't even tried from the client. >> Ok, so that is also the same procedure I am trying. >> >> Now, which .ISO is it? Maybe you have a broken snapshots. Lots of >> bootcode work has been going on in -current. Can you try the 11.1 >> release ISO either i386 or amd64? >> >> I know that installs as I have done that many times. > FreeBSD-11.1-RELEASE-amd64-dvd1.iso > FreeBSD-11.1-RELEASE-amd64-bootonly.iso > Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso > > I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the > data store and checked the sha256 against the one on the ftp site and > it's OK, so except if vshpere somehow corrupts files on upload and > fixes them on download I think the image is OK. > >>>> I usually use a .ISO when working with ESXi and FreeBSD as a >>>> guest. >>> I'll try with the vmdk image of the release now. >> I have NOT ever tried that, so have no data there. >> >>>> I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any >>>> 6.0.0. >>> Hm, I guess I could try on 6.5 as an other cluster with has hosts >>> running VMware ESXi, 6.5.0, 4564106 >> It should just work, I have played with ESXi 6.0.0 at one >> time or another and would have a good recollection if I had issues >> booting any FreeBSD distributions on it. At present I do not have >> any 6.0.0 running, though I could fix that in a matter of minutes. > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything > else) and got the same result trying to boot the 10.4R boot-only ISO). > Would it make any diff if I create the VM from scratch on that host? > I have about 40 FreeBSD 10.3/10.4 VMs that were installed on a vSphere ESXi v6.0 cluster that has since been upgraded recently to v6.5. As a test, I just booted 11.1 from an ISO ( FreeBSD-11.1-RELEASE-amd64-disc1 ) using the FreeBSD-64bit OS template defaults and it reaches the installer welcome screen without issue. Here is a copy of the vmx file if you'd like to compare. Perhaps your host is selecting a different set of defaults for some reason? ... [root@esxi1:/vmfs/volumes/552c8e27-b1f51fec-9bf8-90e2ba090e50/test-freebsd11] cat test-freebsd11.vmx .encoding = "UTF-8" config.version = "8" virtualHW.version = "13" nvram = "test-freebsd11.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" floppy0.present = "FALSE" numvcpus = "2" memSize = "2048" sched.cpu.units = "mhz" sched.cpu.affinity = "all" tools.upgrade.policy = "manual" scsi0.virtualDev = "lsilogic" scsi0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "test-freebsd11.vmdk" sched.scsi0:0.shares = "normal" sched.scsi0:0.throughputCap = "off" scsi0:0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.networkName = "Production A" ethernet0.addressType = "vpx" ethernet0.generatedAddress = "00:50:56:bc:a5:be" ethernet0.present = "TRUE" ide0:0.deviceType = "atapi-cdrom" ide0:0.clientDevice = "TRUE" ide0:0.fileName = "emptyBackingString" ide0:0.present = "TRUE" displayName = "test-freebsd11" guestOS = "freebsd-64" toolScripts.afterPowerOn = "TRUE" toolScripts.afterResume = "TRUE" toolScripts.beforeSuspend = "TRUE" toolScripts.beforePowerOff = "TRUE" uuid.bios = "42 3c ab 70 1b b3 53 b9-1f a4 f2 b4 2f a8 f2 e6" vc.uuid = "50 3c 76 0f 06 b5 37 cc-50 f7 35 c4 c6 34 29 fe" migrate.hostLog = "test-freebsd11-1927f738.hlog" sched.cpu.min = "0" sched.cpu.shares = "normal" sched.mem.min = "0" sched.mem.minSize = "0" sched.mem.shares = "normal" numa.autosize.vcpu.maxPerVirtualNode = "2" numa.autosize.cookie = "20001" sched.swap.derivedName = "/vmfs/volumes/552c8e27-b1f51fec-9bf8-90e2ba090e50/test-freebsd11/test-freebsd11-9923576a.vswp" uuid.location = "56 4d 9b 92 f9 2e 4a 68-f6 6a b2 22 17 43 d5 7e" scsi0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "16" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" vmci0.id = "799601382" monitor.phys_bits_used = "43" vmotion.checkpointFBSize = "4194304" vmotion.checkpointSVGAPrimarySize = "4194304" cleanShutdown = "TRUE" softPowerOff = "FALSE" checkpoint.vmState = "" Does the ESXi host install any another OS successfully? Perhaps your having a hardware issues of some sort. Hope this helps, -Matthew From owner-freebsd-current@freebsd.org Fri Apr 6 20:44:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97447F84F42 for ; Fri, 6 Apr 2018 20:44:28 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 190D7758DE for ; Fri, 6 Apr 2018 20:44:28 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CC79DF84F41; Fri, 6 Apr 2018 20:44:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A87A6F84F40 for ; Fri, 6 Apr 2018 20:44:27 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9DC758DD for ; Fri, 6 Apr 2018 20:44:26 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from localhost (vpn.classit.ro [31.14.161.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id C3A3246840D; Fri, 6 Apr 2018 23:44:19 +0300 (EEST) Date: Fri, 6 Apr 2018 23:44:17 +0300 From: Ion-Mihai Tetcu To: "Rodney W. Grimes" Cc: current@FreeBSD.org, Matthew Grooms Subject: Re: failing to install 11.1R on VMWare Message-ID: <20180406234417.0000744d@FreeBSD.org> In-Reply-To: <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> References: <20180406204010.00006e84@FreeBSD.org> <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 180406-6, 2018-04-06), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 20:44:28 -0000 On Fri, 6 Apr 2018 11:30:26 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > > "Rodney W. Grimes" wrote: > > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > > /boot/kernel/kernel text=014972f8 > > > > > > elf64_loadimage: read failed > > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > > ... > > > > > > (for 10.4R similar just with a different address). [ .. ] > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not > > anything else) and got the same result trying to boot the 10.4R > > boot-only ISO). Would it make any diff if I create the VM from > > scratch on that host? > > Um, moving .vmx files around between versions of vsphere has to be > done with a good deal of care, and given your having "issues" to > start with I would not add that complexity to this problem. > > Create an new empty vm on 6.5.0, and use HW level 8, that is portable > accross 5.5 to 6.5. > > Also try sticking with ONLY IDE disks and cdrom, that might > be causing an issue. OK I created a new machine, almost with defaults (changed the disk to IDE and independent-nonpersistent, put the CDROM on the same controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM version 8) and the installer booted OK, got to the welcome screen. I'll play more tomorrow since it's almost midnight and I have to be up in 4h. Many thanks for the help. Here's the vmx of it: >>> .encoding = "UTF-8" config.version = "8" virtualHW.version = "8" nvram = "FREEBSD-test2.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" memSize = "1024" sched.cpu.units = "mhz" sched.cpu.affinity = "all" sched.cpu.latencySensitivity = "normal" sched.mem.affinity = "all" powerType.powerOff = "default" powerType.suspend = "default" powerType.reset = "default" scsi0.virtualDev = "lsilogic" scsi0.present = "TRUE" ide0:0.fileName = "FREEBSD-test2.vmdk" ide0:0.mode = "independent-nonpersistent" sched.ide0:0.shares = "normal" sched.ide0:0.throughputCap = "off" ide0:0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.networkName = "VM Network" ethernet0.addressType = "vpx" ethernet0.generatedAddress = "00:50:56:8d:99:50" ethernet0.present = "TRUE" ide0:1.deviceType = "cdrom-image" ide0:1.fileName = "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-11.1-RELEASE-amd64-bootonly.iso" ide0:1.present = "TRUE" floppy0.startConnected = "FALSE" floppy0.clientDevice = "TRUE" floppy0.fileName = "vmware-null-remote-floppy" displayName = "FREEBSD-test2" guestOS = "freebsd-64" toolScripts.afterPowerOn = "TRUE" toolScripts.afterResume = "TRUE" toolScripts.beforeSuspend = "TRUE" toolScripts.beforePowerOff = "TRUE" uuid.bios = "42 0d 6c 09 83 cf 81 5d-12 6d a8 de 4d 1a 3a d6" vc.uuid = "50 0d 05 1e 9d 59 64 6a-c5 a8 b4 1b b4 f6 55 9a" migrate.hostLog = "FREEBSD-test2-490e49c9.hlog" sched.cpu.min = "0" sched.cpu.shares = "normal" sched.mem.min = "0" sched.mem.minSize = "0" sched.mem.shares = "normal" numa.autosize.vcpu.maxPerVirtualNode = "1" numa.autosize.cookie = "10001" sched.swap.derivedName = "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD-test2/FREEBSD-test2-6b4fc32b.vswp" uuid.location = "56 4d af 84 7d ea 6b 51-e6 40 16 dd 81 07 1c 64" ide0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "16" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" vmci0.id = "1293564630" hostCPUID.0 = "0000000d756e65476c65746e49656e69" hostCPUID.1 = "000306e40020080077bee3ffbfebfbff" hostCPUID.80000001 = "0000000000000000000000012c100800" guestCPUID.0 = "0000000d756e65476c65746e49656e69" guestCPUID.1 = "000306e400010800969822030fabfbff" guestCPUID.80000001 = "00000000000000000000000128100800" userCPUID.0 = "0000000d756e65476c65746e49656e69" userCPUID.1 = "000306e400010800969822030fabfbff" userCPUID.80000001 = "00000000000000000000000128100800" evcCompatibilityMode = "FALSE" monitor.phys_bits_used = "40" vmotion.checkpointFBSize = "4194304" cleanShutdown = "TRUE" softPowerOff = "FALSE" >>> And here's the one that fails to boot: >>> .encoding = "UTF-8" config.version = "8" virtualHW.version = "11" nvram = "FREEBSD TESTE.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" numvcpus = "2" memSize = "4" sched.cpu.units = "mhz" sched.cpu.affinity = "all" sched.mem.affinity = "all" powerType.powerOff = "soft" powerType.suspend = "hard" powerType.reset = "soft" scsi0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "FREEBSD TESTE.vmdk" sched.scsi0:0.shares = "normal" sched.scsi0:0.throughputCap = "off" scsi0:0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.networkName = "VM Network" ethernet0.addressType = "vpx" ethernet0.generatedAddress = "00:50:56:8d:16:12" ethernet0.present = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-10.4-RELEASE-amd64-bootonly.iso" ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" floppy0.clientDevice = "TRUE" floppy0.fileName = "vmware-null-remote-floppy" displayName = "FREEBSD TESTE" guestOS = "freebsd-64" toolScripts.afterPowerOn = "TRUE" toolScripts.afterResume = "TRUE" toolScripts.beforeSuspend = "TRUE" toolScripts.beforePowerOff = "TRUE" uuid.bios = "42 0d 30 04 8a 71 92 9b-43 6e b2 94 90 6a ac 3a" vc.uuid = "50 0d de ad cb e0 9b 3c-f1 1c d5 56 2e 98 d9 a5" sched.cpu.min = "0" sched.cpu.shares = "normal" sched.mem.min = "0" sched.mem.minSize = "0" sched.mem.shares = "normal" virtualHW.productCompatibility = "hosted" sched.swap.derivedName = "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD TESTE/FREEBSD TESTE-b65a4b76.vswp" replay.supported = "FALSE" replay.filename = "" migrate.hostlog = "./FREEBSD TESTE-b65a4b76.hlog" scsi0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "16" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" vmci0.id = "-1872057286" monitor.phys_bits_used = "42" vmotion.checkpointFBSize = "4194304" vmotion.checkpointSVGAPrimarySize = "4194304" cleanShutdown = "TRUE" softPowerOff = "FALSE" tools.remindInstall = "FALSE" scsi0.virtualDev = "lsilogic" scsi0.sasWWID = "50 05 05 64 8a 71 92 90" sata0.pciSlotNumber = "34" sata0.present = "TRUE" config.readOnly = "FALSE" numa.autosize.vcpu.maxPerVirtualNode = "2" numa.autosize.cookie = "20001" >>> --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-current@freebsd.org Fri Apr 6 22:39:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 578B5F8CB4E for ; Fri, 6 Apr 2018 22:39:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E1C5679DF2 for ; Fri, 6 Apr 2018 22:39:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id A0E1BF8CB49; Fri, 6 Apr 2018 22:39:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79AEBF8CB48 for ; Fri, 6 Apr 2018 22:39:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD55B79DF0 for ; Fri, 6 Apr 2018 22:39:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w36Mdib9005293; Fri, 6 Apr 2018 15:39:44 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w36Mdgej005292; Fri, 6 Apr 2018 15:39:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804062239.w36Mdgej005292@pdx.rh.CN85.dnsmgr.net> Subject: Re: failing to install 11.1R on VMWare In-Reply-To: <20180406235116.00001186@tetcu.info> To: Ion-Mihai Tetcu Date: Fri, 6 Apr 2018 15:39:42 -0700 (PDT) CC: current@FreeBSD.org, Matthew Grooms X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 22:39:50 -0000 > Lol, looking over the one that fails ... RAM is set at 4MB. Which I > think it might be the default on that cluster for some reason. > I'll test now with a sane amount of RAM. Apologies for the noise. > > On Fri, 6 Apr 2018 23:44:17 +0300 > Ion-Mihai Tetcu wrote: > > > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT) > > "Rodney W. Grimes" wrote: > > > > > > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > > > > /boot/kernel/kernel text=014972f8 > > > > > > > > elf64_loadimage: read failed > > > > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > > > > ... > > > > > > > > (for 10.4R similar just with a different address). > > > > [ .. ] > > > > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not > > > > anything else) and got the same result trying to boot the 10.4R > > > > boot-only ISO). Would it make any diff if I create the VM from > > > > scratch on that host? > > > > > > Um, moving .vmx files around between versions of vsphere has to be > > > done with a good deal of care, and given your having "issues" to > > > start with I would not add that complexity to this problem. > > > > > > Create an new empty vm on 6.5.0, and use HW level 8, that is > > > portable accross 5.5 to 6.5. > > > > > > Also try sticking with ONLY IDE disks and cdrom, that might > > > be causing an issue. > > > > OK I created a new machine, almost with defaults (changed the disk to > > IDE and independent-nonpersistent, put the CDROM on the same > > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM > > version 8) and the installer booted OK, got to the welcome screen. > > I'll play more tomorrow since it's almost midnight and I have to be up > > in 4h. Many thanks for the help. > > > > > > Here's the vmx of it: > > >>> > > .encoding = "UTF-8" > > config.version = "8" > > virtualHW.version = "8" > > nvram = "FREEBSD-test2.nvram" > > pciBridge0.present = "TRUE" > > svga.present = "TRUE" > > pciBridge4.present = "TRUE" > > pciBridge4.virtualDev = "pcieRootPort" > > pciBridge4.functions = "8" > > pciBridge5.present = "TRUE" > > pciBridge5.virtualDev = "pcieRootPort" > > pciBridge5.functions = "8" > > pciBridge6.present = "TRUE" > > pciBridge6.virtualDev = "pcieRootPort" > > pciBridge6.functions = "8" > > pciBridge7.present = "TRUE" > > pciBridge7.virtualDev = "pcieRootPort" > > pciBridge7.functions = "8" > > vmci0.present = "TRUE" > > hpet0.present = "TRUE" > > memSize = "1024" that would be 1024MB, so 1G > > sched.cpu.units = "mhz" > > sched.cpu.affinity = "all" > > sched.cpu.latencySensitivity = "normal" > > sched.mem.affinity = "all" > > powerType.powerOff = "default" > > powerType.suspend = "default" > > powerType.reset = "default" > > scsi0.virtualDev = "lsilogic" > > scsi0.present = "TRUE" > > ide0:0.fileName = "FREEBSD-test2.vmdk" > > ide0:0.mode = "independent-nonpersistent" > > sched.ide0:0.shares = "normal" > > sched.ide0:0.throughputCap = "off" > > ide0:0.present = "TRUE" > > ethernet0.virtualDev = "e1000" > > ethernet0.networkName = "VM Network" > > ethernet0.addressType = "vpx" > > ethernet0.generatedAddress = "00:50:56:8d:99:50" > > ethernet0.present = "TRUE" > > ide0:1.deviceType = "cdrom-image" > > ide0:1.fileName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-11.1-RELEASE-amd64-bootonly.iso" > > ide0:1.present = "TRUE" floppy0.startConnected = "FALSE" > > floppy0.clientDevice = "TRUE" > > floppy0.fileName = "vmware-null-remote-floppy" > > displayName = "FREEBSD-test2" > > guestOS = "freebsd-64" > > toolScripts.afterPowerOn = "TRUE" > > toolScripts.afterResume = "TRUE" > > toolScripts.beforeSuspend = "TRUE" > > toolScripts.beforePowerOff = "TRUE" > > uuid.bios = "42 0d 6c 09 83 cf 81 5d-12 6d a8 de 4d 1a 3a d6" > > vc.uuid = "50 0d 05 1e 9d 59 64 6a-c5 a8 b4 1b b4 f6 55 9a" > > migrate.hostLog = "FREEBSD-test2-490e49c9.hlog" > > sched.cpu.min = "0" > > sched.cpu.shares = "normal" > > sched.mem.min = "0" > > sched.mem.minSize = "0" > > sched.mem.shares = "normal" > > numa.autosize.vcpu.maxPerVirtualNode = "1" > > numa.autosize.cookie = "10001" > > sched.swap.derivedName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD-test2/FREEBSD-test2-6b4fc32b.vswp" > > uuid.location = "56 4d af 84 7d ea 6b 51-e6 40 16 dd 81 07 1c 64" > > ide0:0.redo = "" pciBridge0.pciSlotNumber = "17" > > pciBridge4.pciSlotNumber = "21" > > pciBridge5.pciSlotNumber = "22" > > pciBridge6.pciSlotNumber = "23" > > pciBridge7.pciSlotNumber = "24" > > scsi0.pciSlotNumber = "16" > > ethernet0.pciSlotNumber = "32" > > vmci0.pciSlotNumber = "33" > > vmci0.id = "1293564630" > > hostCPUID.0 = "0000000d756e65476c65746e49656e69" > > hostCPUID.1 = "000306e40020080077bee3ffbfebfbff" > > hostCPUID.80000001 = "0000000000000000000000012c100800" > > guestCPUID.0 = "0000000d756e65476c65746e49656e69" > > guestCPUID.1 = "000306e400010800969822030fabfbff" > > guestCPUID.80000001 = "00000000000000000000000128100800" > > userCPUID.0 = "0000000d756e65476c65746e49656e69" > > userCPUID.1 = "000306e400010800969822030fabfbff" > > userCPUID.80000001 = "00000000000000000000000128100800" > > evcCompatibilityMode = "FALSE" > > monitor.phys_bits_used = "40" > > vmotion.checkpointFBSize = "4194304" > > cleanShutdown = "TRUE" > > softPowerOff = "FALSE" > > > > >>> > > > > And here's the one that fails to boot: > > >>> > > .encoding = "UTF-8" > > config.version = "8" > > virtualHW.version = "11" > > nvram = "FREEBSD TESTE.nvram" > > pciBridge0.present = "TRUE" > > svga.present = "TRUE" > > pciBridge4.present = "TRUE" > > pciBridge4.virtualDev = "pcieRootPort" > > pciBridge4.functions = "8" > > pciBridge5.present = "TRUE" > > pciBridge5.virtualDev = "pcieRootPort" > > pciBridge5.functions = "8" > > pciBridge6.present = "TRUE" > > pciBridge6.virtualDev = "pcieRootPort" > > pciBridge6.functions = "8" > > pciBridge7.present = "TRUE" > > pciBridge7.virtualDev = "pcieRootPort" > > pciBridge7.functions = "8" > > vmci0.present = "TRUE" > > hpet0.present = "TRUE" > > numvcpus = "2" > > memSize = "4" Um, that would be 4MB of ram, yep, amazing it got as far as it did.... > > sched.cpu.units = "mhz" > > sched.cpu.affinity = "all" > > sched.mem.affinity = "all" > > powerType.powerOff = "soft" > > powerType.suspend = "hard" > > powerType.reset = "soft" > > scsi0.present = "TRUE" > > scsi0:0.deviceType = "scsi-hardDisk" > > scsi0:0.fileName = "FREEBSD TESTE.vmdk" > > sched.scsi0:0.shares = "normal" > > sched.scsi0:0.throughputCap = "off" > > scsi0:0.present = "TRUE" > > ethernet0.virtualDev = "e1000" > > ethernet0.networkName = "VM Network" > > ethernet0.addressType = "vpx" > > ethernet0.generatedAddress = "00:50:56:8d:16:12" > > ethernet0.present = "TRUE" > > ide1:0.deviceType = "cdrom-image" > > ide1:0.fileName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-10.4-RELEASE-amd64-bootonly.iso" > > ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" > > floppy0.clientDevice = "TRUE" > > floppy0.fileName = "vmware-null-remote-floppy" > > displayName = "FREEBSD TESTE" > > guestOS = "freebsd-64" > > toolScripts.afterPowerOn = "TRUE" > > toolScripts.afterResume = "TRUE" > > toolScripts.beforeSuspend = "TRUE" > > toolScripts.beforePowerOff = "TRUE" > > uuid.bios = "42 0d 30 04 8a 71 92 9b-43 6e b2 94 90 6a ac 3a" > > vc.uuid = "50 0d de ad cb e0 9b 3c-f1 1c d5 56 2e 98 d9 a5" > > sched.cpu.min = "0" > > sched.cpu.shares = "normal" > > sched.mem.min = "0" > > sched.mem.minSize = "0" > > sched.mem.shares = "normal" > > virtualHW.productCompatibility = "hosted" > > sched.swap.derivedName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD > > TESTE/FREEBSD TESTE-b65a4b76.vswp" replay.supported = "FALSE" > > replay.filename = "" migrate.hostlog = "./FREEBSD TESTE-b65a4b76.hlog" > > scsi0:0.redo = "" > > pciBridge0.pciSlotNumber = "17" > > pciBridge4.pciSlotNumber = "21" > > pciBridge5.pciSlotNumber = "22" > > pciBridge6.pciSlotNumber = "23" > > pciBridge7.pciSlotNumber = "24" > > scsi0.pciSlotNumber = "16" > > ethernet0.pciSlotNumber = "32" > > vmci0.pciSlotNumber = "33" > > vmci0.id = "-1872057286" > > monitor.phys_bits_used = "42" > > vmotion.checkpointFBSize = "4194304" > > vmotion.checkpointSVGAPrimarySize = "4194304" > > cleanShutdown = "TRUE" > > softPowerOff = "FALSE" > > tools.remindInstall = "FALSE" > > scsi0.virtualDev = "lsilogic" > > scsi0.sasWWID = "50 05 05 64 8a 71 92 90" > > sata0.pciSlotNumber = "34" > > sata0.present = "TRUE" > > config.readOnly = "FALSE" > > numa.autosize.vcpu.maxPerVirtualNode = "2" > > numa.autosize.cookie = "20001" > > >>> > > > > > > > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sat Apr 7 04:21:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F004F824B2 for ; Sat, 7 Apr 2018 04:21:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 03D9C7EFD5 for ; Sat, 7 Apr 2018 04:21:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-20-68.dyn.iinet.net.au [115.166.20.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w374LrEg071947 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 6 Apr 2018 21:21:56 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: zfsloader: messy output on Dell iDrac serial console Message-ID: <76d1549c-c721-ffcb-c27e-48e4d06c9c63@freebsd.org> Date: Sat, 7 Apr 2018 12:21:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 04:21:58 -0000 running on *some* Dell servers the serial console looks messed up at the time of the FreeBSD menu. it looks like it's dropping (or adding? but that's less likely) characters.  |  5. [K]ernel: kernel (1 of 2)           |  .- .                    -.  |  6. Configure Boot [O]ptions...         |2  --| y/       -.       -/`   -o/  |137. Select Boot [E]nvironment...        | `:`                  `:`         ::/sy++:.  |                                         H|     .-- `--.     --  /6H`:                          :`  |                                         | .---.....----. IS there an RTS/CTS input we should be attending to? I will add that some of the other modules (e.g. the mfi raid setup section) also get affected, so it's not just a bug in our code. From owner-freebsd-current@freebsd.org Sat Apr 7 04:01:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC2BDF80F02 for ; Sat, 7 Apr 2018 04:01:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6057776431 for ; Sat, 7 Apr 2018 04:01:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-20-68.dyn.iinet.net.au [115.166.20.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w3741SHT071904 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 6 Apr 2018 21:01:31 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: deadlock detected in -current (new).. NFS? Anyone with 'amd' knowledge? Message-ID: Date: Sat, 7 Apr 2018 12:01:23 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 04:01:41 -0000 Anyone seen these recently? I just got the following: panic: deadlkres: possible deadlock detected for (address)  blocked for (big number) ticks anyone seen similar on very new (yesterday) -current GENERIC. ? there was a prior message that may or may not be related: newnfs: server pid741@gamma  error: fileid changed. fsid 0:0: expected fileid 0x1, got 0x2 (BROKEN NFS SERVER OR MIDDLEWARE) (amd screwed up). I suspect that amd is broken on -current using known good config files results in a hung nfs mount and even after killing amd, any attempt to touch the mountpoint results in a hung (but interruptable) proccess. For example as /net  was an amd mountpoint,   ls -l /    results in a hung copy of ls. (but you can get it back with ^C) I suspect the two are related. Julian From owner-freebsd-current@freebsd.org Sat Apr 7 06:35:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E53B7F8DDF5 for ; Sat, 7 Apr 2018 06:35:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2996F6DF3B; Sat, 7 Apr 2018 06:35:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1f4hRV-000658-LJ; Sat, 07 Apr 2018 09:35:17 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: zfsloader: messy output on Dell iDrac serial console From: Daniel Braniss In-Reply-To: <76d1549c-c721-ffcb-c27e-48e4d06c9c63@freebsd.org> Date: Sat, 7 Apr 2018 09:35:17 +0300 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <617BAAEE-B78F-424F-ABF0-28F2E30BAEAF@cs.huji.ac.il> References: <76d1549c-c721-ffcb-c27e-48e4d06c9c63@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 06:35:24 -0000 > On 7 Apr 2018, at 7:21, Julian Elischer wrote: >=20 > running on *some* Dell servers the serial console looks messed up at = the time of the FreeBSD menu. > it looks like it's dropping (or adding? but that's less likely) = characters. >=20 > | 5. [K]ernel: kernel (1 of 2) | .- . = -. > | 6. Configure Boot [O]ptions... |2 --| y/ -. = -/` -o/ > |137. Select Boot [E]nvironment... | `:` `:` = ::/sy++:. > | H| .-- `--. -- = /6H`: :` > | | .---.....----. >=20 > IS there an RTS/CTS input we should be attending to? >=20 > I will add that some of the other modules (e.g. the mfi raid setup = section) also get affected, > so it's not just a bug in our code. I=E2=80=99m using Serial-Over-LAN via ipmi/drac and am noticing this too = on a Dell C6220, don=E2=80=99t know when this started though, It=E2=80=99s only recently = that I=E2=80=99m working on this kind of hosts. It drives the xterm/rxvt crazy, but it=E2=80=99s = only the output from the boot/loader, once the kernel takes over, all is back to normal. the = serial speed is set to 115200, but changing it as far as i remember did not help. will = try lowering soon. I had to disable the menu to get some sense of the output, and usually = have to hit ^B to remove most of the garbage. From owner-freebsd-current@freebsd.org Sat Apr 7 11:31:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96F4AF80BFE for ; Sat, 7 Apr 2018 11:31:15 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 30F4D7E2C6 for ; Sat, 7 Apr 2018 11:31:15 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E4E2BF80BF9; Sat, 7 Apr 2018 11:31:14 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA855F80BF8 for ; Sat, 7 Apr 2018 11:31:14 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1C37E299 for ; Sat, 7 Apr 2018 11:31:13 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from localhost (unknown [78.97.72.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id CFA9A46708E for ; Sat, 7 Apr 2018 14:31:11 +0300 (EEST) Date: Sat, 7 Apr 2018 14:31:11 +0300 From: Ion-Mihai Tetcu Cc: current@FreeBSD.org Subject: Re: failing to install 11.1R on VMWare Message-ID: <20180407143111.00005020@FreeBSD.org> In-Reply-To: <20180406234417.0000744d@FreeBSD.org> References: <20180406204010.00006e84@FreeBSD.org> <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> <20180406234417.0000744d@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 180406-6, 2018-04-06), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 11:31:15 -0000 [ combining 2 mails sent yesterday that didn't made it to the list ] Lol, looking over the one that fails ... RAM is set at 4MB. Which I think it might be the default on that cluster for some reason. I'll test now with a sane amount of RAM. Apologies for the noise. Yep, with 1GB it's OK. Can't wait for the next week to kill the guy who configured that VM before handling it over to me. Sorry again for waisting your time. On Fri, 6 Apr 2018 23:44:17 +0300 Ion-Mihai Tetcu wrote: > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT) > "Rodney W. Grimes" wrote: > > > > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > > > "Rodney W. Grimes" wrote: > > > > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > > > /boot/kernel/kernel text=014972f8 > > > > > > > elf64_loadimage: read failed > > > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > > > ... > > > > > > > (for 10.4R similar just with a different address). > > [ .. ] > > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not > > > anything else) and got the same result trying to boot the 10.4R > > > boot-only ISO). Would it make any diff if I create the VM from > > > scratch on that host? > > > > Um, moving .vmx files around between versions of vsphere has to be > > done with a good deal of care, and given your having "issues" to > > start with I would not add that complexity to this problem. > > > > Create an new empty vm on 6.5.0, and use HW level 8, that is > > portable accross 5.5 to 6.5. > > > > Also try sticking with ONLY IDE disks and cdrom, that might > > be causing an issue. > > OK I created a new machine, almost with defaults (changed the disk to > IDE and independent-nonpersistent, put the CDROM on the same > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM > version 8) and the installer booted OK, got to the welcome screen. > I'll play more tomorrow since it's almost midnight and I have to be up > in 4h. Many thanks for the help. > > > Here's the vmx of it: > >>> > .encoding = "UTF-8" > config.version = "8" > virtualHW.version = "8" > nvram = "FREEBSD-test2.nvram" > pciBridge0.present = "TRUE" > svga.present = "TRUE" > pciBridge4.present = "TRUE" > pciBridge4.virtualDev = "pcieRootPort" > pciBridge4.functions = "8" > pciBridge5.present = "TRUE" > pciBridge5.virtualDev = "pcieRootPort" > pciBridge5.functions = "8" > pciBridge6.present = "TRUE" > pciBridge6.virtualDev = "pcieRootPort" > pciBridge6.functions = "8" > pciBridge7.present = "TRUE" > pciBridge7.virtualDev = "pcieRootPort" > pciBridge7.functions = "8" > vmci0.present = "TRUE" > hpet0.present = "TRUE" > memSize = "1024" > sched.cpu.units = "mhz" > sched.cpu.affinity = "all" > sched.cpu.latencySensitivity = "normal" > sched.mem.affinity = "all" > powerType.powerOff = "default" > powerType.suspend = "default" > powerType.reset = "default" > scsi0.virtualDev = "lsilogic" > scsi0.present = "TRUE" > ide0:0.fileName = "FREEBSD-test2.vmdk" > ide0:0.mode = "independent-nonpersistent" > sched.ide0:0.shares = "normal" > sched.ide0:0.throughputCap = "off" > ide0:0.present = "TRUE" > ethernet0.virtualDev = "e1000" > ethernet0.networkName = "VM Network" > ethernet0.addressType = "vpx" > ethernet0.generatedAddress = "00:50:56:8d:99:50" > ethernet0.present = "TRUE" > ide0:1.deviceType = "cdrom-image" > ide0:1.fileName = > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-11.1-RELEASE-amd64-bootonly.iso" > ide0:1.present = "TRUE" floppy0.startConnected = "FALSE" > floppy0.clientDevice = "TRUE" > floppy0.fileName = "vmware-null-remote-floppy" > displayName = "FREEBSD-test2" > guestOS = "freebsd-64" > toolScripts.afterPowerOn = "TRUE" > toolScripts.afterResume = "TRUE" > toolScripts.beforeSuspend = "TRUE" > toolScripts.beforePowerOff = "TRUE" > uuid.bios = "42 0d 6c 09 83 cf 81 5d-12 6d a8 de 4d 1a 3a d6" > vc.uuid = "50 0d 05 1e 9d 59 64 6a-c5 a8 b4 1b b4 f6 55 9a" > migrate.hostLog = "FREEBSD-test2-490e49c9.hlog" > sched.cpu.min = "0" > sched.cpu.shares = "normal" > sched.mem.min = "0" > sched.mem.minSize = "0" > sched.mem.shares = "normal" > numa.autosize.vcpu.maxPerVirtualNode = "1" > numa.autosize.cookie = "10001" > sched.swap.derivedName = > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD-test2/FREEBSD-test2-6b4fc32b.vswp" > uuid.location = "56 4d af 84 7d ea 6b 51-e6 40 16 dd 81 07 1c 64" > ide0:0.redo = "" pciBridge0.pciSlotNumber = "17" > pciBridge4.pciSlotNumber = "21" > pciBridge5.pciSlotNumber = "22" > pciBridge6.pciSlotNumber = "23" > pciBridge7.pciSlotNumber = "24" > scsi0.pciSlotNumber = "16" > ethernet0.pciSlotNumber = "32" > vmci0.pciSlotNumber = "33" > vmci0.id = "1293564630" > hostCPUID.0 = "0000000d756e65476c65746e49656e69" > hostCPUID.1 = "000306e40020080077bee3ffbfebfbff" > hostCPUID.80000001 = "0000000000000000000000012c100800" > guestCPUID.0 = "0000000d756e65476c65746e49656e69" > guestCPUID.1 = "000306e400010800969822030fabfbff" > guestCPUID.80000001 = "00000000000000000000000128100800" > userCPUID.0 = "0000000d756e65476c65746e49656e69" > userCPUID.1 = "000306e400010800969822030fabfbff" > userCPUID.80000001 = "00000000000000000000000128100800" > evcCompatibilityMode = "FALSE" > monitor.phys_bits_used = "40" > vmotion.checkpointFBSize = "4194304" > cleanShutdown = "TRUE" > softPowerOff = "FALSE" > > >>> > > And here's the one that fails to boot: > >>> > .encoding = "UTF-8" > config.version = "8" > virtualHW.version = "11" > nvram = "FREEBSD TESTE.nvram" > pciBridge0.present = "TRUE" > svga.present = "TRUE" > pciBridge4.present = "TRUE" > pciBridge4.virtualDev = "pcieRootPort" > pciBridge4.functions = "8" > pciBridge5.present = "TRUE" > pciBridge5.virtualDev = "pcieRootPort" > pciBridge5.functions = "8" > pciBridge6.present = "TRUE" > pciBridge6.virtualDev = "pcieRootPort" > pciBridge6.functions = "8" > pciBridge7.present = "TRUE" > pciBridge7.virtualDev = "pcieRootPort" > pciBridge7.functions = "8" > vmci0.present = "TRUE" > hpet0.present = "TRUE" > numvcpus = "2" > memSize = "4" > sched.cpu.units = "mhz" > sched.cpu.affinity = "all" > sched.mem.affinity = "all" > powerType.powerOff = "soft" > powerType.suspend = "hard" > powerType.reset = "soft" > scsi0.present = "TRUE" > scsi0:0.deviceType = "scsi-hardDisk" > scsi0:0.fileName = "FREEBSD TESTE.vmdk" > sched.scsi0:0.shares = "normal" > sched.scsi0:0.throughputCap = "off" > scsi0:0.present = "TRUE" > ethernet0.virtualDev = "e1000" > ethernet0.networkName = "VM Network" > ethernet0.addressType = "vpx" > ethernet0.generatedAddress = "00:50:56:8d:16:12" > ethernet0.present = "TRUE" > ide1:0.deviceType = "cdrom-image" > ide1:0.fileName = > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-10.4-RELEASE-amd64-bootonly.iso" > ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" > floppy0.clientDevice = "TRUE" > floppy0.fileName = "vmware-null-remote-floppy" > displayName = "FREEBSD TESTE" > guestOS = "freebsd-64" > toolScripts.afterPowerOn = "TRUE" > toolScripts.afterResume = "TRUE" > toolScripts.beforeSuspend = "TRUE" > toolScripts.beforePowerOff = "TRUE" > uuid.bios = "42 0d 30 04 8a 71 92 9b-43 6e b2 94 90 6a ac 3a" > vc.uuid = "50 0d de ad cb e0 9b 3c-f1 1c d5 56 2e 98 d9 a5" > sched.cpu.min = "0" > sched.cpu.shares = "normal" > sched.mem.min = "0" > sched.mem.minSize = "0" > sched.mem.shares = "normal" > virtualHW.productCompatibility = "hosted" > sched.swap.derivedName = > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD > TESTE/FREEBSD TESTE-b65a4b76.vswp" replay.supported = "FALSE" > replay.filename = "" migrate.hostlog = "./FREEBSD TESTE-b65a4b76.hlog" > scsi0:0.redo = "" > pciBridge0.pciSlotNumber = "17" > pciBridge4.pciSlotNumber = "21" > pciBridge5.pciSlotNumber = "22" > pciBridge6.pciSlotNumber = "23" > pciBridge7.pciSlotNumber = "24" > scsi0.pciSlotNumber = "16" > ethernet0.pciSlotNumber = "32" > vmci0.pciSlotNumber = "33" > vmci0.id = "-1872057286" > monitor.phys_bits_used = "42" > vmotion.checkpointFBSize = "4194304" > vmotion.checkpointSVGAPrimarySize = "4194304" > cleanShutdown = "TRUE" > softPowerOff = "FALSE" > tools.remindInstall = "FALSE" > scsi0.virtualDev = "lsilogic" > scsi0.sasWWID = "50 05 05 64 8a 71 92 90" > sata0.pciSlotNumber = "34" > sata0.present = "TRUE" > config.readOnly = "FALSE" > numa.autosize.vcpu.maxPerVirtualNode = "2" > numa.autosize.cookie = "20001" > >>> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-current@freebsd.org Sat Apr 7 16:14:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70164F93F80 for ; Sat, 7 Apr 2018 16:14:10 +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 E07FF7AA23; Sat, 7 Apr 2018 16:14:09 +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 w37GE8Fl088577 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Apr 2018 09:14:09 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w37GE8Gr088576; Sat, 7 Apr 2018 09:14:08 -0700 (PDT) (envelope-from fbsd) Date: Sat, 7 Apr 2018 09:14:08 -0700 From: bob prohaska To: Julian Elischer Cc: freebsd-current , bob prohaska Subject: Re: zfsloader: messy output on Dell iDrac serial console Message-ID: <20180407161408.GA88547@www.zefox.net> References: <76d1549c-c721-ffcb-c27e-48e4d06c9c63@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76d1549c-c721-ffcb-c27e-48e4d06c9c63@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 16:14:10 -0000 On Sat, Apr 07, 2018 at 12:21:47PM +0800, Julian Elischer wrote: > running on *some* Dell servers the serial console looks messed up at > the time of the FreeBSD menu. > it looks like it's dropping (or adding? but that's less likely) > characters. > > ??|?? 5. [K]ernel: kernel (1 of 2)???????????????????? |?? .- .?????????????????????????????????????? -. > ??|?? 6. Configure Boot [O]ptions...???????????????? |2?? --| y/???????????? -.???????????? Scrambled console output has shown up on a Pi3 under what might be called overload conditions, things like make -j8 buildworld and running of stress2's default test suite. It doesn't seem to be a serial issue in that case. Hard to believe you're seeing something related, but my $.02 anyway. bob prohaska From owner-freebsd-current@freebsd.org Sat Apr 7 19:00:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 214CDF9EF85 for ; Sat, 7 Apr 2018 19:00:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD596F47E; Sat, 7 Apr 2018 19:00:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9372844EB4; Sat, 7 Apr 2018 21:00:07 +0200 (CEST) From: Dimitry Andric Message-Id: <9EF36320-F1E8-4FF7-A917-7D4872EA610F@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F8C12BC2-D23B-4A13-A358-69AAFDA2F3CA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: clang manual page? Date: Sat, 7 Apr 2018 21:00:06 +0200 In-Reply-To: <20180406183942.GB78891@troutmask.apl.washington.edu> Cc: David Chisnall , Pete Wright , Conrad Meyer , freebsd-current , Ed Maste To: sgk@troutmask.apl.washington.edu References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> <20180406183942.GB78891@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:00:15 -0000 --Apple-Mail=_F8C12BC2-D23B-4A13-A358-69AAFDA2F3CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Apr 2018, at 20:39, Steve Kargl = wrote: >=20 > On Fri, Apr 06, 2018 at 01:25:54PM +0200, Dimitry Andric wrote: >> Yes, but that manual is also pretty much incomplete, so with the last >> import I decided to stay with the older perl doc based one. Upstream >> is pretty bad at writing detailed documentation, certainly in the = form >> of man pages. >>=20 >=20 > Index: clang.1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- clang.1 (revision 332114) > +++ clang.1 (working copy) > @@ -128,15 +128,72 @@ > .UNINDENT > .INDENT 0.0 > .TP > -.B \-std=3D > -Specify the language standard to compile for. > +.B \-std=3D > +Specify the language standard to enforce. > + > +A partial list of validate > +.B > +for the C programming language is > +.INDENT 7.0 > +.INDENT 3.5 > +\fIc89\fP ISO/IEC 9899:1990 > +.sp > +\fIc90\fP ISO/IEC 9899:1990 > +.sp > +\fIc99\fP ISO/IEC 9899:1999 > +.sp > +\fIc11\fP ISO/IEC 9899:2011 > +.sp > +\fIc17\fP Working draft for ISO/EIC 9899:2017 > +.sp > +\fIgnu89\fP ISO/IEC 9899:1990 with GNU extensions > +.sp > +\fIgnu90\fP ISO/IEC 9899:1990 with GNU extensions > +.sp > +\fIgnu99\fP ISO/IEC 9899:1999 with GNU extensions > +.sp > +\fIgnu11\fP ISO/IEC 9899:2011 with GNU extensions > +.sp > +\fIgnu17\fP Draft for ISO/EIC 9899:2017 with GNU extensions > .UNINDENT > +.UNINDENT > + > +A partial list of validate > +.B > +for the C++ programming language is > +.INDENT 7.0 > +.INDENT 3.5 > +\fIc++98\fP ISO/IEC 14882:1998 with amendments > +.sp > +\fIc++03\fP ISO/IEC 14882:2003 with amendments > +.sp > +\fIc++11\fP ISO/IEC 14882:2011 with amendments > +.sp > +\fIc++14\fP ISO/IEC 14882:2014 with amendments > +.sp > +\fIc++17\fP ISO/IEC 14882:2017 with amendments > +.sp > +\fIc++2a\fP Draft ISO/IEC 14882:2020 > +.sp > +\fIgnu++98\fP ISO/IEC 14882:1998 with amendments and GNU extensions > +.sp > +\fIgnu++03\fP ISO/IEC 14882:2003 with amendments and GNU extensions > +.sp > +\fIgnu++11\fP ISO/IEC 14882:2011 with amendments and GNU extensions > +.sp > +\fIgnu++14\fP ISO/IEC 14882:2014 with amendments and GNU extensions > +.sp > +\fIgnu++17\fP ISO/IEC 14882:2017 with amendments and GNU extensions > +.sp > +\fIgnu++2a\fP Draft ISO/IEC 14882:2020 with GNU extensions > +.UNINDENT > +.UNINDENT > +.UNINDENT > .INDENT 0.0 > .TP > .B \-stdlib=3D > Specify the C++ standard library to use; supported options are = libstdc++ and > libc++. If not specified, platform default will be used. > -.UNINDENT > .INDENT 0.0 > .TP > .B \-rtlib=3D Thanks for the diff, but the man page is generated from a .rst source, so it will have to be changed there instead. I will submit an analogous patch upstream for the rst file. -Dimitry --Apple-Mail=_F8C12BC2-D23B-4A13-A358-69AAFDA2F3CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWskVNgAKCRCwXqMKLiCW o8uGAJ9vUEc+uLGMfTMiad5zjSXyQW6aSQCfYnUUAV3ZpSzIW0qRZ5eCBNdeEQU= =GxNw -----END PGP SIGNATURE----- --Apple-Mail=_F8C12BC2-D23B-4A13-A358-69AAFDA2F3CA-- From owner-freebsd-current@freebsd.org Sat Apr 7 19:34:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A235FA174A for ; Sat, 7 Apr 2018 19:34:57 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B1F0831BF; Sat, 7 Apr 2018 19:34:57 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id c78-v6so4834948lfh.1; Sat, 07 Apr 2018 12:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GumACvN/9yhJkt0OqH0HCk4Mkwzb4nSBaUXpo2KiPu0=; b=Us5luo95XEn8uwB0PD7Ti4njYznPpzUsjLX5dzm6DOcj3dxISG2Xk1n7/RhiWmZsnT DVayzxAXHqICagHN3c6IKP3W5Qb/zxfHm0HI17pkNv+JqojwzoPPznkaowCMONhw5a9V lmQSh3aLWgwYiQ/pZSow2YM69sOiQp/Gjz8pzI0JhljX5QN+jsjSUCeZeoRmdovra8tp EvOOYQa17xZmWbQqZEc8Jj1ohme7Zg/QFpJAIPFCLYVc/6ALrgVMPfhmtJjtorD2pyFV SstF7+Ms8s0cKMszbzYE+qtnWwjMO/jJjKxf7Ny2iZq63geUiSYqWDZseHek8Ha+bDSB xtog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GumACvN/9yhJkt0OqH0HCk4Mkwzb4nSBaUXpo2KiPu0=; b=mRG1UbutYHafKRblYDA1FvbJwGSOG92Z+8iToJ7x5vDRtrH9dbRytIGaaUz0Jtysr0 xUQ3AirCuGJNq9LV8UjpZMFC38NULihqeonoLD4h22Wc9lLPErSKoV3yiq7a2v64UiFY tYb3Zqk4cCgZInWz8AP110raYx6CSWskrUkHLS0OPzs3pWg7blNWhjg6rHs2Brnz3pez /KK4otfFv9lWqnb/Euda+bnfsERuZNZRAGTEsZXGjJPa1gQSx6l72DzhRTXKgkRsCQWz LNfoiIBGJNNgYoo3E7jzqKkfTo1CuVd5P5gnQ/mljbSnLDpiTllw41glIH6d1L5zFIEn qiWA== X-Gm-Message-State: ALQs6tArpZXBUPDfcKRrIkHBTNzH9iAM1b4p0kXn7Jp9Myp6tYFw2Ae/ kjKD+U3p3rfwx8Wy3hTr/ykKUgVoqvuLgDrh9lE= X-Google-Smtp-Source: AIpwx4+U622zV1HYZJTQFqinEjHgZvrIMW6vU2eXXOX/LeO6tCpWOeprKraQ2GOqgzednIO3YrSEOyaLfA5BUEqQb/g= X-Received: by 10.46.154.70 with SMTP id k6mr19108722ljj.63.1523129695261; Sat, 07 Apr 2018 12:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.85.13 with HTTP; Sat, 7 Apr 2018 12:34:54 -0700 (PDT) In-Reply-To: References: <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> From: Justin Hibbits Date: Sat, 7 Apr 2018 14:34:54 -0500 Message-ID: Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston Cc: Jeff Roberson , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:34:57 -0000 On Fri, Apr 6, 2018 at 10:25 AM, Justin Hibbits wrote: > On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston wrote: >> On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote: >>> My powerpc64 embedded machine is virtually unusable since these vm changes. >>> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help >>> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with >>> many processes in wait channel btalloc. >> >> You don't really have the same symptoms that Don is reporting. > > Okay. I latched onto the thread because it seemed similar. > >> Threads being stuck in btalloc implies a KVA shortage. So: >> - What do you mean by "stuck in vmdaemon"? > > The machine hangs, and my ssh sessions get killed. I can't do > anything at the console except break into kdb. When I do, the running > thread is always vmdaemon. > >> - Which commits specifically cause problems? Does reverting r329882 fix the >> hang? > > I'll try reverting it and report back. Thankfully I can buildkernel > successfully on the machine before it hangs. Can't do more than that, > though. I reverted back to r329881, and successfully built world. Updated to r329882 and it got stuck with processes in btalloc. I've seen other reports of r329882 causing problems on powerpc64 as well, with other bizarre behaviors. - Justin From owner-freebsd-current@freebsd.org Sat Apr 7 19:49:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9C61FA2872 for ; Sat, 7 Apr 2018 19:49:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44BE76B7B0 for ; Sat, 7 Apr 2018 19:49:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id t192-v6so8062494itc.1 for ; Sat, 07 Apr 2018 12:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uygCfVVjIKOE03PFVDPt36gOVvACGxdsoTQnFek9Ues=; b=ahN1SvMB2eDtw0pckyKeJo76MyKKdOXQfP3K2XFWkJJpX8PqVpeQ5mvlWTcb9RJBSh 2i7iUfljXlA6PxgbE22qU7bc5TucBBB1KTvnEgjX6ZPd/+GoGWv/+Sm7vsq3dWcMpV60 588PunaH1PQ9roX5JHV299MZVc/ISTcHrlu7nudj3fCec8k3GmIJayJGR+wLzZZB1sVl PL8iAzzqEyotTmgb59jv6LAbW6Bh6a6yhDP6O4KBk31b6yEXdRinxajuXPQR95A2NCPk lxHvQXs3Qa4j3NHbj/WX50XD0TkKAw91g4Kl/Q+5BjycjGDT5nulfaddAXER9QvTFduW EZwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=uygCfVVjIKOE03PFVDPt36gOVvACGxdsoTQnFek9Ues=; b=kPE2ztIlZjvnAX0Ai0U0BbfzUseDcKJVAkEb3HPnKnS+eCCKU9d+phwGFYlK9wlIHy fVDhWcXsg3+f4QRMvVf4wQpC/gUG/+XqhddofcITtoaAKE6ghKiDGFAGOKj9DY+aKv/V d7KrXo/H7jb9g7mhX1agPlGQYZr8Zo30bkQ1FJJYHO0Fi0xUUZVM/O6L2NWTYEZ8fH6z 6EfHOKR7wPIsTdTEmQ7BRjETBJktmJ0Fiztm0MpzTYmWATfeoP3Ez4RhoByYDAh82XsX 87Z8fiY3Ss9fOlPaBNvNW0UWiQID9KYtJNB6NTII3rszR8tSytUO2OzJ+ggkORRYtOih vtuw== X-Gm-Message-State: AElRT7F/Uwy8rPoLE2lzL0qackRVLtZJHNDtHgMsSLccGSLfmY/q6bo8 QfS6KheZVoB92WhRJtQhrA8= X-Google-Smtp-Source: AIpwx48lYYjk5Y/mpuprWZfSeLIkHT7JCjliFhpuYq1ACn0CF2L889G7aVOA/2amWxjYrTv/0cmsbw== X-Received: by 2002:a24:7904:: with SMTP id z4-v6mr22403061itc.63.1523130580603; Sat, 07 Apr 2018 12:49:40 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id k199-v6sm7500019itb.35.2018.04.07.12.49.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Apr 2018 12:49:39 -0700 (PDT) Sender: Mark Johnston Date: Sat, 7 Apr 2018 15:49:35 -0400 From: Mark Johnston To: Justin Hibbits Cc: Jeff Roberson , FreeBSD current Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT Message-ID: <20180407194935.GA491@raichu> References: <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:49:42 -0000 On Sat, Apr 07, 2018 at 02:34:54PM -0500, Justin Hibbits wrote: > On Fri, Apr 6, 2018 at 10:25 AM, Justin Hibbits wrote: > > On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston wrote: > >> On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote: > >>> My powerpc64 embedded machine is virtually unusable since these vm changes. > >>> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help > >>> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with > >>> many processes in wait channel btalloc. > >> > >> You don't really have the same symptoms that Don is reporting. > > > > Okay. I latched onto the thread because it seemed similar. > > > >> Threads being stuck in btalloc implies a KVA shortage. So: > >> - What do you mean by "stuck in vmdaemon"? > > > > The machine hangs, and my ssh sessions get killed. I can't do > > anything at the console except break into kdb. When I do, the running > > thread is always vmdaemon. > > > >> - Which commits specifically cause problems? Does reverting r329882 fix the > >> hang? > > > > I'll try reverting it and report back. Thankfully I can buildkernel > > successfully on the machine before it hangs. Can't do more than that, > > though. > > I reverted back to r329881, and successfully built world. Updated to > r329882 and it got stuck with processes in btalloc. > > I've seen other reports of r329882 causing problems on powerpc64 as > well, with other bizarre behaviors. Did you try the patch that I had posted? If not, could you? Please also update zfs_arc_free_target or just apply D14994. From owner-freebsd-current@freebsd.org Sat Apr 7 19:56:12 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D273FA2F45 for ; Sat, 7 Apr 2018 19:56:12 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 679816F279; Sat, 7 Apr 2018 19:56:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w37JvJ4N084009 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 7 Apr 2018 19:57:21 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w37Ju1uE032427 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2018 12:56:02 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Date: Sat, 7 Apr 2018 12:55:56 -0700 (PDT) From: Don Lewis Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Justin Hibbits cc: Mark Johnston , Jeff Roberson , FreeBSD current In-Reply-To: Message-ID: References: <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:56:12 -0000 On 7 Apr, Justin Hibbits wrote: > On Fri, Apr 6, 2018 at 10:25 AM, Justin Hibbits wrote: >> On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston wrote: >>> On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote: >>>> My powerpc64 embedded machine is virtually unusable since these vm changes. >>>> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help >>>> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with >>>> many processes in wait channel btalloc. >>> >>> You don't really have the same symptoms that Don is reporting. >> >> Okay. I latched onto the thread because it seemed similar. >> >>> Threads being stuck in btalloc implies a KVA shortage. So: >>> - What do you mean by "stuck in vmdaemon"? >> >> The machine hangs, and my ssh sessions get killed. I can't do >> anything at the console except break into kdb. When I do, the running >> thread is always vmdaemon. >> >>> - Which commits specifically cause problems? Does reverting r329882 fix the >>> hang? >> >> I'll try reverting it and report back. Thankfully I can buildkernel >> successfully on the machine before it hangs. Can't do more than that, >> though. > > I reverted back to r329881, and successfully built world. Updated to > r329882 and it got stuck with processes in btalloc. > > I've seen other reports of r329882 causing problems on powerpc64 as > well, with other bizarre behaviors. I initially missed that this was on powerpc. I believe that arch is a bit odd with characters unsigned by default and arithmentic shifts always being unsigned. Things like that could mess up the algorithm, but I didn't see anything suspicious in the r329882 diff. From owner-freebsd-current@freebsd.org Sat Apr 7 19:59:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FC93F80392 for ; Sat, 7 Apr 2018 19:59:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4631D70F2E; Sat, 7 Apr 2018 19:59:17 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id z143-v6so4870691lff.3; Sat, 07 Apr 2018 12:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MuDggmqLUxPEnr7jczEEY7MJd34Y50wJKZJAALKk/jk=; b=Ou4MRdkLP248I43+OAQ/Y1n4ZO+b4KAKZYNbGceEPtDC2OTOs9HBfyuO/ysoMhNgyn X7k0LXJg7MUseCxngrdBzj+y05rK4qhbzhKwYL8Kdr7hQotgUIsXlLBXFd+Ok4j2f/GE Ef62rXb2MW+/Y+L8lMHLN42ZppqQt4/Y+3Ngs9bgcIFCTDr+pHTTb5ty/u+aJqVt2BOR rr2mlo2lQe1pSvRmbimcyhl4WOTzeJlUmJ/LgO9318DGrXRmmaGmbxojKN6lR6Jj7VYO 5nvvw5hsL/iZo3+FdwpjCm5HA1g+OSruiiBX5x+vUsAYCRjQ3JTRCn6zJQzBpYJphO2p fBZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MuDggmqLUxPEnr7jczEEY7MJd34Y50wJKZJAALKk/jk=; b=OjyhplaynW/I6YMvljAKLvvJR8+NgLw70+SpS9KCsGgfV1FxaFM4NBHOl3pYzk3e4o wWPkUVih3TGubHAtAlcf+Y/4QM6CexlA+zOyfedju6JMV6rm/4uSLiqXL7MtZxW54Xn/ aZkf+VvODOt9NAUz1E+ct8+FzX2sccWIO77FSwu+iZ+gqkLKiKhYtXromr0KaXv7PG4p 6+cVjnH+2h10WyyHtzUV9KddYvAWht7LP6ONI+UvIn/2Q9SHYQ1WR/Xwiy+AlC9Au8ST 9r4MEvAFbjoKEYzgy/g8WVUm5l1czpVMZeGXw2PmwqvQJjUmtOl1+IAKmZnXpkL0BptY UbMA== X-Gm-Message-State: ALQs6tA8SuyJ1Ux4AFxtT3uQJc4vppCFSf199fDuKrKUKtJoo5yhVlFa bazRSE4ySxklnR0XBANBbf5iigWvw93xu4UspcQ= X-Google-Smtp-Source: AIpwx49Eszns53aaU6O1upNWcMPRLDFb0DbNsfGQ9QeJj4KJ36//WUVgP7QI5JBWiRiZGr5JXg7+qXFy9l4BCNPzLbI= X-Received: by 2002:a19:7385:: with SMTP id h5-v6mr19618347lfk.67.1523131155437; Sat, 07 Apr 2018 12:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.85.13 with HTTP; Sat, 7 Apr 2018 12:59:14 -0700 (PDT) In-Reply-To: References: <20180320070745.GA12880@server.rulingia.com> <2b3db2af-03c7-65ff-25e7-425cfd8815b6@FreeBSD.org> <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> From: Justin Hibbits Date: Sat, 7 Apr 2018 14:59:14 -0500 Message-ID: Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Don Lewis Cc: Mark Johnston , Jeff Roberson , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:59:18 -0000 Hi Don, > I initially missed that this was on powerpc. I believe that arch is a > bit odd with characters unsigned by default and arithmentic shifts > always being unsigned. Things like that could mess up the algorithm, > but I didn't see anything suspicious in the r329882 diff. I think the biggest difference for powerpc64 vs amd64 in this case is the (currently) relatively small KVA (7.5GB vs 2(?) TB). That might make a difference regarding VM pageout calculations. - Justin From owner-freebsd-current@freebsd.org Sat Apr 7 20:34:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 884C0F83171 for ; Sat, 7 Apr 2018 20:34:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1FE684C51; Sat, 7 Apr 2018 20:34:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x231.google.com with SMTP id x77so5444840ioi.2; Sat, 07 Apr 2018 13:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=i3PZCVZM8PZLli0d/fA+tdsj3LvWSDz7sy6cRNhdsrk=; b=S6Dpyvs9+EisSSH2TBlwDWVNE+U2V+AYhkFBvKx0N2hbOOXsQHpey5uLkDIbLnX834 LoPHb9VXxVjRob5/zIGgDB8PO1dtpyOoM899m1IsUu75aqx5GuH7o0V+IComEV/5eDzP frz/HSwvQjMuOxJ8Tn+p3LvorQiD7Z/+RTWX0vb3TcldXDXy9BYXSoqrYa98VipA9CL+ ackYL7/vwKKFD64dg0cy5Vbl6pbpyYxffSahBpqExLdPUTnLphuwAKUku/3BXSvxNGeX 5Nd0Yd39Gy2/f7DnC6gUngm40RJRnEF+AwOkat2M7X15y30WryfKEQynNPrHaqfz79nm nJOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=i3PZCVZM8PZLli0d/fA+tdsj3LvWSDz7sy6cRNhdsrk=; b=E1WuLhb+y40RV9N/UBgI3bTXAag/OOlThqAnz3t1B79lK92JF5frGPHXot5zC0NQYX NO0zw5zncUi8xl9H7HEE3xPysjwfzNDqyo6gk1oK4ebDfH6bx3z4zroz8VtQ+jHan/aY uI0qn0tRRbIcKI4fnrAewFfUyLZOzzA1yf3xUHrBRrSjMwASJjuWjLdG2yXe5t8yw/DS kC4PuMlnltTHBlbgkS2eNFKvcFq0vIWY84g/ukRHu3MJCuOrOIFOLkZ+KapwTiaUO3uh S43hDqOaMwi5PyE6AfpzbxCT+mn5cM79gIwmSV5n1djyK0suUL7zWnwTtXgBgLvMMwp9 Bymg== X-Gm-Message-State: AElRT7FpYP5O6A28JHC8+KpytyNa9xJpop6vkJYz8OujLmwTf6q2Ga+s G0rCrBJlM0rXtxakisD3NHmpZh2GfMF6JAsi1xLnbg== X-Google-Smtp-Source: AIpwx4820mfAfUpml9UYIgKeDnmNr794QyySlhskZdqr5h6EkU0PbamqGQs5d6Tz21IME20KHxEMOzihZ3BfOGtRpys= X-Received: by 10.107.46.30 with SMTP id i30mr29913937ioo.288.1523133285188; Sat, 07 Apr 2018 13:34:45 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Sat, 7 Apr 2018 13:34:24 -0700 (PDT) In-Reply-To: <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> References: <20180405223852.GA43120@troutmask.apl.washington.edu> <20180406001514.GA43793@troutmask.apl.washington.edu> <347cc907-96b3-140d-5a8f-084f91283be5@nomadlogic.org> <6691B42A-E56F-4432-82FA-42BC410EC152@FreeBSD.org> <09A15F48-0AEA-48C5-920B-232E474B405B@FreeBSD.org> From: Ed Maste Date: Sat, 7 Apr 2018 16:34:24 -0400 X-Google-Sender-Auth: HpAdITq3v3qT-dgbmmuW-lKl-PI Message-ID: Subject: Re: clang manual page? To: Dimitry Andric Cc: David Chisnall , Pete Wright , Steve Kargl , Conrad Meyer , freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 20:34:46 -0000 On 6 April 2018 at 07:25, Dimitry Andric wrote: > > With lld there wasn't even *any* form of command line documentation > yet, which is why Ed slapped together a man page (that could probably > still use more details). It should really be upstreamed, in Sphinx's > RST format, or since they appear to gravitate towards Markdown now, > maybe already in that format. The lld manpage was committed upstream a while ago in fact, and has had a round of improvements since then from both lld and OpenBSD/mandoc developers. We'll get these improvements with the next LLVM update. From owner-freebsd-current@freebsd.org Sat Apr 7 21:47:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0664AF8864A for ; Sat, 7 Apr 2018 21:47:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 758CD6DACA for ; Sat, 7 Apr 2018 21:47:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3A997F88647; Sat, 7 Apr 2018 21:47:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF92AF8863E for ; Sat, 7 Apr 2018 21:47:53 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 695256DAA1; Sat, 7 Apr 2018 21:47:53 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id v205so2682750vkv.13; Sat, 07 Apr 2018 14:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Nn+ZYenNqoZFpzMWX61H2fVFCr3Dafy7fydM++qhlQ=; b=qd6gLKCzh2X85YKE4hS2cCcSnMj+XoPRqHzc8u0KJYKw7Rv36i2oOokIThxsGtfkFC 4etllAclLAKp6MmH0Q3k8I5iD+vDbQIg9IC2NgA8QuZGNXhqju76z6TnrkGJNdNfpE8J 03ZA2sgPwXJHIAJuImsec1iJ/3Kkl5XqKsAWFZzBrQTBgsPMpHZmOS+/4Cv3kdVRr+sW Hd5321g2GmZHA57bbyJ9qHCjrgntWKIkt0QVCgqJOzKV90HZHtSVdjab0A0IMmWl7Vr9 nhjH5SQEL34QJoKH1Yc01vpghvi0sYaBh3noqaupEPoKSwNQvii34X7FK1g+7bexSiUO EB7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/Nn+ZYenNqoZFpzMWX61H2fVFCr3Dafy7fydM++qhlQ=; b=kG4TpGgNayogxi0txSfqz9FQcNMu2/JtUyBdyFLhors3F9tAX1rlnpCG1oMattMclE QOe5Zg1fpW2lOF6yqi3dk2YHELwogDQQXgsdO5Q76dcNZ4HRzjEN7T8YjC6n3hzh/gfM XsorqzbRKZ36EYGixcAQLRQpTIqMo0lIEaiNZxu1lXGCI9DY8D+1bJWN3mQ+gxJdixjD Apc+eRJCQDp+8QBaQDyXj8/TdqNouh8+8zjVyr2LoRA20AbcT+WpnQhMDKVVryPCGG8t GT+Xwu46opljyM/EW22sIcPdG11steWDSzCnE74uKlQ9jkhg+jYDeziXGkvsZ3K8UbpS OkqA== X-Gm-Message-State: ALQs6tBidcJbkQ4nJ4zMNlB5NtlvLoOVAVJer86CS8lG/Fq0pHer8T3A S31SYW9d7NAWCJg/raPTbTpg6Ic0k4NXDOs/bjjrsw== X-Google-Smtp-Source: AIpwx4+rPZeiRLld5b2rOOA1DBp56slXRQ1glyn3RZJQt8WFTXFDG82J2LW/u3k87R6Z5/2cuvj7Jf69Utn6yBHL3cA= X-Received: by 10.31.56.205 with SMTP id f196mr2949135vka.45.1523137672388; Sat, 07 Apr 2018 14:47:52 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.91.5 with HTTP; Sat, 7 Apr 2018 14:47:51 -0700 (PDT) In-Reply-To: <20180407143111.00005020@FreeBSD.org> References: <20180406204010.00006e84@FreeBSD.org> <201804061830.w36IUQbj004046@pdx.rh.CN85.dnsmgr.net> <20180406234417.0000744d@FreeBSD.org> <20180407143111.00005020@FreeBSD.org> From: Kevin Oberman Date: Sat, 7 Apr 2018 14:47:51 -0700 X-Google-Sender-Auth: 0B2ccCEhlRUt5c5JVCVMlbUu0kU Message-ID: Subject: Re: failing to install 11.1R on VMWare To: Ion-Mihai Tetcu Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 21:47:55 -0000 Mercy! He probably assumed memory in GB and thought 4GB was plenty. Dumb but understandable mistake. I've made similar ones, but try not to make a habit of it. (My wife probably disagrees.) Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Apr 7, 2018 at 4:31 AM, Ion-Mihai Tetcu wrote: > > [ combining 2 mails sent yesterday that didn't made it to the list ] > > Lol, looking over the one that fails ... RAM is set at 4MB. Which I > think it might be the default on that cluster for some reason. > I'll test now with a sane amount of RAM. Apologies for the noise. > > Yep, with 1GB it's OK. > Can't wait for the next week to kill the guy who configured that VM > before handling it over to me. > Sorry again for waisting your time. > > > On Fri, 6 Apr 2018 23:44:17 +0300 > Ion-Mihai Tetcu wrote: > > > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT) > > "Rodney W. Grimes" wrote: > > > > > > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > > > > /boot/kernel/kernel text=014972f8 > > > > > > > > elf64_loadimage: read failed > > > > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > > > > ... > > > > > > > > (for 10.4R similar just with a different address). > > > > [ .. ] > > > > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not > > > > anything else) and got the same result trying to boot the 10.4R > > > > boot-only ISO). Would it make any diff if I create the VM from > > > > scratch on that host? > > > > > > Um, moving .vmx files around between versions of vsphere has to be > > > done with a good deal of care, and given your having "issues" to > > > start with I would not add that complexity to this problem. > > > > > > Create an new empty vm on 6.5.0, and use HW level 8, that is > > > portable accross 5.5 to 6.5. > > > > > > Also try sticking with ONLY IDE disks and cdrom, that might > > > be causing an issue. > > > > OK I created a new machine, almost with defaults (changed the disk to > > IDE and independent-nonpersistent, put the CDROM on the same > > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM > > version 8) and the installer booted OK, got to the welcome screen. > > I'll play more tomorrow since it's almost midnight and I have to be up > > in 4h. Many thanks for the help. > > > > > > Here's the vmx of it: > > >>> > > .encoding = "UTF-8" > > config.version = "8" > > virtualHW.version = "8" > > nvram = "FREEBSD-test2.nvram" > > pciBridge0.present = "TRUE" > > svga.present = "TRUE" > > pciBridge4.present = "TRUE" > > pciBridge4.virtualDev = "pcieRootPort" > > pciBridge4.functions = "8" > > pciBridge5.present = "TRUE" > > pciBridge5.virtualDev = "pcieRootPort" > > pciBridge5.functions = "8" > > pciBridge6.present = "TRUE" > > pciBridge6.virtualDev = "pcieRootPort" > > pciBridge6.functions = "8" > > pciBridge7.present = "TRUE" > > pciBridge7.virtualDev = "pcieRootPort" > > pciBridge7.functions = "8" > > vmci0.present = "TRUE" > > hpet0.present = "TRUE" > > memSize = "1024" > > sched.cpu.units = "mhz" > > sched.cpu.affinity = "all" > > sched.cpu.latencySensitivity = "normal" > > sched.mem.affinity = "all" > > powerType.powerOff = "default" > > powerType.suspend = "default" > > powerType.reset = "default" > > scsi0.virtualDev = "lsilogic" > > scsi0.present = "TRUE" > > ide0:0.fileName = "FREEBSD-test2.vmdk" > > ide0:0.mode = "independent-nonpersistent" > > sched.ide0:0.shares = "normal" > > sched.ide0:0.throughputCap = "off" > > ide0:0.present = "TRUE" > > ethernet0.virtualDev = "e1000" > > ethernet0.networkName = "VM Network" > > ethernet0.addressType = "vpx" > > ethernet0.generatedAddress = "00:50:56:8d:99:50" > > ethernet0.present = "TRUE" > > ide0:1.deviceType = "cdrom-image" > > ide0:1.fileName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ > ISO/FreeBSD-11.1-RELEASE-amd64-bootonly.iso" > > ide0:1.present = "TRUE" floppy0.startConnected = "FALSE" > > floppy0.clientDevice = "TRUE" > > floppy0.fileName = "vmware-null-remote-floppy" > > displayName = "FREEBSD-test2" > > guestOS = "freebsd-64" > > toolScripts.afterPowerOn = "TRUE" > > toolScripts.afterResume = "TRUE" > > toolScripts.beforeSuspend = "TRUE" > > toolScripts.beforePowerOff = "TRUE" > > uuid.bios = "42 0d 6c 09 83 cf 81 5d-12 6d a8 de 4d 1a 3a d6" > > vc.uuid = "50 0d 05 1e 9d 59 64 6a-c5 a8 b4 1b b4 f6 55 9a" > > migrate.hostLog = "FREEBSD-test2-490e49c9.hlog" > > sched.cpu.min = "0" > > sched.cpu.shares = "normal" > > sched.mem.min = "0" > > sched.mem.minSize = "0" > > sched.mem.shares = "normal" > > numa.autosize.vcpu.maxPerVirtualNode = "1" > > numa.autosize.cookie = "10001" > > sched.swap.derivedName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ > FREEBSD-test2/FREEBSD-test2-6b4fc32b.vswp" > > uuid.location = "56 4d af 84 7d ea 6b 51-e6 40 16 dd 81 07 1c 64" > > ide0:0.redo = "" pciBridge0.pciSlotNumber = "17" > > pciBridge4.pciSlotNumber = "21" > > pciBridge5.pciSlotNumber = "22" > > pciBridge6.pciSlotNumber = "23" > > pciBridge7.pciSlotNumber = "24" > > scsi0.pciSlotNumber = "16" > > ethernet0.pciSlotNumber = "32" > > vmci0.pciSlotNumber = "33" > > vmci0.id = "1293564630" > > hostCPUID.0 = "0000000d756e65476c65746e49656e69" > > hostCPUID.1 = "000306e40020080077bee3ffbfebfbff" > > hostCPUID.80000001 = "0000000000000000000000012c100800" > > guestCPUID.0 = "0000000d756e65476c65746e49656e69" > > guestCPUID.1 = "000306e400010800969822030fabfbff" > > guestCPUID.80000001 = "00000000000000000000000128100800" > > userCPUID.0 = "0000000d756e65476c65746e49656e69" > > userCPUID.1 = "000306e400010800969822030fabfbff" > > userCPUID.80000001 = "00000000000000000000000128100800" > > evcCompatibilityMode = "FALSE" > > monitor.phys_bits_used = "40" > > vmotion.checkpointFBSize = "4194304" > > cleanShutdown = "TRUE" > > softPowerOff = "FALSE" > > > > >>> > > > > And here's the one that fails to boot: > > >>> > > .encoding = "UTF-8" > > config.version = "8" > > virtualHW.version = "11" > > nvram = "FREEBSD TESTE.nvram" > > pciBridge0.present = "TRUE" > > svga.present = "TRUE" > > pciBridge4.present = "TRUE" > > pciBridge4.virtualDev = "pcieRootPort" > > pciBridge4.functions = "8" > > pciBridge5.present = "TRUE" > > pciBridge5.virtualDev = "pcieRootPort" > > pciBridge5.functions = "8" > > pciBridge6.present = "TRUE" > > pciBridge6.virtualDev = "pcieRootPort" > > pciBridge6.functions = "8" > > pciBridge7.present = "TRUE" > > pciBridge7.virtualDev = "pcieRootPort" > > pciBridge7.functions = "8" > > vmci0.present = "TRUE" > > hpet0.present = "TRUE" > > numvcpus = "2" > > memSize = "4" > > sched.cpu.units = "mhz" > > sched.cpu.affinity = "all" > > sched.mem.affinity = "all" > > powerType.powerOff = "soft" > > powerType.suspend = "hard" > > powerType.reset = "soft" > > scsi0.present = "TRUE" > > scsi0:0.deviceType = "scsi-hardDisk" > > scsi0:0.fileName = "FREEBSD TESTE.vmdk" > > sched.scsi0:0.shares = "normal" > > sched.scsi0:0.throughputCap = "off" > > scsi0:0.present = "TRUE" > > ethernet0.virtualDev = "e1000" > > ethernet0.networkName = "VM Network" > > ethernet0.addressType = "vpx" > > ethernet0.generatedAddress = "00:50:56:8d:16:12" > > ethernet0.present = "TRUE" > > ide1:0.deviceType = "cdrom-image" > > ide1:0.fileName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ > ISO/FreeBSD-10.4-RELEASE-amd64-bootonly.iso" > > ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" > > floppy0.clientDevice = "TRUE" > > floppy0.fileName = "vmware-null-remote-floppy" > > displayName = "FREEBSD TESTE" > > guestOS = "freebsd-64" > > toolScripts.afterPowerOn = "TRUE" > > toolScripts.afterResume = "TRUE" > > toolScripts.beforeSuspend = "TRUE" > > toolScripts.beforePowerOff = "TRUE" > > uuid.bios = "42 0d 30 04 8a 71 92 9b-43 6e b2 94 90 6a ac 3a" > > vc.uuid = "50 0d de ad cb e0 9b 3c-f1 1c d5 56 2e 98 d9 a5" > > sched.cpu.min = "0" > > sched.cpu.shares = "normal" > > sched.mem.min = "0" > > sched.mem.minSize = "0" > > sched.mem.shares = "normal" > > virtualHW.productCompatibility = "hosted" > > sched.swap.derivedName = > > "/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/FREEBSD > > TESTE/FREEBSD TESTE-b65a4b76.vswp" replay.supported = "FALSE" > > replay.filename = "" migrate.hostlog = "./FREEBSD TESTE-b65a4b76.hlog" > > scsi0:0.redo = "" > > pciBridge0.pciSlotNumber = "17" > > pciBridge4.pciSlotNumber = "21" > > pciBridge5.pciSlotNumber = "22" > > pciBridge6.pciSlotNumber = "23" > > pciBridge7.pciSlotNumber = "24" > > scsi0.pciSlotNumber = "16" > > ethernet0.pciSlotNumber = "32" > > vmci0.pciSlotNumber = "33" > > vmci0.id = "-1872057286" > > monitor.phys_bits_used = "42" > > vmotion.checkpointFBSize = "4194304" > > vmotion.checkpointSVGAPrimarySize = "4194304" > > cleanShutdown = "TRUE" > > softPowerOff = "FALSE" > > tools.remindInstall = "FALSE" > > scsi0.virtualDev = "lsilogic" > > scsi0.sasWWID = "50 05 05 64 8a 71 92 90" > > sata0.pciSlotNumber = "34" > > sata0.present = "TRUE" > > config.readOnly = "FALSE" > > numa.autosize.vcpu.maxPerVirtualNode = "2" > > numa.autosize.cookie = "20001" > > >>> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >