From owner-freebsd-current@freebsd.org Sun Aug 9 16:47:09 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 392F63B918B for ; Sun, 9 Aug 2020 16:47:09 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BPlPS1dSPz4Cgx for ; Sun, 9 Aug 2020 16:47:07 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 5EC8D9C34 for ; Sun, 9 Aug 2020 12:47:00 -0400 (EDT) To: freebsd-current From: Michael Butler Subject: cross-build failure on objcopy Message-ID: Date: Sun, 9 Aug 2020 12:46:59 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-NZ Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BPlPS1dSPz4Cgx X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.97)[-0.973]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.07)[-1.065]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.38)[-0.383]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 16:47:09 -0000 When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get the error below after a previously successful build. Running the build again (a 3rd time) completes successfully :-( This is the output from cd /usr/src/release; ./release.sh -c release-i386.conf [ .. ] ===> usr.bin/cxxfilt (all) ===> usr.bin/objcopy (all) ===> usr.sbin/bsnmpd/tools/bsnmptools (all) ===> usr.bin/file2c (all) ===> usr.bin/gprof (all) ===> usr.bin/indent (all) ===> usr.bin/lex (all) ===> usr.bin/mkstr (all) ===> usr.bin/nm (all) objcopy: open objcopy failed: Text file busy --- objcopy --- *** [objcopy] Error code 1 make[4]: *** objcopy removed make[4]: stopped in /usr/local/release-builds/i386/usr/src/usr.bin/objcopy .ERROR_TARGET='objcopy' .ERROR_META_FILE='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.bin/objcopy/objcopy.meta' .MAKE.LEVEL='4' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes' _ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=objcopy.debug objcopy.full objcopy;' .CURDIR='/usr/local/release-builds/i386/usr/src/usr.bin/objcopy' .MAKE='make' .OBJDIR='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.bin/objcopy' .TARGETS='all' DESTDIR='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/local/release-builds/i386/usr/src/share/mk' imb From owner-freebsd-current@freebsd.org Sun Aug 9 17:22:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 738D43BA700 for ; Sun, 9 Aug 2020 17:22:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BPmBM1vnKz4F7Z for ; Sun, 9 Aug 2020 17:22:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.nyi.freebsd.org (Postfix) id 415AE3BA0FF; Sun, 9 Aug 2020 17:22:35 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 401053BA151 for ; Sun, 9 Aug 2020 17:22:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BPmBK6rjmz4FDF; Sun, 9 Aug 2020 17:22:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 079HMV7l027387 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Aug 2020 10:22:31 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 079HMUEb027386; Sun, 9 Aug 2020 10:22:30 -0700 (PDT) (envelope-from jmg) Date: Sun, 9 Aug 2020 10:22:30 -0700 From: John-Mark Gurney To: Filippo Moretti Cc: FreeBSD Current , "flz@freebsd.org" Subject: Re: Problem compiling chromium Message-ID: <20200809172230.GL4213@funkthat.com> Mail-Followup-To: Filippo Moretti , FreeBSD Current , "flz@freebsd.org" References: <1582441101.10722462.1596356639024.ref@mail.yahoo.com> <1582441101.10722462.1596356639024@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1582441101.10722462.1596356639024@mail.yahoo.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 09 Aug 2020 10:22:31 -0700 (PDT) X-Rspamd-Queue-Id: 4BPmBK6rjmz4FDF X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [1.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.03)[0.033]; NEURAL_SPAM_SHORT(0.24)[0.240]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.33)[0.326]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 17:22:35 -0000 Filippo Moretti wrote this message on Sun, Aug 02, 2020 at 08:23 +0000: > This is the last eror I get attempting to compile chromium on amd64 arch R363570[263/38159] python ../../mojo/public/tools/mojom/mojom_parser.py --input-root /usr/ports/www/chromium/work/chromium-84.0.4147.105/ --input-root /usr/ports/www/chromium/work/chromium-84.0.4147.105/out/Release/gen --output-root /usr/ports/www/chromium/work/chromium-84.0.4147.105/out/Release/gen --mojom-file-list=__mojo_public_mojom_base_base__parser___build_toolchain_linux_clang_x64__rule..rsp --check-imports /usr/ports/www/chromium/work/chromium-84.0.4147.105/out/Release/gen/mojo/public/mojom/base/base.build_metadata --enable-feature file_path_is_string --enable-feature is_posix --enable-feature is_linux > [264/38159] python ../../tools/licenses.py --target-os=freebsd --depfile gen/components/resources/about_credits.d credits gen/components/resources/about_credits.html > FAILED: gen/components/resources/about_credits.html > python ../../tools/licenses.py --target-os=freebsd --depfile gen/components/resources/about_credits.d credits gen/components/resources/about_credits.html > Traceback (most recent call last): >   File "../../tools/licenses.py", line 807, in >     sys.exit(main()) >   File "../../tools/licenses.py", line 792, in main >     args.gn_target, args.depfile): File "../../tools/licenses.py", line 720, in GenerateCredits >     license_file_list + ['build.ninja']) >   File "/usr/ports/www/chromium/work/chromium-84.0.4147.105/build/android/gyp/util/build_utils.py", line 619, in WriteDepfile >     inputs = ComputePythonDependencies() + inputs >   File "/usr/ports/www/chromium/work/chromium-84.0.4147.105/build/android/gyp/util/build_utils.py", line 557, in ComputePythonDependencies >     p for p in abs_module_paths if p.startswith(abs_dir_source_root) >   File "/usr/ports/www/chromium/work/chromium-84.0.4147.105/build/android/gyp/util/build_utils.py", line 557, in >     p for p in abs_module_paths if p.startswith(abs_dir_source_root) >   File "/usr/ports/www/chromium/work/.bin/../../../../../local/lib/python3.7/posixpath.py", line 378, in abspath >     path = os.fspath(path) > TypeError: expected str, bytes or os.PathLike object, not NoneType > ninja: build stopped: subcommand failed. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/www/chromium Are you sure that chromium is Python 3 clean? Python 2 was recently deprecated, so likely this is fallout from that. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Sun Aug 9 22:19:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 782513BF222 for ; Sun, 9 Aug 2020 22:19:42 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BPtn94PX9z4STn for ; Sun, 9 Aug 2020 22:19:41 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id p20so6457306wrf.0 for ; Sun, 09 Aug 2020 15:19:41 -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=kZjsfE8kXEd36MuJlb+ciFy1dzqjAO+aDcUKHqCbaEM=; b=N/5xNU0iC3vRClRZuyGCE3RcPRsH9kwx5fYWPJLSUm0yib6mKmRTTs5RSH53JACcR6 nWOz0an3diyNakdd/+gOswocrz5HAu/v89QsMxC3BlSwDB3MGAhnHIwREGpDyEK8HiPv r2f/F3qcTrnYfUr2VDHGQdYYYufZlNjzbOsnwV0dC8ThkMta4vcPZG3YZaItK7iXDXd6 6iPI7A89rv5qBE47Nbgjaya60KEstqjfnfZjcpQ6rEhHLOr49Bo4oeBmt8kcU31YDLZh djtXQoTzAqKUoB5pM6hNUUp8FW3M2k/O8VnR76ANuaWx6Y0SBJTNC3ei7fZu3n8R1SeX 2Elg== 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=kZjsfE8kXEd36MuJlb+ciFy1dzqjAO+aDcUKHqCbaEM=; b=Dm9gP71C1BzgGUN0rPQlhBNqRYErdVVheR4LNSCbQqc/C9tIva45m92OKQpC0ALaHu Tmq7JIKn/AlXUf+uPWRhy8MFKndNjeDjRdOwNJuemHo6oT1gAByhQXmxQSMvl6EXGey3 MKGIu2WYAZ37rBKL3PyugRmpPF6fgAh/VnaeREBQXxHmoOVU6QxBvpId4M47nuRf91Qf SUePnNqOcv6GO6iYf/XJ40cYRjznGLEpHvtbmSU9EvGxRsBYVGsSwEw8NtSe29tn5k+N Ta2cBwbb+y7traIqN0ZABg4ZBPgqOLBrPA5J8fVHQ2yR6kv0AV3inQz6aJ9C7AowmnUc ZGOQ== X-Gm-Message-State: AOAM531h7Kp55XP5uZiPzFTtop9rdomsucJa66IBIt6yNWKPJUltNvUR p9MYTHhmLBVPguu5/mSY6FArM+eP7n9WzBanLlHOovg4MJQ= X-Google-Smtp-Source: ABdhPJwVgKzhq2wp6EDkSwKjHSxPGsISfdWqIP+cJ/udrVedCERTOOTDMM3X5a0AgrhYzErp9wOwrnFKvTp5z94H+GE= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr9976948wrp.412.1597011578290; Sun, 09 Aug 2020 15:19:38 -0700 (PDT) MIME-Version: 1.0 From: Alexandre Levy Date: Sun, 9 Aug 2020 23:19:26 +0100 Message-ID: Subject: Kernel crash during video transcoding To: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BPtn94PX9z4STn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=N/5xNU0i; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.08)[-1.077]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.968]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42a:from]; NEURAL_HAM_SHORT(-0.02)[-0.022]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 22:19:42 -0000 Hi, I installed the port drm-devel-kmod for Plex to be able to transcode videos using the integrated GPU of my Intel Celeron G5900. I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG profile. Transcoding has been working fine for quite a while now but one video transcoding is causing a kernel panic that is reproducible all the time with that particular video. It seems like it's caused by the i915kms module (call of i915_gms_fault() in the stack) : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdf fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80bdd2b4 stack pointer = 0x0:0xfffffe00d2be56d0 frame pointer = 0x0:0xfffffe00d2be56d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4611 (Plex Transcoder) trap number = 12 panic: page fault cpuid = 0 time = 1596976796 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d2be5390 vpanic() at vpanic+0x182/frame 0xfffffe00d2be53e0 panic() at panic+0x43/frame 0xfffffe00d2be5440 trap_fatal() at trap_fatal+0x387/frame 0xfffffe00d2be54a0 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00d2be54f0 trap() at trap+0x271/frame 0xfffffe00d2be5600 calltrap() at calltrap+0x8/frame 0xfffffe00d2be5600 --- trap 0xc, rip = 0xffffffff80bdd2b4, rsp = 0xfffffe00d2be56d0, rbp = 0xfffffe00d2be56d0 --- _rw_wowned() at _rw_wowned+0x4/frame 0xfffffe00d2be56d0 vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame 0xfffffe00d2be5710 remap_io_mapping() at remap_io_mapping+0x120/frame 0xfffffe00d2be5760 i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfffffe00d2be57d0 linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame 0xfffffe00d2be5840 vm_fault() at vm_fault+0x3d1/frame 0xfffffe00d2be5950 vm_fault_trap() at vm_fault_trap+0x60/frame 0xfffffe00d2be5990 trap_pfault() at trap_pfault+0x19c/frame 0xfffffe00d2be59e0 trap() at trap+0x3f1/frame 0xfffffe00d2be5af0 calltrap() at calltrap+0x8/frame 0xfffffe00d2be5af0 --- trap 0xc, rip = 0x80296659a, rsp = 0x7fffffffbd38, rbp = 0x80fc00000 --- KDB: enter: panic I don't see any crash dump in /var/crash despite having the right configuration and I should have enough space on my swap device (128GB USB drive) : $ cat /etc/rc.conf | grep dump dumpdev="AUTO" $ swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/crash0 121307096 0 121307096 0% $ cat /etc/fstab /dev/gpt/crash0 none swap sw 0 0 $ dumpon -l gpt/crash0 Not sure why no dump was generated, is it because the kernel was compiled with the GENERIC-NODEBUG profile ? However I see various KDB options in the GENERIC profile that are inherited by GENERIC-NODEBUG. Happy to recompile the kernel with GENERIC profile if it's required. Thank you. From owner-freebsd-current@freebsd.org Mon Aug 10 07:44:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 445F0378BBA for ; Mon, 10 Aug 2020 07:44:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQ7K82yzBz3drv for ; Mon, 10 Aug 2020 07:44:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BF689260287; Mon, 10 Aug 2020 09:44:35 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy , freebsd-current@freebsd.org References: From: Hans Petter Selasky Message-ID: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> Date: Mon, 10 Aug 2020 09:44:14 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BQ7K82yzBz3drv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-0.97)[-0.969]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.08)[-0.077]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 07:44:45 -0000 Hi, On 2020-08-10 00:19, Alexandre Levy wrote: > Hi, > > I installed the port drm-devel-kmod for Plex to be able to transcode videos > using the integrated GPU of my Intel Celeron G5900. > > I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG profile. > > Transcoding has been working fine for quite a while now but one video > transcoding is causing a kernel panic that is reproducible all the time > with that particular video. It seems like it's caused by the i915kms module > (call of i915_gms_fault() in the stack) : If you compile the kernel using GENERIC and then enable debugging in the i915 kms and reproduce, we might get a more clear picture! It is a so called NULL pointer you've experienced. --HPS > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdf > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80bdd2b4 > stack pointer = 0x0:0xfffffe00d2be56d0 > frame pointer = 0x0:0xfffffe00d2be56d0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4611 (Plex Transcoder) > trap number = 12 > panic: page fault > cpuid = 0 > time = 1596976796 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00d2be5390 > vpanic() at vpanic+0x182/frame 0xfffffe00d2be53e0 > panic() at panic+0x43/frame 0xfffffe00d2be5440 > trap_fatal() at trap_fatal+0x387/frame 0xfffffe00d2be54a0 > trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00d2be54f0 > trap() at trap+0x271/frame 0xfffffe00d2be5600 > calltrap() at calltrap+0x8/frame 0xfffffe00d2be5600 > --- trap 0xc, rip = 0xffffffff80bdd2b4, rsp = 0xfffffe00d2be56d0, rbp = > 0xfffffe00d2be56d0 --- > _rw_wowned() at _rw_wowned+0x4/frame 0xfffffe00d2be56d0 > vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame > 0xfffffe00d2be5710 > remap_io_mapping() at remap_io_mapping+0x120/frame 0xfffffe00d2be5760 > i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfffffe00d2be57d0 > linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame > 0xfffffe00d2be5840 > vm_fault() at vm_fault+0x3d1/frame 0xfffffe00d2be5950 > vm_fault_trap() at vm_fault_trap+0x60/frame 0xfffffe00d2be5990 > trap_pfault() at trap_pfault+0x19c/frame 0xfffffe00d2be59e0 > trap() at trap+0x3f1/frame 0xfffffe00d2be5af0 > calltrap() at calltrap+0x8/frame 0xfffffe00d2be5af0 > --- trap 0xc, rip = 0x80296659a, rsp = 0x7fffffffbd38, rbp = 0x80fc00000 --- > KDB: enter: panic > > I don't see any crash dump in /var/crash despite having the right > configuration and I should have enough space on my swap device (128GB USB > drive) : > > $ cat /etc/rc.conf | grep dump > dumpdev="AUTO" > > $ swapinfo > Device 1K-blocks Used Avail Capacity > /dev/gpt/crash0 121307096 0 121307096 0% > > $ cat /etc/fstab > /dev/gpt/crash0 none swap sw 0 0 > > $ dumpon -l > gpt/crash0 > > Not sure why no dump was generated, is it because the kernel was compiled > with the GENERIC-NODEBUG profile ? However I see various KDB options in the > GENERIC profile that are inherited by GENERIC-NODEBUG. > > Happy to recompile the kernel with GENERIC profile if it's required. > > Thank you. > _______________________________________________ > 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 Aug 10 08:41:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D388037A26B for ; Mon, 10 Aug 2020 08:41:22 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQ8ZV1FSBz3yhm for ; Mon, 10 Aug 2020 08:41:22 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id r4so7325264wrx.9 for ; Mon, 10 Aug 2020 01:41:22 -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=3Nx0GprOJzO8W5lHuIdaDulaE7OP2OKda+LZE8T3yOg=; b=C0Pv+uW6kdVIPfg1bs0/SKM0U1KWVPvUbsHu+0cpErfzQm5+AhrBj8vD0RVjjlrUmC meDkuLHMHDDc1fLnC7IHguzXr4MAXdximlQkbSQ+9eQsCFzPOUEhvsMxPpFrwJ+xMie/ q5K39bYM/e99i9SR1UZ+Tijxgy8H0V9qC5sleUC3bBexmGizeBQiNUR8xCbhzJzU739A ZhBzvbvfPijvkh2J2TC+TjheFdlT4+2xbbU2dtHoDVKCO5TeEICIUIIsLZEUz1U6OIQo nuoEYR+TtxefRYCXsHFzp4ZCxwc/bgettIOLZURUtepvUG/s+aPr+9h0DWu9YPsbgWW4 F+2Q== 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=3Nx0GprOJzO8W5lHuIdaDulaE7OP2OKda+LZE8T3yOg=; b=q9JKJaVOHLRLLsgxySrXgsu/1UUJ+b+QZ/2bWXL7WlcEB20uSmwogfRcBDKwmJYKDA Lw4ASddXIa5KVIXv1kIAKzbpfw/rSk0Z2kD0e11Nv/9glJiMFhRjNV4mTsDxkhr8Cmdp Cucha/1xdafun92ByGgISK8HzziNUE1EwOpxWGwzt+VwsUlNNfOVmGuudqRNdjQhzMya bxBmylkxbwzL2OagFLYI3Tj+2xUS1QXQ1BwMJz3qCgb4KrLfTaj+Y/NOFVXmx145128v soKjQiaVBNTbuj+yB8ORqiIMXkIvxp/+wX9PF35rVadAnM4OcMsLXK3Nx1f3s1ncMGv7 9Zkg== X-Gm-Message-State: AOAM533xQZtRHVYdyWGOgaIqxEvOg/0SqNdIM6L7MhGM6fogjdXlhPj1 9P/Cnq94DpOc5GDJyrh4lB+bJkhRCGftDomikGObbc+N X-Google-Smtp-Source: ABdhPJxS74LbFtRSmVxcyoNhxRQB0oGU8GplA7J065CCwuC4hjRT4og43AxwRNJpqQzk/vDa2BqmNzbMjIxlZS+vuag= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr365678wrp.412.1597048880774; Mon, 10 Aug 2020 01:41:20 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> In-Reply-To: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> From: Alexandre Levy Date: Mon, 10 Aug 2020 09:41:08 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BQ8ZV1FSBz3yhm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=C0Pv+uW6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::443 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Spamd-Result: default: False [-4.32 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.073]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.016]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::443:from]; NEURAL_HAM_SHORT(-1.23)[-1.230]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:41:22 -0000 I'm recompiling the kernel using GENERIC at the moment but I'm not sure how to enable debugging in i915 kms, there is no compile option for that, am I missing something ? Le lun. 10 ao=C3=BBt 2020 =C3=A0 08:44, Hans Petter Selasky a =C3=A9crit : > Hi, > > On 2020-08-10 00:19, Alexandre Levy wrote: > > Hi, > > > > I installed the port drm-devel-kmod for Plex to be able to transcode > videos > > using the integrated GPU of my Intel Celeron G5900. > > > > I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG > profile. > > > > Transcoding has been working fine for quite a while now but one video > > transcoding is causing a kernel panic that is reproducible all the time > > with that particular video. It seems like it's caused by the i915kms > module > > (call of i915_gms_fault() in the stack) : > > If you compile the kernel using GENERIC and then enable debugging in the > i915 kms and reproduce, we might get a more clear picture! > > It is a so called NULL pointer you've experienced. > > --HPS > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0xdf > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff80bdd2b4 > > stack pointer =3D 0x0:0xfffffe00d2be56d0 > > frame pointer =3D 0x0:0xfffffe00d2be56d0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 4611 (Plex Transcoder) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > time =3D 1596976796 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe00d2be5390 > > vpanic() at vpanic+0x182/frame 0xfffffe00d2be53e0 > > panic() at panic+0x43/frame 0xfffffe00d2be5440 > > trap_fatal() at trap_fatal+0x387/frame 0xfffffe00d2be54a0 > > trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00d2be54f0 > > trap() at trap+0x271/frame 0xfffffe00d2be5600 > > calltrap() at calltrap+0x8/frame 0xfffffe00d2be5600 > > --- trap 0xc, rip =3D 0xffffffff80bdd2b4, rsp =3D 0xfffffe00d2be56d0, r= bp =3D > > 0xfffffe00d2be56d0 --- > > _rw_wowned() at _rw_wowned+0x4/frame 0xfffffe00d2be56d0 > > vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame > > 0xfffffe00d2be5710 > > remap_io_mapping() at remap_io_mapping+0x120/frame 0xfffffe00d2be5760 > > i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfffffe00d2be57d0 > > linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame > > 0xfffffe00d2be5840 > > vm_fault() at vm_fault+0x3d1/frame 0xfffffe00d2be5950 > > vm_fault_trap() at vm_fault_trap+0x60/frame 0xfffffe00d2be5990 > > trap_pfault() at trap_pfault+0x19c/frame 0xfffffe00d2be59e0 > > trap() at trap+0x3f1/frame 0xfffffe00d2be5af0 > > calltrap() at calltrap+0x8/frame 0xfffffe00d2be5af0 > > --- trap 0xc, rip =3D 0x80296659a, rsp =3D 0x7fffffffbd38, rbp =3D 0x80= fc00000 > --- > > KDB: enter: panic > > > > I don't see any crash dump in /var/crash despite having the right > > configuration and I should have enough space on my swap device (128GB U= SB > > drive) : > > > > $ cat /etc/rc.conf | grep dump > > dumpdev=3D"AUTO" > > > > $ swapinfo > > Device 1K-blocks Used Avail Capacity > > /dev/gpt/crash0 121307096 0 121307096 0% > > > > $ cat /etc/fstab > > /dev/gpt/crash0 none swap sw 0 0 > > > > $ dumpon -l > > gpt/crash0 > > > > Not sure why no dump was generated, is it because the kernel was compil= ed > > with the GENERIC-NODEBUG profile ? However I see various KDB options in > the > > GENERIC profile that are inherited by GENERIC-NODEBUG. > > > > Happy to recompile the kernel with GENERIC profile if it's required. > > > > Thank you. > > _______________________________________________ > > 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 Aug 10 08:43:08 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34C7337A93D for ; Mon, 10 Aug 2020 08:43:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQ8cW0Y5nz40Zc for ; Mon, 10 Aug 2020 08:43:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F1AB9260287; Mon, 10 Aug 2020 10:43:04 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> From: Hans Petter Selasky Message-ID: <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> Date: Mon, 10 Aug 2020 10:42:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BQ8cW0Y5nz40Zc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.34 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.05)[-1.049]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.04)[-1.038]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:43:08 -0000 On 2020-08-10 10:41, Alexandre Levy wrote: > I'm recompiling the kernel using GENERIC at the moment but I'm not sure how > to enable debugging in i915 kms, there is no compile option for that, am I > missing something ? Type: make config Before building the i915kms port, then there should be a DEBUG option you can select. --HPS From owner-freebsd-current@freebsd.org Mon Aug 10 08:45:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6C0A637AD28 for ; Mon, 10 Aug 2020 08:45:01 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQ8fh45B1z40cv for ; Mon, 10 Aug 2020 08:45:00 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id f7so7367333wrw.1 for ; Mon, 10 Aug 2020 01:45:00 -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=Wimt/IEKk8wf6ZuQxCpR7gGMem3eQ/+8n19XufltSdw=; b=kbV33gps7zGpFP3VmeJY/aaCiS0lZwQZjD5XSu62/k2yEMDarAne+9fNWF8j4/oZtW qrrIWdXo29sljw3HQa+jSO1bkCCfvSjSQBZetgxcjHbbdDKkjXC1v5cDLTlXoAwNX4HF XaqbclUaQhpwBVSzM4mGGX0VxiHoUtfRSidKF4EReL5fbIe5njY339arbOWcCkhThoQo buY+z1XGHnkv5ZydHGHpp0s86HCVc17AF61Wjmn+5uC5XLbtFX57nEGCzqNTz9t3XR3J 23e7OfDjY+R6lyfsG/RdxWdxMmn0VJIP6AYahhvJh1QJcfF10lbViQLPJzmH9GvYFGca Bb5w== 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=Wimt/IEKk8wf6ZuQxCpR7gGMem3eQ/+8n19XufltSdw=; b=hgLB4wiiJNXg8wea/nWtLlzAiFbZi9JOtitWIDGKWhpESvGVtqzFTM4MNd26kcVK7X MZpSSDYhtXQyp6UdSKrKVTgS9jTAKDRnBYM3BSLmTGlkr0qn2e4afic66LAyHMgZOF5x /YxvVWvH68VopSqH02NCk6UrVCQ+oPLf2ivzuMhGKYqkBFgNzW7AjvSpuhgDzbu/aX81 Lwa2G+cD1GAa2ioTVdelvTUn4oGZpVl/6lJKRdSWwKN3uVpjKWg29Go72HPZr8cKo90d lK9gvaQJT5oFBqabTE5arJAafNVdx0jnPskHD8IdJ594td7ebqFGSH4aEtMgq8I4IDQD yVow== X-Gm-Message-State: AOAM53124Y5oNN0r2KLl5yBZ4S8PbRPa8SxHCzCDhzpRBD+e7C+OSFcM bLrv9pbo3UoFwa2vZzxHRdCCx3SOB5Mqu+7xdQ4= X-Google-Smtp-Source: ABdhPJyxpwl8bmZw3noRkDbfa5IFGy4NAWXpwWwVb09HJX6Q/uK7cYrXMWGtzrxJxlLfAUvvlvpv8P7liU6UViPDt7k= X-Received: by 2002:adf:9e8d:: with SMTP id a13mr22289522wrf.94.1597049098939; Mon, 10 Aug 2020 01:44:58 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> In-Reply-To: <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> From: Alexandre Levy Date: Mon, 10 Aug 2020 09:44:47 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BQ8fh45B1z40cv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=kbV33gps; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Spamd-Result: default: False [-4.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.071]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.015]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; NEURAL_HAM_SHORT(-1.32)[-1.323]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:45:01 -0000 Ah thanks, I was doing a make config-recursive and that didn't show the DEBUG option. It's recompiling the module with DEBUG now. Le lun. 10 ao=C3=BBt 2020 =C3=A0 09:43, Hans Petter Selasky a =C3=A9crit : > On 2020-08-10 10:41, Alexandre Levy wrote: > > I'm recompiling the kernel using GENERIC at the moment but I'm not sure > how > > to enable debugging in i915 kms, there is no compile option for that, a= m > I > > missing something ? > > Type: > > make config > > Before building the i915kms port, then there should be a DEBUG option > you can select. > > --HPS > From owner-freebsd-current@freebsd.org Mon Aug 10 09:47:23 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 683AD37BF6F; Mon, 10 Aug 2020 09:47:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQB2f3d75z43W9; Mon, 10 Aug 2020 09:47:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1AE6B260287; Mon, 10 Aug 2020 11:47:14 +0200 (CEST) Subject: Re: somewhat reproducable vimage panic To: "Bjoern A. Zeeb" , Kristof Provost Cc: John-Mark Gurney , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Stephen Hurd References: <20200721091654.GC4213@funkthat.com> <20200721113153.42d83119@x23> <20200721202323.GE4213@funkthat.com> <38F5A3A6-B578-4BA4-8F69-C248163CB6E0@libassi.se> <20200722060514.GF4213@funkthat.com> <20200722193443.GG4213@funkthat.com> <6C149617-55BB-4A87-B993-195E5E133790@lists.zabbadoz.net> <20200722221509.GI4213@funkthat.com> <2FFC49F9-83DE-4FA1-A47F-1D8A7AF4B241@FreeBSD.org> <6847FB6B-0B1A-43C7-B567-15BF21AB5D56@FreeBSD.org> <8B72C0B9-9CF0-4557-81D7-77190775805C@lists.zabbadoz.net> From: Hans Petter Selasky Message-ID: <826eb82b-c6f9-9ef0-8dda-14ad00ce183e@selasky.org> Date: Mon, 10 Aug 2020 11:46:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4BQB2f3d75z43W9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.97)[-0.975]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.06)[-1.061]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.59)[-0.587]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 09:47:23 -0000 On 2020-07-23 21:26, Bjoern A. Zeeb wrote: > That’ll probably work;  still, the deferred teardown work seems wrong to > me;  I haven’t investigated;  the patch kind-of says exactly that as > well: if “wait until deferred stuff is done” is all we are doing, why > can we not do it on the spot then? Hi Bjoern, Trying to move the discussion over to Phabricator at: https://reviews.freebsd.org/D24914 The answer to your question I believe is this commit: https://svnweb.freebsd.org/base/head/sys/netinet/in_mcast.c?revision=333175&view=markup It affects both IPv4 and IPv6. I know that sometimes multicast entries can be freed from timer callbacks. I think having a task, probably one is enough, for network related configuration is acceptable. With D24914 there will be two threads to teardown which is probably overkill, but anyway makes a solid solution for now. I don't know why Stephen didn't think about draining those tasks. I know some people are not actively using VIMAGE and that might be the reason. --HPS From owner-freebsd-current@freebsd.org Mon Aug 10 10:20:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FD2537D991 for ; Mon, 10 Aug 2020 10:20:22 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQBmh5WZjz456V for ; Mon, 10 Aug 2020 10:20:20 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.654, required 6, autolearn=not spam, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.46, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 07AAKF6R024351 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [172.16.35.2] (CPEac202e7325b3-CMac202e7325b0.cpe.net.cable.rogers.com [99.253.170.241]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 07AAKF6R024351 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 10 Aug 2020 06:20:16 -0400 Subject: Re: To people upgrading from before r363679 To: freebsd-current@freebsd.org References: From: Dennis Clarke Message-ID: <0169058e-ec49-7ce0-c510-4fd071a239e8@blastwave.org> Date: Mon, 10 Aug 2020 10:20:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BQBmh5WZjz456V X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.965]; NEURAL_HAM_MEDIUM(-1.03)[-1.035]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-0.20)[-0.204]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[99.253.170.241:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 10:20:22 -0000 On 8/5/20 9:19 PM, Warner Losh wrote: > If you are upgrading across r363679, you may have installworld fail, as > documented in UPDATING. > > I have a fix (that requires a trip through buildworld) that's under review > at https://reviews.freebsd.org/D25967 . The changes are likely good, but > comments likely need updating. > > The short version is that we purposely use old libraries to install the > system. We created a symbolic link to a bunch of binaries on the system and > once installworld installs one of them, we get the error. The workaround > works because we copy libc.so before doing the installworld, so now we're > running with a new libc.so with new binaries, which works. My fix always > copies and never symlinks. The symbolic link stuff is too fragile. > > With it, I've done one system, but I'd appreciate reports (on the code > review if possible, to me in email if not) of people who have success > upgrading with this. If you've already run installworld and hit the > undefined symbol, it's too late for you to help me test (since re-running > is the same as hitting to test is the same as the workaround and so it will > work even if my workaround is busted). > > Some history: This was introduced about 2 years ago. Prior to that, we > always copied binaries for the install. This will fix the situation : triton$ triton$ cat /usr/src/my.patch --- Makefile.inc1.orig 2020-08-06 21:55:35.403116000 +0000 +++ Makefile.inc1 2020-08-07 04:51:05.259840000 +0000 @@ -2296,13 +2296,12 @@ .for _tool in ${_bootstrap_tools_links} ${_bt}-link-${_tool}: .PHONY .MAKE - @if [ ! -e "${WORLDTMP}/legacy/bin/${_tool}" ]; then \ - source_path=`which ${_tool}`; \ - if [ ! -e "$${source_path}" ] ; then \ - echo "Cannot find host tool '${_tool}'"; false; \ - fi; \ - ln -sfnv "$${source_path}" "${WORLDTMP}/legacy/bin/${_tool}"; \ - fi + @rm -f "${WORLDTMP}/legacy/bin/${_tool}"; \ + source_path=`which ${_tool}`; \ + if [ ! -e "$${source_path}" ] ; then \ + echo "Cannot find host tool '${_tool}'"; false; \ + fi; \ + cp -f "$${source_path}" "${WORLDTMP}/legacy/bin/${_tool}" ${_bt}-links: ${_bt}-link-${_tool} .endfor --- tools/build/Makefile.orig 2020-08-06 21:55:35.416626000 +0000 +++ tools/build/Makefile 2020-08-07 04:49:09.064737000 +0000 @@ -119,26 +119,26 @@ host-symlinks: @echo "Linking host tools into ${DESTDIR}/bin" .for _tool in ${_host_tools_to_symlink} - @if [ ! -e "${DESTDIR}/bin/${_tool}" ]; then \ - source_path=`which ${_tool}`; \ - if [ ! -e "$${source_path}" ] ; then \ - echo "Cannot find host tool '${_tool}'"; false; \ - fi; \ - ln -sfnv "$${source_path}" "${DESTDIR}/bin/${_tool}"; \ - fi + @source_path=`which ${_tool}`; \ + if [ ! -e "$${source_path}" ] ; then \ + echo "Cannot find host tool '${_tool}'"; false; \ + fi; \ + rm -f "${DESTDIR}/bin/${_tool}"; \ + cp -f "$${source_path}" "${DESTDIR}/bin/${_tool}" .endfor .for _tool in ${_host_abs_tools_to_symlink} @source_path="${_tool:S/:/ /:[1]}"; \ target_path="${DESTDIR}/bin/${_tool:S/:/ /:[2]}"; \ - if [ ! -e "$${target_path}" ] ; then \ - if [ ! -e "$${source_path}" ] ; then \ - echo "Host tool '${src_path}' is missing"; false; \ - fi; \ - ln -sfnv "$${source_path}" "$${target_path}"; \ - fi + if [ ! -e "$${source_path}" ] ; then \ + echo "Host tool '${src_path}' is missing"; false; \ + fi; \ + rm -f "$${target_path}"; \ + cp -f "$${source_path}" "$${target_path}" .endfor .if exists(/usr/libexec/flua) ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua ++ rm -f ${DESTDIR}/usr/libexec/flua ++ cp -f /usr/libexec/flua ${DESTDIR}/usr/libexec/flua .endif # Create all the directories that are needed during the legacy, bootstrap-tools triton$ triton$ uname -apKU FreeBSD triton 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r363997: Fri Aug 7 02:48:03 GMT 2020 root@triton:/usr/obj/usr/src/head/amd64.amd64/sys/GENERIC amd64 amd64 1300105 1300105 Dennis From owner-freebsd-current@freebsd.org Mon Aug 10 11:00:17 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1A2BB37E9B1 for ; Mon, 10 Aug 2020 11:00:17 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQCfk6746z48My for ; Mon, 10 Aug 2020 11:00:14 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wm1-x344.google.com with SMTP id t14so7886812wmi.3 for ; Mon, 10 Aug 2020 04:00:14 -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=y9kd3Jk3eUoHTrZlTFjd4+35fg3weWz9iFsL6KMMgeo=; b=gYel72oLxYDymeOV/S82QEzMJHaFEniBPnmqMH/OfF6BILNAaOKGMBT+xqzKYaLpLG r2E0h1Uk+hCAWSdWkgb9iH2G4zWctTuK15d8XgGMQzu3EMtVbcDXGCW9J/ELdEDdOGmA tiQV9NWE0IoG7ogK+MJyo4k80tt9r/NqBF/H5o1Qo9SovoEO4kbp8tNLgt+WWNhlAZii dZ4UZwwwO4OAgD1EBvfmq8pr8tPcYmRpm9nF880Ilhrdkxg8oqcrhRWV5Uy176ePbnjO JxD8bYoBPJLGRj4fZTO1cBMfCsv4DqotUl5rgjl+j2ynrf5TOvPQ27z7ogLPjSh+e2qT tfjA== 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=y9kd3Jk3eUoHTrZlTFjd4+35fg3weWz9iFsL6KMMgeo=; b=CG+6czwX3F8XoMtTMxdcfgEzt/NjHTCRtvffCnNrF1VqW+Xq2Xnh+vL9mSSJTOisbh JDf/B4kQhSIfndysmtj8C2XzCdG3jR0fZ4CJaPgDgVZT2L+vewDdoDugo4YIFSEE3Sso gm7FY8w8SJ9QoBuUZC2sZSkeRIdLwI8LRDeYe5oXVU5i/1C8KSG/zswjTnxxa7SClfwl /eeblvg1niM6Q9DWwTSp9cj8LBR1C0SY6ZG+X77CR7KTAIR8ht+1kBrpp/UxOpbG1MWD DivsfxehIAWmY9IUxnX1hv2lR1i2srp96aVRSKidGFecfifORuewxKoOyyKHOKtddzl0 OYbw== X-Gm-Message-State: AOAM533Q+WjtepdLVxKs9jM8M+9tU3cFajDTJYaMzjcWu5YbEAHMTBEF TBEwMGfog15ubshPCh3KmLBr+28PeyW+51/uDUDroL2y5hA= X-Google-Smtp-Source: ABdhPJzES1JLiKNUlvp1DHlaiZFWNbhg1uJVI8rfZ24qEw2eekvh1LM04MaGXmpxh4km2zV4fm4Y9sz+u25dPjZyrmQ= X-Received: by 2002:a7b:c105:: with SMTP id w5mr24423127wmi.146.1597057212064; Mon, 10 Aug 2020 04:00:12 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> In-Reply-To: From: Alexandre Levy Date: Mon, 10 Aug 2020 11:59:59 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BQCfk6746z48My X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gYel72oL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::344 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Spamd-Result: default: False [-3.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.072]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.016]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::344:from]; NEURAL_HAM_SHORT(-0.42)[-0.420]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 11:00:17 -0000 I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and I got this additional info (still no crash dump though) : Kernel page fault with the following non-sleepable locks held: kernel: exclusive rw vm object (vm object) r =3D 0 (0xfffff8037533bc60) locked @ /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/intel_freebsd.c:186 Looking at the code, the error happens during the call to VM_OBJECT_WLOCK (memory page locking for write ?) in the intel_freebsd.c (see [1] below). I'm out for a few days but I'll try to dig more into it when I'm back next weekend although I have no experience in the drm-devel-kmod codebase. In the meantime if you have any suggestions on debugging this further I'm happy to follow them. Thanks again. [1] i915/intel_freebsd.c int remap_io_mapping(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, unsigned long size, struct io_mapping *iomap) { vm_page_t m; vm_object_t vm_obj; vm_memattr_t attr; vm_paddr_t pa; vm_pindex_t pidx, pidx_start; int count, rc; attr =3D iomap->attr; count =3D size >> PAGE_SHIFT; pa =3D pfn << PAGE_SHIFT; pidx_start =3D OFF_TO_IDX(addr); rc =3D 0; vm_obj =3D vma->vm_obj; vma->vm_pfn_first =3D pidx_start; >>> VM_OBJECT_WLOCK(vm_obj); <<< for (pidx =3D pidx_start; pidx < pidx_start + count; pidx++, pa +=3D PAGE_SIZE) { retry: m =3D vm_page_grab(vm_obj, pidx, VM_ALLOC_NOCREAT); if (m =3D=3D NULL) { m =3D PHYS_TO_VM_PAGE(pa); if (!vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL)) goto retry; if (vm_page_insert(m, vm_obj, pidx)) { vm_page_xunbusy(m); VM_OBJECT_WUNLOCK(vm_obj); vm_wait(NULL); VM_OBJECT_WLOCK(vm_obj); goto retry; } vm_page_valid(m); } pmap_page_set_memattr(m, attr); vma->vm_pfn_count++; } VM_OBJECT_WUNLOCK(vm_obj); return (rc); } Le lun. 10 ao=C3=BBt 2020 =C3=A0 09:44, Alexandre Levy = a =C3=A9crit : > Ah thanks, I was doing a make config-recursive and that didn't show the > DEBUG option. It's recompiling the module with DEBUG now. > > Le lun. 10 ao=C3=BBt 2020 =C3=A0 09:43, Hans Petter Selasky a > =C3=A9crit : > >> On 2020-08-10 10:41, Alexandre Levy wrote: >> > I'm recompiling the kernel using GENERIC at the moment but I'm not sur= e >> how >> > to enable debugging in i915 kms, there is no compile option for that, >> am I >> > missing something ? >> >> Type: >> >> make config >> >> Before building the i915kms port, then there should be a DEBUG option >> you can select. >> >> --HPS >> > From owner-freebsd-current@freebsd.org Mon Aug 10 11:02:32 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A0B2437EBEB for ; Mon, 10 Aug 2020 11:02:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQCjM6kK5z48rX for ; Mon, 10 Aug 2020 11:02:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 31C4B260287; Mon, 10 Aug 2020 13:02:29 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> From: Hans Petter Selasky Message-ID: Date: Mon, 10 Aug 2020 13:02:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BQCjM6kK5z48rX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.05)[-1.049]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.49)[-0.494]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 11:02:32 -0000 On 2020-08-10 12:59, Alexandre Levy wrote: > I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and > I got this additional info (still no crash dump though) : If you have the debugger enabled, you will need to type "dump" in the crash handler to get the core-dump. --HPS From owner-freebsd-current@freebsd.org Mon Aug 10 11:05:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8CEB37EB4A for ; Mon, 10 Aug 2020 11:05:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQCmD0qJtz4938 for ; Mon, 10 Aug 2020 11:04:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id ABBB8260287; Mon, 10 Aug 2020 13:04:57 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> From: Hans Petter Selasky Message-ID: <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> Date: Mon, 10 Aug 2020 13:04:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BQCmD0qJtz4938 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.66)[-0.657]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 11:05:01 -0000 Hi, On 2020-08-10 12:59, Alexandre Levy wrote: > Looking at the code, the error happens during the call to VM_OBJECT_WLOCK > (memory page locking for write ?) in the intel_freebsd.c (see [1] below). > I'm out for a few days but I'll try to dig more into it when I'm back next > weekend although I have no experience in the drm-devel-kmod codebase. In > the meantime if you have any suggestions on debugging this further I'm > happy to follow them. The problem is likely that the vm_obj is NULL. I think I recall that this function is special and can only be called from a certain context, unlike in Linux. Will need the full backtrace with line numbers in order to debug this. --HPS From owner-freebsd-current@freebsd.org Mon Aug 10 16:08:25 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1AE383A6FDE for ; Mon, 10 Aug 2020 16:08:25 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BQLVJ73qTz4SPq for ; Mon, 10 Aug 2020 16:08:24 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id F0BC13A6FDD; Mon, 10 Aug 2020 16:08:24 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F08473A7411 for ; Mon, 10 Aug 2020 16:08:24 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQLVJ670fz4SdK for ; Mon, 10 Aug 2020 16:08:24 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p4fd3ae86.dip0.t-ipconnect.de [79.211.174.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 7635D15A31 for ; Mon, 10 Aug 2020 16:08:24 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 10 Aug 2020 18:08:23 +0200 From: Gordon Bergling To: current@freebsd.org Subject: installworld error (Shared object "libncursesw.so.8" not found) Message-ID: <20200810160823.GA42828@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 5:57PM up 8 days, 23:27, 5 users, load averages: 0.18, 0.22, 0.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 16:08:25 -0000 Hi, I am currently getting the following error during a "make installworld": ------------------------------------------------------------------------------- [...] ===> share/zoneinfo/tests (install) install -o root -g wheel -m 555 backward_test /usr/tests/share/zoneinfo/backward_test installing DIRS TESTFILESDIR testsFILESDIR install -d -m 0755 -o root -g wheel /usr/tests/share/zoneinfo install -o root -g wheel -m 444 /boiler/nfs/src/contrib/tzdata/backward /usr/tests/share/zoneinfo/backward install -o root -g wheel -m 444 /boiler/nfs/src/share/zoneinfo/tests/zoneinfo_common.sh /usr/tests/share/zoneinfo/zoneinfo_common.sh install -o root -g wheel -m 444 Kyuafile /usr/tests/share/zoneinfo/Kyuafile Updating /etc/localtime ld-elf.so.1: Shared object "libncursesw.so.8" not found, required by "tzsetup" *** Error code 1 Stop. make[5]: stopped in /boiler/nfs/src/share/zoneinfo *** Error code 1 *** Error code 1 *** Error code 1 *** Error code 1 Stop. make[1]: stopped in /boiler/nfs/src *** Error code 1 ------------------------------------------------------------------------------- I did a complete build with a "make clean cleandepend" before. Has anyone a hint on how to solve this error? --Gordon From owner-freebsd-current@freebsd.org Mon Aug 10 16:12:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 972633A7883 for ; Mon, 10 Aug 2020 16:12:54 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQLbT1z7fz4Srk for ; Mon, 10 Aug 2020 16:12:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi1-f176.google.com with SMTP id k4so9394679oik.2 for ; Mon, 10 Aug 2020 09:12: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:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=qwS6VK2/DQn9kQfI1hI73s9k/1OdzHBorAShZSVvTJM=; b=Ds4Gxg6Cdm1peVKYCkyLKk7mi5xD6cnJsbnLzyTyre/8bfcsoIokFeWgpEc1r5Yt5l 1wHIV8qR48K8s8H7KqfybllxN0YA7IRv5EJHeFslohN4AkjeoqH1JfhyEyNbJzm5WeDS 6Hue0jiF9WJIA2IK7fL/xsDeB3gd7/0X2o9+Q0ESUv8ilZzn/Wgvl7ksFHRTDyEw6C9U T4LQPR+VEsCZILyzVcRvylv4QftLIX8bCfNy4H1pAINw0Xe95FZwWCDKCZ3EKNoErwXs xDcKTo7VteXYYSqXMKdD1vcRTuVE6GIJHjlwB0I10+yjyzjDodsmzLPnunyLR1cIb4vS S3fA== X-Gm-Message-State: AOAM530vPcRhH8uoBGxlxJlbv+6FwbTCOlTCTKBb1gFMBMzxB+8YCOR5 Xtyp57hFQYH4rdatPXLS+LCnENAnzLU= X-Google-Smtp-Source: ABdhPJzietL3VSfkFKcX5sn/+n3CKmIK21kc1H5JLDeXLlC9K6NI1/MkwHaVkvNSf3QXRnCLz8wz9w== X-Received: by 2002:aca:4b54:: with SMTP id y81mr72116oia.54.1597075971934; Mon, 10 Aug 2020 09:12:51 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com. [209.85.210.43]) by smtp.gmail.com with ESMTPSA id j9sm3520099otn.67.2020.08.10.09.12.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 09:12:51 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id k12so7737955otr.1 for ; Mon, 10 Aug 2020 09:12:51 -0700 (PDT) X-Received: by 2002:a05:6830:1305:: with SMTP id p5mr1424082otq.135.1597075971195; Mon, 10 Aug 2020 09:12:51 -0700 (PDT) MIME-Version: 1.0 References: <0169058e-ec49-7ce0-c510-4fd071a239e8@blastwave.org> In-Reply-To: <0169058e-ec49-7ce0-c510-4fd071a239e8@blastwave.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 10 Aug 2020 09:12:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: To people upgrading from before r363679 To: Dennis Clarke Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BQLbT1z7fz4Srk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.167.176 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-1.86 / 15.00]; HAS_REPLYTO(0.00)[cem@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.11)[0.108]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.176:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.176:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 16:12:54 -0000 The problem identified in Warner's email was fixed in r364030, so an easy solution is updating from r363678 or earlier directly to r364030 or later. Best, Conrad On Mon, Aug 10, 2020 at 3:20 AM Dennis Clarke wrote: > > On 8/5/20 9:19 PM, Warner Losh wrote: > > If you are upgrading across r363679, you may have installworld fail, as > > documented in UPDATING. > > > > I have a fix (that requires a trip through buildworld) that's under review > > at https://reviews.freebsd.org/D25967 . The changes are likely good, but > > comments likely need updating. > > > > The short version is that we purposely use old libraries to install the > > system. We created a symbolic link to a bunch of binaries on the system and > > once installworld installs one of them, we get the error. The workaround > > works because we copy libc.so before doing the installworld, so now we're > > running with a new libc.so with new binaries, which works. My fix always > > copies and never symlinks. The symbolic link stuff is too fragile. > > > > With it, I've done one system, but I'd appreciate reports (on the code > > review if possible, to me in email if not) of people who have success > > upgrading with this. If you've already run installworld and hit the > > undefined symbol, it's too late for you to help me test (since re-running > > is the same as hitting to test is the same as the workaround and so it will > > work even if my workaround is busted). > > > > Some history: This was introduced about 2 years ago. Prior to that, we > > always copied binaries for the install. > > This will fix the situation : > > triton$ > triton$ cat /usr/src/my.patch > ... From owner-freebsd-current@freebsd.org Mon Aug 10 19:03:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F2483AC83B; Mon, 10 Aug 2020 19:03:19 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQQN73l99z4h7h; Mon, 10 Aug 2020 19:03:19 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 6C2D46D49; Mon, 10 Aug 2020 19:03:19 +0000 (UTC) Date: Mon, 10 Aug 2020 19:03:19 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-08-09 Message-ID: <20200810190319.GA45063@freefall.freebsd.org> Reply-To: freebsd-testing@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.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:03:19 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-08-09 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-08-02 to 2020-08-09. During this period, we have: * 1823 builds (94.0% (-1.4) passed, 6.0% (+1.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 193 test runs (96.4% (+27.4) passed, 3.1% (-26.9) unstable, 0.5% (-0.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 28 doc and www builds (100% (+0.0) passed) Test case status (on 2020-08-09 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ------ | -------- | | head/amd64 | 7874 (+2) | 7784 (+3) | 0 (-1) | 90 (0) | | head/i386 | 7872 (+2) | 7772 (0) | 0 (-1) | 100 (+3) | | 12-STABLE/amd64 | 7620 (+1) | 7560 (-2) | 0 (0) | 60 (+3) | | 12-STABLE/i386 | 7618 (+1) | 7550 (-2) | 0 (0) | 68 (+3) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6854 (0) | 0 (0) | 56 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200809 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ Patches to fix (partially): https://reviews.freebsd.org/D25953 https://reviews.freebsd.org/D25954 ## Fixed cases * lib.googletest.gtest_main.googletest-port-test.main https://svnweb.freebsd.org/changeset/base/363821 ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/ ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 ## Issues ### Cause build fails * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 Fixed in head in https://svnweb.freebsd.org/changeset/base/363361 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Tue Aug 11 03:10:43 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 07B963B6B27 for ; Tue, 11 Aug 2020 03:10:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660087.outbound.protection.outlook.com [40.107.66.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BQdBV0hh5z3dtQ for ; Tue, 11 Aug 2020 03:10:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GBcyeULdbuH2QitZQcJOAOVoPZx5nAb6/UUuk6QLKoSqqZ1vK9a+/epuEO7DPRZrCx4YQWXYDLTviHW3uCc3gIPjq/jl6/64b1f3KuwbAXsvhLuO/kYcwJKPEcxIlRejtkM6eH1wYKLogqNDDNF1UTIJKU8e3grgOiXMb2TlvIY8RolplXQv/sktIi2M+FhO6ESG3ovv6vBKB3ZTl/M4i5JrOWR5aTOv70VaBjRHVoUawcCcwMZMZ5Va0CFrd4GhvsBAR4MiF+sT5mzJphddfxuDsOgm8NQFw74iK9qBxsmpc7YrEkAJDJ4FTk3z3kvhu/t40za9Ezgo/m2iOgsXWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L4jPcyQtQ7MlpZWRhkgUBpf+ucphztEMeJS6OBBCFos=; b=FNXyploTICOsy11Qmid3PSiBRzBcDCKntiYC/TEIydBsIgRrVpswdBVxlKCyvY0jKtOzMZBLWULZ/FJ9xaopSe727ubfMqXK7HiLmZ7bT09BrRhvDtU95iqyxMrEc+yCfc/cP0G6V87kp4Rgzq4rAFBuVqMqBHoUeA82uP7tkeKxOFaAUBH6mQYw9oCiRGKKxKaZyLt9csL1VNHublpdiSutjjXbx66eh+NKrtv1ZyaQbwHvH2ms7YIZRXxyFqZ/75vCEHG4fqXPlz4aQOw9OYat92TrtzF1N6ivKGgvmVq8AXNH1nEUqhOkMMwJAOcAsv0P4cThy+mYyCa+lTzdGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L4jPcyQtQ7MlpZWRhkgUBpf+ucphztEMeJS6OBBCFos=; b=Z02JvtQniXMIHqD7TMNa2UHeCP2h6ECpf6r8hc/rMUBllKtFexJ5cJZXLH1Rjhg8KJVm30Ch7LIki/yMeDGPBCFZu1scJSTFoi3eRfBrwCwYNKmnNFAqrhN1JNhrOILT18XkfgGov/0yXIVKOBggdNEqhRFf/v57I4gSWnPg41stNPO3d1YOPWC7tqyB/4CGDhL0bvgFDNSFVCVBooCOJNPCuF4pSGf5qIn6gMqr8ZEDN57YmxxD2/Poxy43OyzmkhMmlKiriG+kiEvLicpcpjYj8l4xgrMiiSFhu55eJ33FMyWCRAjx14qmc07l6VYQcVZ8L3XqB8vh8Q1yQX45IQ== Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:38::14) by YQXPR0101MB0840.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:25::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Tue, 11 Aug 2020 03:10:40 +0000 Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::e89a:a655:91ca:4e63]) by QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::e89a:a655:91ca:4e63%5]) with mapi id 15.20.3261.024; Tue, 11 Aug 2020 03:10:39 +0000 From: Rick Macklem To: Konstantin Belousov CC: Kirk McKusick , "freebsd-current@FreeBSD.org" Subject: Re: can buffer cache pages be used in ext_pgs mbufs? Thread-Topic: can buffer cache pages be used in ext_pgs mbufs? Thread-Index: AQHWbT5NsHegiwo1zUiUbiF8t3J50KkuSUkAgAIrdK6AASLqAIAAoXdL Date: Tue, 11 Aug 2020 03:10:39 +0000 Message-ID: References: <202008080443.0784hEfh084650@chez.mckusick.com> <20200808144040.GD2551@kib.kiev.ua> , <20200810170956.GL2551@kib.kiev.ua> In-Reply-To: <20200810170956.GL2551@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 758a1a16-9035-43ba-4693-08d83da4205c x-ms-traffictypediagnostic: YQXPR0101MB0840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G6lkPFmideJclRO+7dIK0tqXwfOZPl/q3XMT3vqPIW7jPyW1aaEwa5/B5mviOAVFXPnWWiLhkhnDjUw1xF6TE1rzLIB0A++XTe8eAy5Qv+seU4Z1aOiAd2InilTdyuhfY6gMmSsyGZQu2H0cPiUpzz3CfJIMul/6/WRWYBIXBEH2E72ht792DEEp8DhJ8RWr9b3ioRhVfesJB8yjSDakTDWKoKtrbnt2t0S4/2Yl66+fcS2aULcIHsOTOEJH04jS/HAk61TEmVA3q57iy/jOGoN3wj4t4EEUvb/Fwp065bfkNLk8kBCjTzBbFoIcPzI4EQ4kY7HLxT3xlsN6lnv/cw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(396003)(136003)(366004)(346002)(376002)(786003)(6916009)(316002)(2906002)(7696005)(6506007)(186003)(478600001)(54906003)(9686003)(55016002)(5660300002)(52536014)(4326008)(8676002)(71200400001)(91956017)(33656002)(83380400001)(8936002)(66476007)(76116006)(64756008)(66946007)(86362001)(66556008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YCDG6e7aqSAcjsymMT0StevnvKbkuExm3jZ0x6JuX55iG59sQT9nRswwREVwp2BYjNQGexI+k/isBrp0l8NS+UKRNLkHi3BUaBL8/bNPlulmCyNFDpfrR4ORS0vR0OaE/Q0sWGgo3AbhLVZBUF9oWEf61Fk0Fq1mWtRA1QxwZyeUjtw5KOK5ofMGNZ8bSIa5qNFjDz6AKw6pi2QiqKKW8dmc0Cm6YNDQr/0e/OOnq7rsLxkiuECfkr5r54lBZ15QWoVbeYpQTuew7mJB+RhrhjtwpaFR2snfz8cFxTpV+KeFJxcIcfjSCn8aVjp84GuXmu7KZ9XVb6Z0yr5h0lgwas8AaXP/MbeWnstwvya8fij+3fJDR5DPX6BsV76Z0PBc9B5EWwfBx8bvQaGnXFDNQYY7r+6xPPYRN6aiRgk9WOZv2Y47t3mQRoEJunAZXaCyL8Ri4+9D24FBDlTGHOr2BFuA2/c1nUvNudql87yWA+VegUUL2p6ys88TqNnvgCjPCjD3d+/QOZ+HHDdsf5LciGCI4wbRsCep5b2Y90t25z66es3JoLstm97sZnMd92cVw0KKC921/131q5Yqs/uJJX7Qx457Haag98xjt2s9leFdkSqx7EabkYkTla7gIY6WsXBr3e9JcFWSTROo90s+sV3/sOZyduhmFI6oMvXIVW5vdgdXtiqcftIiT8ywej8IPzsDDcifNsbsZYlYGjGkBQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 758a1a16-9035-43ba-4693-08d83da4205c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 03:10:39.8215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pJqgRS1zP2pH6ul8R2q9gxexqdm5022taOJ+c+K6/gwfc5QmAzMgdeskOu3NQtynfwKaaC00w9x6WsKrWg4oSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB0840 X-Rspamd-Queue-Id: 4BQdBV0hh5z3dtQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=Z02JvtQn; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.87 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.32 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.008]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-0.99)[-0.995]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-0.82)[-0.818]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.87:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.87:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 03:10:43 -0000 Konstantin Belousov wrote:=0A= >On Mon, Aug 10, 2020 at 12:46:00AM +0000, Rick Macklem wrote:=0A= >> Konstantin Belousov wrote:=0A= >> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote:=0A= >> >> I do not have the answer to your question, but I am copying Kostik=0A= >> >> as if anyone knows the answer, it is probably him.=0A= >> >>=0A= >> >> ~Kirk=0A= >> >>=0A= >> >> =3D-=3D-=3D=0A= >> >I do not know the exact answer, this is why I did not followed up on th= e=0A= >> >original question on current@. In particular, I have no idea about the= =0A= >> >ext_pgs mechanism.=0A= >> >=0A= >> >Still I can point one semi-obvious aspect of your proposal.=0A= >> >=0A= >> >When the buffer is written (with bwrite()), its pages are sbusied and= =0A= >> >the write mappings of them are invalidated. The end effect is that no= =0A= >> >modifications to the pages are possible until they are unbusied. This,= =0A= >> >together with the lock of the buffer that holds the pages, effectively= =0A= >> >stops all writes either through write(2) or by mmaped regions.=0A= >> >=0A= >> >In other words, any access for write to the range of file designated by= =0A= >> >the buffer, causes the thread to block until the pages are unbusied and= =0A= >> >the buffer is unlocked. Which in described case would mean, until NFS= =0A= >> >server responds.=0A= >> >=0A= >> >If this is fine, then ok.=0A= >> For what I am thinking of, I would say that is fine, since the ktls code= reads=0A= >> the pages to encrypt/send them, but can use other allocated pages for=0A= >> the encrypted data.=0A= >>=0A= >> >Rick, do you know anything about the vm page lifecycle as mb_ext_pgs ?= =0A= >> Well, the anonymous pages (the only ones I've been using sofar) are=0A= >> allocated with:=0A= >> vm_page_alloc(NULL, 0, VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ |=0A= >> VM_ALLOC_NODUMP | VM_ALLOC_WIRED);=0A= >>=0A= >> and then the m_ext_ext_free function (mb_free_mext_pgs()) does:=0A= >> vm_page_unwire_noq(pg);=0A= >> vm_page_free(pg);=0A= >> on each of them.=0A= >>=0A= >> m->m_ext_ext_free() is called in tls_encrypt() when it no longer wants t= he=0A= >> pages, but is normally called via m_free(m), which calls mb_free_extpg(m= ),=0A= >> although there are a few other places.=0A= >>=0A= >> Since m_ext_ext_free is whatever function you want to make it, I suppose= the=0A= >> answer is "until your m_ext.ext_free" function is called.=0A= >>=0A= >> At this time, for ktls, if you are using software encryption, the call t= o ktls_encrypt(),=0A= >> which is done before passing the mbufs down to TCP is when it is done wi= th the=0A= >> unencrypted data pages. (I suppose there is no absolute guarantee that t= his=0A= >> happens before the kernel RPC layer times out waiting for an RPC reply, = but it=0A= >> is almost inconceivable, since this happens before the RPC request is pa= ssed=0A= >> down to TCP.)=0A= >>=0A= >> The case I now think is more problematic is the "hardware assist" case. = Although=0A= >> no hardware/driver yet does this afaik, I suspect that the unencrypted d= ata page=0A= >> mbufs could end up stuck in TCP for a long time, in case a retransmit is= needed.=0A= >>=0A= >> So, I now think I might need to delay the bufdone() call until the m_ext= _ext_free()=0A= >> call has been done for the pages, if they are buffer cache pages?=0A= >> --> Usually I would expect the m_ext_ext_free() call for the mbuf(s) tha= t=0A= >> hold the data to be written to the server to be done long before= =0A= >> bufdone() would be called for the buffer that is being written,= =0A= >> but there is no guarantee.=0A= >>=0A= >> Am I correct in assuming that the pages for the buffer will remain valid= and=0A= >> readable through the direct map until bufdone() is called?=0A= >> If I am correct w.r.t. this, it should work so long as the m_ext_ext_fre= e() calls=0A= >> for the pages happen before the bufdone() call on the bp, I think?=0A= >=0A= >I think there is further complication with non-anonymous pages.=0A= >You want (or perhaps need) the page content to be immutable and not=0A= >changed while you pass pages around and give the for ktls sw or hw=0A= >processing. Otherwise it could not pass the TLS authentification if=0A= >page was changed in process.=0A= >=0A= >Similar issue exists when normal buffer writes are scheduled through=0A= >the strategy(), and you can see that bufwrite() does vfs_busy_pages()=0A= >with clear_modify=3D1, which does two things:=0A= >- sbusy the pages (sbusy pages can get new read-only mappings, but cannot= =0A= > be mapped rw)=0A= >- pmap_remove_write() on the pages to invalidate all current writeable=0A= > mappings.=0A= >=0A= >This state should be kept until ktls is completely done with the pages.=0A= I am now thinking that this is done exactly as you describe above and=0A= doesn't require any changes.=0A= =0A= The change I am planning is below the strategy routine in the function=0A= that does the write RPC.=0A= It currently copies the data from the buffer into mbuf clusters.=0A= After this change, it would put the physical page #s for the buffer in the= =0A= mbuf(s) and then wait for them all to be m_ext_ext_free()d before calling= =0A= bufdone().=0A= --> The only difference is the wait before the bufdone() call in the RPC la= yer=0A= below the strategy routine. (bufdone() is the only call the NFS clie= nt=0A= seems to do below the strategy routine, so I assume it ends the stat= e=0A= you describe above?)=0A= =0A= rick=0A= =0A= =0A= =0A= From owner-freebsd-current@freebsd.org Tue Aug 11 17:54:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A2FA93B3ADA for ; Tue, 11 Aug 2020 17:54:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BR0pG3Mskz3b3s for ; Tue, 11 Aug 2020 17:54:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 07BHsMkb059251 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Aug 2020 20:54:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 07BHsMkb059251 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 07BHsM7v059250; Tue, 11 Aug 2020 20:54:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Aug 2020 20:54:22 +0300 From: Konstantin Belousov To: Rick Macklem Cc: Kirk McKusick , "freebsd-current@FreeBSD.org" Subject: Re: can buffer cache pages be used in ext_pgs mbufs? Message-ID: <20200811175422.GP2551@kib.kiev.ua> References: <202008080443.0784hEfh084650@chez.mckusick.com> <20200808144040.GD2551@kib.kiev.ua> <20200810170956.GL2551@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BR0pG3Mskz3b3s X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.01 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.25)[-0.247]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-0.82)[-0.821]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(0.06)[0.062]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 17:54:31 -0000 On Tue, Aug 11, 2020 at 03:10:39AM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Mon, Aug 10, 2020 at 12:46:00AM +0000, Rick Macklem wrote: > >> Konstantin Belousov wrote: > >> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote: > >> >> I do not have the answer to your question, but I am copying Kostik > >> >> as if anyone knows the answer, it is probably him. > >> >> > >> >> ~Kirk > >> >> > >> >> =-=-= > >> >I do not know the exact answer, this is why I did not followed up on the > >> >original question on current@. In particular, I have no idea about the > >> >ext_pgs mechanism. > >> > > >> >Still I can point one semi-obvious aspect of your proposal. > >> > > >> >When the buffer is written (with bwrite()), its pages are sbusied and > >> >the write mappings of them are invalidated. The end effect is that no > >> >modifications to the pages are possible until they are unbusied. This, > >> >together with the lock of the buffer that holds the pages, effectively > >> >stops all writes either through write(2) or by mmaped regions. > >> > > >> >In other words, any access for write to the range of file designated by > >> >the buffer, causes the thread to block until the pages are unbusied and > >> >the buffer is unlocked. Which in described case would mean, until NFS > >> >server responds. > >> > > >> >If this is fine, then ok. > >> For what I am thinking of, I would say that is fine, since the ktls code reads > >> the pages to encrypt/send them, but can use other allocated pages for > >> the encrypted data. > >> > >> >Rick, do you know anything about the vm page lifecycle as mb_ext_pgs ? > >> Well, the anonymous pages (the only ones I've been using sofar) are > >> allocated with: > >> vm_page_alloc(NULL, 0, VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ | > >> VM_ALLOC_NODUMP | VM_ALLOC_WIRED); > >> > >> and then the m_ext_ext_free function (mb_free_mext_pgs()) does: > >> vm_page_unwire_noq(pg); > >> vm_page_free(pg); > >> on each of them. > >> > >> m->m_ext_ext_free() is called in tls_encrypt() when it no longer wants the > >> pages, but is normally called via m_free(m), which calls mb_free_extpg(m), > >> although there are a few other places. > >> > >> Since m_ext_ext_free is whatever function you want to make it, I suppose the > >> answer is "until your m_ext.ext_free" function is called. > >> > >> At this time, for ktls, if you are using software encryption, the call to ktls_encrypt(), > >> which is done before passing the mbufs down to TCP is when it is done with the > >> unencrypted data pages. (I suppose there is no absolute guarantee that this > >> happens before the kernel RPC layer times out waiting for an RPC reply, but it > >> is almost inconceivable, since this happens before the RPC request is passed > >> down to TCP.) > >> > >> The case I now think is more problematic is the "hardware assist" case. Although > >> no hardware/driver yet does this afaik, I suspect that the unencrypted data page > >> mbufs could end up stuck in TCP for a long time, in case a retransmit is needed. > >> > >> So, I now think I might need to delay the bufdone() call until the m_ext_ext_free() > >> call has been done for the pages, if they are buffer cache pages? > >> --> Usually I would expect the m_ext_ext_free() call for the mbuf(s) that > >> hold the data to be written to the server to be done long before > >> bufdone() would be called for the buffer that is being written, > >> but there is no guarantee. > >> > >> Am I correct in assuming that the pages for the buffer will remain valid and > >> readable through the direct map until bufdone() is called? > >> If I am correct w.r.t. this, it should work so long as the m_ext_ext_free() calls > >> for the pages happen before the bufdone() call on the bp, I think? > > > >I think there is further complication with non-anonymous pages. > >You want (or perhaps need) the page content to be immutable and not > >changed while you pass pages around and give the for ktls sw or hw > >processing. Otherwise it could not pass the TLS authentification if > >page was changed in process. > > > >Similar issue exists when normal buffer writes are scheduled through > >the strategy(), and you can see that bufwrite() does vfs_busy_pages() > >with clear_modify=1, which does two things: > >- sbusy the pages (sbusy pages can get new read-only mappings, but cannot > > be mapped rw) > >- pmap_remove_write() on the pages to invalidate all current writeable > > mappings. > > > >This state should be kept until ktls is completely done with the pages. > I am now thinking that this is done exactly as you describe above and > doesn't require any changes. > > The change I am planning is below the strategy routine in the function > that does the write RPC. > It currently copies the data from the buffer into mbuf clusters. > After this change, it would put the physical page #s for the buffer in the > mbuf(s) and then wait for them all to be m_ext_ext_free()d before calling > bufdone(). > --> The only difference is the wait before the bufdone() call in the RPC layer > below the strategy routine. (bufdone() is the only call the NFS client > seems to do below the strategy routine, so I assume it ends the state > you describe above?) > As far as pages are put into mbuf clusters only after bwrite() that did vfs_busy_pages(), and bufdone() is called not earlier than network finished with the mbufs, it should be ok. From owner-freebsd-current@freebsd.org Wed Aug 12 22:23:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 928073AC881 for ; Wed, 12 Aug 2020 22:23:46 +0000 (UTC) (envelope-from justfly1111@icloud.com) Received: from st43p00im-zteg10062001.me.com (st43p00im-zteg10062001.me.com [17.58.63.166]) (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 4BRkkT6dSTz4ShS for ; Wed, 12 Aug 2020 22:23:45 +0000 (UTC) (envelope-from justfly1111@icloud.com) Received: from charmander.justfly.live (unknown [73.61.234.255]) by st43p00im-zteg10062001.me.com (Postfix) with ESMTPSA id 809DD6C0848 for ; Wed, 12 Aug 2020 22:23:44 +0000 (UTC) To: freebsd-current@freebsd.org From: Eleven Eleven Subject: ANyon else having any iiiisvenafter recompiling Message-ID: Date: Wed, 12 Aug 2020 18:23:43 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-12_19:2020-08-11, 2020-08-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=676 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2008120143 X-Rspamd-Queue-Id: 4BRkkT6dSTz4ShS X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[icloud.com]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[icloud.com:+]; DMARC_POLICY_ALLOW(-0.50)[icloud.com,quarantine]; NEURAL_HAM_SHORT(-0.62)[-0.622]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[icloud.com]; ASN(0.00)[asn:714, ipnet:17.58.63.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.63.166:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; R_DKIM_ALLOW(-0.20)[icloud.com:s=1a1hai]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.019]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[icloud.com:dkim]; WHITELIST_SPF_DKIM(-3.00)[icloud.com:d:+,icloud.com:s:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.63.166:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 22:23:46 -0000 Oy so i noticed 13 qwas runnig slow nd saw in UPDATing abou rebuilding wih malloc_production and no debug so I rebuilt my world lib c and keeerel with out anny debugging options and now it seems liktttttttttsystem is still laging but even slowerr the point wheree either itll either pint muiple letters on one key press or itll not print anythng for 3-4 letters then continue. anyone else experienne types ofissuesss if so anne have any deasss  fix im running amd64 on a 2013 mac pro with 12 core ad 128 gigs of ram andfor swap i hhhhhhae a 100gig zvol and also anothr 240gig ssd drive used as swap  in an atteempt trydx his isssstini it may be from  mry pleassssse bear wy attrosh messae its due to the probles outlineeeeeeeed above tnk yu so muuuuuuuuuuuch your tme is extrmely apprecia thank you From owner-freebsd-current@freebsd.org Fri Aug 14 05:54:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA7833B54DE for ; Fri, 14 Aug 2020 05:54:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660053.outbound.protection.outlook.com [40.107.66.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BSXh23JTgz4HFq for ; Fri, 14 Aug 2020 05:54:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BWGd8QQKfxmnQd94C8zDFh8QXw5Zr5F1ltLFuJ2k+LnvGqjD/GIdy65eai3luTBG/+9AYUjxalQVem7AfolFU0yTp3Ro6XKukOj2Ui755tVo2YBBNYYKdzv1axooi73WMTCWFSI1AxCBMhnTZ+aqZfDedC0dwpIaRQH3jPEtJ+UuGW1zPXCoyuh5T7AxuNoLf8NG76U4geVQJZAul8ObLY7wdTe5MHpNEgFK2DlVkm0IWe4zNJ3/gR06IVw5NyyeEP3YLECCW5tveoaxb3LDNlwou/haBF/M/QVV+aXIwIza5/93eneHsdIKuUYHSF5DIq8hUSFwhA2+l185TM915w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JKWszosgS9s5D/8+RIKroPUaCRxCN3DEFbjrOlifdqo=; b=mzRyofsjtBvvY4ZUrgeUUih5sl2850vmyIe3XrTtffTxeyqQMIsVUh3+b7tOjWJ1GFEg2XEIy4QGQPO9Fa+PRnyqn8l9lxTIJ4wfB+kd6cDrwrabFt/2K2vhDXoDSDq5TCixuCOvbECG5W+4R/rL57SHDdy2XH8fIjOtFX3h/+lk6BqdaoLHjXowfp8QyDLvbALr011h+IpT/1VMdga0X6XbzeulUSXw/kbrOGs6qQvBd9dr33RgFrkk5/RJswlw+SyWXqh0s/W5fRni64RQQbeFXTydgmA0jgkwgZYtbi0Ib1PFq43WRu2AeiyRXSYry2TeWkRB0Lyo8CUu20azIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JKWszosgS9s5D/8+RIKroPUaCRxCN3DEFbjrOlifdqo=; b=H9YdGmR+FKWapFykBAsb8CkQLB0cSkE9zsydpD2PBggfbAXGq+/i3aSlcAnYh3mmITmxuMttzEQyQMduI/xsavtuDug9+3VwrScVOGukLWEGYBtlM9bcWxicoWwe62HNH/VOCug/1abqBvRjO58m86PPTEOgSpLFkAxpxZc8BORcZm0YRRq5izkaqjqS6WFyp9NIwbJSImj3OBmg9XClfwX7ZiJBWMyjMoPkKpjMJhG/ldA5hvXrd5AeeClBUld28D9PL0YvyFBemao3kcq5UDG/Iq+fj1T7VzZrWIhYpMI4i9RSDx60258c/mcSfHjRiiv1YFAFVVf8bBJPF/yZ5Q== Received: from YTBPR01MB3375.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1e::27) by YTOPR0101MB1675.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Fri, 14 Aug 2020 05:54:24 +0000 Received: from YTBPR01MB3375.CANPRD01.PROD.OUTLOOK.COM ([fe80::a8ee:601d:f368:a052]) by YTBPR01MB3375.CANPRD01.PROD.OUTLOOK.COM ([fe80::a8ee:601d:f368:a052%7]) with mapi id 15.20.3283.015; Fri, 14 Aug 2020 05:54:24 +0000 From: Rick Macklem To: Konstantin Belousov CC: Kirk McKusick , "freebsd-current@FreeBSD.org" Subject: Re: can buffer cache pages be used in ext_pgs mbufs? Thread-Topic: can buffer cache pages be used in ext_pgs mbufs? Thread-Index: AQHWbT5NsHegiwo1zUiUbiF8t3J50KkuSUkAgAIrdK6AASLqAIAAoXdLgAD9SACAA+uViA== Date: Fri, 14 Aug 2020 05:54:23 +0000 Message-ID: References: <202008080443.0784hEfh084650@chez.mckusick.com> <20200808144040.GD2551@kib.kiev.ua> <20200810170956.GL2551@kib.kiev.ua> , <20200811175422.GP2551@kib.kiev.ua> In-Reply-To: <20200811175422.GP2551@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46573605-cafc-4c92-7e5c-08d840167f34 x-ms-traffictypediagnostic: YTOPR0101MB1675: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9zhNRBzoIw1F4vgz/e8m+29AEMN94zBQGhoB4dpDl17nSB8BXwptWEiKujKWzlUjevAZ9rWGrARko0U+OPaKvNCTjNoqvTT5AiT/3L5rS5mzXJrpfPMS9XX/ttn/P1BMQVuDrSCUnzoAARiG2/PQyF1n+dWatO5EWE1Nrq92ewg2mMhxPmCkMrsoksuVD6oHRkPSYQmQG/AN9P5+S3Pb0b9XefZxlHKiFnyCNCnOblK/bdN5S3T3giNark8ifddrf4cRiTNeqGJhTjics3NVxYwYH/fsfNuBQ5NTv1KAHkxeYpgjYA57mSoXKxL7YjGp3s/ucC3sVkm7zfMisNQ5Ag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3375.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(396003)(39860400002)(366004)(346002)(376002)(136003)(4326008)(786003)(33656002)(9686003)(6916009)(316002)(55016002)(2906002)(186003)(54906003)(6506007)(86362001)(8936002)(478600001)(64756008)(66476007)(76116006)(91956017)(8676002)(5660300002)(52536014)(83380400001)(7696005)(66946007)(66446008)(66556008)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Lgp1g3sMXAZUdy3YQTEsFCjRndfE59u1CBlWYVlbCQuDRbTO+28sImtiqojUhicFrD42hxQrpI9SfMq1YQovCuSSdfr3CETCmRI/r0qLYdTbXYB04/ENt8Tlx0rOSEdE8AAyUGOxJ69c2gEAnzrerBugdUeV7170x2f263BTmvr+9P4VCFkojPDsmINtS4s7f/w8VVJiszDHBWNr49xNam+34OIRbKMxw8TL395CXeE8z658oiPqEmteXzLJmQtoNf5ci2OwlIlWuKnUNFiJxxBwgIZSvHAJ6YEHfQi4Fsarpi79nIL23EB+qHZhwr6p1A+XDjmkl0ogWS96ye8cwBuUWijiN5HqI5LI/gABLx3Ofvlc0aXaAIAGo5NaheX8Q4ko1y4ppda+qSr9HhaNSsQUvNuCqkHkfD5D8Q1DQwoYnUDejwDNQJYKGaxW5yu8TE3+BW730cOSlKcybxPco9ESbfTDCBOlW1lu8jWmSCpM/m5MG+/TWl+Ns6Jn56H+YcfLo7pZ7uarciu2MmtnY/z1LPaqPtzy355jhhnKFkk0c7xJ1kHGmnsGA4wgZ5iWqY7nAV2lTnD6TtbSwjrc4B3+/RM/WTdNF2M6XbdWGMNuXHdQOh8NOFpiSCeVXvKXjE6bqHuHbDAuN1TKDdcwFXV2SaJWFFc6DspLUFd4Q6amHzr7N2z5yovIg4wO3ZslODXaIdQfveKL5ws/g3HPWQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3375.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 46573605-cafc-4c92-7e5c-08d840167f34 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 05:54:23.9180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MlxXEVK91wYLAjkkur6WBfc2SHV60pril84WG8RYrYIzEGiG4pazITyPV1wsk60OF0cTZ2DX6N47vqMilwdkyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1675 X-Rspamd-Queue-Id: 4BSXh23JTgz4HFq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=H9YdGmR+; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.53 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.48 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.02)[-1.016]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-0.97)[-0.967]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.53:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.53:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 05:54:28 -0000 Konstantin Belousov wrote:=0A= >On Tue, Aug 11, 2020 at 03:10:39AM +0000, Rick Macklem wrote:=0A= >> Konstantin Belousov wrote:=0A= >> >On Mon, Aug 10, 2020 at 12:46:00AM +0000, Rick Macklem wrote:=0A= >> >> Konstantin Belousov wrote:=0A= >> >> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote:=0A= >> >> >> I do not have the answer to your question, but I am copying Kostik= =0A= >> >> >> as if anyone knows the answer, it is probably him.=0A= >> >> >>=0A= >> >> >> ~Kirk=0A= >> >> >>=0A= >> >> >> =3D-=3D-=3D=0A= >> >> >I do not know the exact answer, this is why I did not followed up on= the=0A= >> >> >original question on current@. In particular, I have no idea about = the=0A= >> >> >ext_pgs mechanism.=0A= >> >> >=0A= >> >> >Still I can point one semi-obvious aspect of your proposal.=0A= >> >> >=0A= >> >> >When the buffer is written (with bwrite()), its pages are sbusied an= d=0A= >> >> >the write mappings of them are invalidated. The end effect is that n= o=0A= >> >> >modifications to the pages are possible until they are unbusied. Thi= s,=0A= >> >> >together with the lock of the buffer that holds the pages, effective= ly=0A= >> >> >stops all writes either through write(2) or by mmaped regions.=0A= >> >> >=0A= >> >> >In other words, any access for write to the range of file designated= by=0A= >> >> >the buffer, causes the thread to block until the pages are unbusied = and=0A= >> >> >the buffer is unlocked. Which in described case would mean, until N= FS=0A= >> >> >server responds.=0A= >> >> >=0A= >> >> >If this is fine, then ok.=0A= >> >> For what I am thinking of, I would say that is fine, since the ktls c= ode reads=0A= >> >> the pages to encrypt/send them, but can use other allocated pages for= =0A= >> >> the encrypted data.=0A= >> >>=0A= >> >> >Rick, do you know anything about the vm page lifecycle as mb_ext_pgs= ?=0A= >> >> Well, the anonymous pages (the only ones I've been using sofar) are= =0A= >> >> allocated with:=0A= >> >> vm_page_alloc(NULL, 0, VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ |=0A= >> >> VM_ALLOC_NODUMP | VM_ALLOC_WIRED);=0A= >> >>=0A= >> >> and then the m_ext_ext_free function (mb_free_mext_pgs()) does:=0A= >> >> vm_page_unwire_noq(pg);=0A= >> >> vm_page_free(pg);=0A= >> >> on each of them.=0A= >> >>=0A= >> >> m->m_ext_ext_free() is called in tls_encrypt() when it no longer want= s the=0A= >> >> pages, but is normally called via m_free(m), which calls mb_free_extp= g(m),=0A= >> >> although there are a few other places.=0A= >> >>=0A= >> >> Since m_ext_ext_free is whatever function you want to make it, I supp= ose the=0A= >> >> answer is "until your m_ext.ext_free" function is called.=0A= >> >>=0A= >> >> At this time, for ktls, if you are using software encryption, the cal= l to ktls_encrypt(),=0A= >> >> which is done before passing the mbufs down to TCP is when it is done= with the=0A= >> >> unencrypted data pages. (I suppose there is no absolute guarantee tha= t this=0A= >> >> happens before the kernel RPC layer times out waiting for an RPC repl= y, but it=0A= >> >> is almost inconceivable, since this happens before the RPC request is= passed=0A= >> >> down to TCP.)=0A= >> >>=0A= >> >> The case I now think is more problematic is the "hardware assist" cas= e. Although=0A= >> >> no hardware/driver yet does this afaik, I suspect that the unencrypte= d data page=0A= >> >> mbufs could end up stuck in TCP for a long time, in case a retransmit= is needed.=0A= >> >>=0A= >> >> So, I now think I might need to delay the bufdone() call until the m_= ext_ext_free()=0A= >> >> call has been done for the pages, if they are buffer cache pages?=0A= >> >> --> Usually I would expect the m_ext_ext_free() call for the mbuf(s) = that=0A= >> >> hold the data to be written to the server to be done long befo= re=0A= >> >> bufdone() would be called for the buffer that is being written= ,=0A= >> >> but there is no guarantee.=0A= >> >>=0A= >> >> Am I correct in assuming that the pages for the buffer will remain va= lid and=0A= >> >> readable through the direct map until bufdone() is called?=0A= >> >> If I am correct w.r.t. this, it should work so long as the m_ext_ext_= free() calls=0A= >> >> for the pages happen before the bufdone() call on the bp, I think?=0A= >> >=0A= >> >I think there is further complication with non-anonymous pages.=0A= >> >You want (or perhaps need) the page content to be immutable and not=0A= >> >changed while you pass pages around and give the for ktls sw or hw=0A= >> >processing. Otherwise it could not pass the TLS authentification if=0A= >> >page was changed in process.=0A= >> >=0A= >> >Similar issue exists when normal buffer writes are scheduled through=0A= >> >the strategy(), and you can see that bufwrite() does vfs_busy_pages()= =0A= >> >with clear_modify=3D1, which does two things:=0A= >> >- sbusy the pages (sbusy pages can get new read-only mappings, but cann= ot=0A= >> > be mapped rw)=0A= >> >- pmap_remove_write() on the pages to invalidate all current writeable= =0A= >> > mappings.=0A= >> >=0A= >> >This state should be kept until ktls is completely done with the pages.= =0A= >> I am now thinking that this is done exactly as you describe above and=0A= >> doesn't require any changes.=0A= >>=0A= >> The change I am planning is below the strategy routine in the function= =0A= >> that does the write RPC.=0A= >> It currently copies the data from the buffer into mbuf clusters.=0A= >> After this change, it would put the physical page #s for the buffer in t= he=0A= >> mbuf(s) and then wait for them all to be m_ext_ext_free()d before callin= g=0A= >> bufdone().=0A= >> --> The only difference is the wait before the bufdone() call in the RPC= layer=0A= >> below the strategy routine. (bufdone() is the only call the NFS c= lient=0A= >> seems to do below the strategy routine, so I assume it ends the s= tate=0A= >> you describe above?)=0A= >>=0A= >As far as pages are put into mbuf clusters only after bwrite() that=0A= >did vfs_busy_pages(), and bufdone() is called not earlier than network=0A= >finished with the mbufs, it should be ok.=0A= I've coded it up and, at least for a little testing sofar, it seems to work= ok.=0A= =0A= Thanks for your comments, rick=0A= From owner-freebsd-current@freebsd.org Sat Aug 15 11:24:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B47AD3B5EE8 for ; Sat, 15 Aug 2020 11:24:52 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BTHyr1k8Gz3gsl for ; Sat, 15 Aug 2020 11:24:52 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.nyi.freebsd.org (Postfix) id 3974E3B5FDA; Sat, 15 Aug 2020 11:24:52 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 391DF3B5E4B; Sat, 15 Aug 2020 11:24:52 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500j.mail.yandex.net (forward500j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::110]) (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 4BTHyn6TMtz3gf7; Sat, 15 Aug 2020 11:24:49 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback9q.mail.yandex.net (mxback9q.mail.yandex.net [IPv6:2a02:6b8:c0e:6b:0:640:b813:52e4]) by forward500j.mail.yandex.net (Yandex) with ESMTP id 21EC911C10EB; Sat, 15 Aug 2020 14:24:46 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback9q.mail.yandex.net (mxback/Yandex) with ESMTP id gZoxByldXr-Oj7S7WEI; Sat, 15 Aug 2020 14:24:45 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1597490685; bh=YzdWpvIh/iiTERlAggFd6+ZvO322aG3JHfdsvVWL8TE=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=FJe1Q7PhtEbADI+06DTKefL6JjoivmEnSdyWQ41v4f67blcNLpmVKD+nDkWqR20x4 xDzxz9Jpi9PszTX/NYbfNyZfKCMvf940F/mrlHgeKu91wUFfwDm1vfO28Og1rG9CD0 r77raa6M6O1ZbMSDhxABxZNgQfvFn/FQe6Wj9+Pk= Received: by vla5-c7b28c6912c3.qloud-c.yandex.net with HTTP; Sat, 15 Aug 2020 14:24:45 +0300 From: Alexander V. Chernikov To: "current@FreeBSD.org" , FreeBSD Stable Mailing List , net In-Reply-To: <236161595078191@mail.yandex.ru> References: <236161595078191@mail.yandex.ru> Subject: Re: net.add_addr_allfibs=1 behaviour deprecation MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 15 Aug 2020 12:24:45 +0100 Message-Id: <348771597489519@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4BTHyn6TMtz3gf7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=FJe1Q7Ph; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:801:2::110 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-3.27 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; NEURAL_HAM_MEDIUM(-1.10)[-1.096]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0::/52]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_LONG(-1.02)[-1.016]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[ipfw.ru:+]; NEURAL_HAM_SHORT(-0.56)[-0.556]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:0:801:2::110:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 11:24:52 -0000 18.07.2020, 14:22, "Alexander V. Chernikov" : > Dear FreeBSD users, > > I would like to make net.add_addr_allfibs=0 as the default system behaviour and remove net.add_addr_allfibs. > To do so, I would like to collect use cases with net.add_addr_allfibs=1 and multiple fibs, to ensure they can still be supported after removal. > > Background: > > Multi-fib support was added in r178888 [1], 12 years ago. Addition of interface addresses to all fibs was a feature from day 1. > The `net.add_addr_allfibs` sysctl  was added in r180840 [2], 12 years ago. > > Problem: > The goal of the fib support is to provide multiple independent routing tables, isolated from each other. > `net.add_addr_allfibs` default tries to shift gears in the opposite direction, unconditionally inserting all addresses to all of the fibs. > > It complicates the logic, kernel code and makes control plane performance decrease with the number of fibs. > It make impossible to use the same prefixes in multiple fibs, which may be desired given shortage of IPv4 address space. > > I do understand that there are some cases where such behaviour is desired. > For example, it can be used to achieve VRF route leaking or binding on address from different fibs. > I would like to collect such cases to consider supporting them in a different way. > > The goal is to make net.add_addr_allfibs=0 default behaviour and remove net.add_addr_allfibs. > It will simplify kernel fib-related code and allow bringing more fib-related features. It will also improve fib scaling. No objections has been received. Next steps: * Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 ) * Provide an ability to use nexthops from different fibs * Remove net.add_addr_allfibs > Timeline: > Aug 1: summarising feedback and the usecases, decision on proceeding further > Aug 20 (tentative):  patches for supported usecases > Sep 15 (tentative):  net.add_addr_allfibs removal. > > [1]: [base Contents of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=178888&view=markup) > [2]: [base Diff of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&) > > /Alexander From owner-freebsd-current@freebsd.org Sat Aug 15 14:48:02 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DAE723BBFDC for ; Sat, 15 Aug 2020 14:48:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BTNTG5GV0z4Cfj for ; Sat, 15 Aug 2020 14:48:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B2DFC3BBD75; Sat, 15 Aug 2020 14:48:02 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B281E3BC3BD; Sat, 15 Aug 2020 14:48:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTNTF5NzWz4CsL; Sat, 15 Aug 2020 14:48:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f178.google.com with SMTP id o21so10758532oie.12; Sat, 15 Aug 2020 07:48:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xGjUfKxn9PfIdLBCx9jG/5F1X1T8UbpBBrQCqcW2N5g=; b=TAxsJ3ivYmXWVCMyQg1mQY9Ggwo4jmg8PHt+Djgzs59cWBgQN+R/QgqM2A0mwdzJDy R7syZix4vvhluaUbIB3UYRcjn7T5rPVDz93YJlFUSjAIapzlFeGP0i4USuyDBalnD+QH JzZB6CnG/y8nUhtWgjITXxKfg7/cnyCwRQ3oh0j255rFv/WIgPtQTcyDGJwg0g0c4OOU 7E/vBlkNKEd1qPnwns54XPvBMowkrzwB9UdwIQruuSr7HALL9S8Gf2vigQbUB5rMsgFm n3pApv54oaEJI7CiXpe2AH0O8mKVrbQtMN+lKag6Pff/vO63MzjH6NuS6ocyBUiFQw4x 0k1Q== X-Gm-Message-State: AOAM530mFm4YCNfJMXOSKuUZGPOEqESQzt1QbpUT4x+beqGulCN0q8M3 81bnEm8MFsjFPuw7WCXuMimd3pYREL7+A/1ryGOypsPJkUU= X-Google-Smtp-Source: ABdhPJwR1se2wLNXDPidVQouTiRnBcgdFM+UESssvfvbwGFr52Z1+1azCPvJElk6SnoLVKn1FjlR5oEmF7xECl9b8/o= X-Received: by 2002:aca:1c0c:: with SMTP id c12mr4585022oic.73.1597502879817; Sat, 15 Aug 2020 07:47:59 -0700 (PDT) MIME-Version: 1.0 References: <236161595078191@mail.yandex.ru> <348771597489519@mail.yandex.ru> In-Reply-To: <348771597489519@mail.yandex.ru> From: Alan Somers Date: Sat, 15 Aug 2020 08:47:48 -0600 Message-ID: Subject: Re: net.add_addr_allfibs=1 behaviour deprecation To: "Alexander V. Chernikov" Cc: "current@FreeBSD.org" , FreeBSD Stable Mailing List , net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597502882; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xGjUfKxn9PfIdLBCx9jG/5F1X1T8UbpBBrQCqcW2N5g=; b=WdY0jVdn1BlbqxG5m+nvFY38qIuSOnEYKZW/QE9nKzOAbkAKQpZB+RRUHaklXE4kj3MCYA GDwH3oPk/oZbloOv8iEfu0j8Fu8YXdnZyZMKhDDTJU+PsT9TSWqWOuR6q5ZA2KUx1ib25z uXBa2myup8bGUiAUgxL7p3kTB7rUWhR2EeAKKHX+mh9fbmezEsj//uUx1ZhS9HMxukaWQN k671Pjqkak9a1VAqbAev/5pWNuVzCH16Jl/hNtWni11MNIRPW8N4XBcRifhlpctdC2Xcal SFE9bhzwQYBLXLub9pR6bQBTJMer6bMsnt2UBck2M93nj7kvk0fe0TWoqNstRQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597502882; a=rsa-sha256; cv=none; b=XwDNAhwCzQWuNl5rwbLZ7vhn/pvr7x4/WC2Aff4jVQ930Sbbg88G46ouaZckjtMbnMdRzA gpJOF3h4VGUlKqNyUFOCFPPUDo2YEKHqanI0BxfudHKREulp94xDD6Rp5eXcZCjdtPJlle q0Ym5cpc70/pMi7rr5bijB8+vRL+AfWo6jK7kY+fiVzYGX1ID5RjEfsPOwRr88ZwH6DEMd TanUOlKq7zlD2d7Cexgn+rcQ2o8c1Z44Wrv+25FD1gWh8LCWEQh4zmVur4JvfVUrNBSy/3 Tbq+gtAKfkjpdefa/+eYM21WzMNfZoy8yel43Nz6FNBeVgWNPj0HiidoqwiYzg== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.178 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Rspamd-Queue-Id: 4BTNTF5NzWz4CsL X-Spamd-Bar: / X-Spamd-Result: default: False [0.03 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.59)[-0.591]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_SIGNED(0.00)[i=1]; TO_DN_SOME(0.00)[]; URI_COUNT_ODD(1.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.242]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.178:from]; NEURAL_HAM_MEDIUM(-0.14)[-0.136]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.178:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 14:48:02 -0000 On Sat, Aug 15, 2020 at 5:25 AM Alexander V. Chernikov wrote: > 18.07.2020, 14:22, "Alexander V. Chernikov" : > > Dear FreeBSD users, > > > > I would like to make net.add_addr_allfibs=0 as the default system > behaviour and remove net.add_addr_allfibs. > > To do so, I would like to collect use cases with net.add_addr_allfibs=1 > and multiple fibs, to ensure they can still be supported after removal. > > > > Background: > > > > Multi-fib support was added in r178888 [1], 12 years ago. Addition of > interface addresses to all fibs was a feature from day 1. > > The `net.add_addr_allfibs` sysctl was added in r180840 [2], 12 years > ago. > > > > Problem: > > The goal of the fib support is to provide multiple independent routing > tables, isolated from each other. > > `net.add_addr_allfibs` default tries to shift gears in the opposite > direction, unconditionally inserting all addresses to all of the fibs. > > > > It complicates the logic, kernel code and makes control plane > performance decrease with the number of fibs. > > It make impossible to use the same prefixes in multiple fibs, which may > be desired given shortage of IPv4 address space. > > > > I do understand that there are some cases where such behaviour is > desired. > > For example, it can be used to achieve VRF route leaking or binding on > address from different fibs. > > I would like to collect such cases to consider supporting them in a > different way. > > > > The goal is to make net.add_addr_allfibs=0 default behaviour and remove > net.add_addr_allfibs. > > It will simplify kernel fib-related code and allow bringing more > fib-related features. It will also improve fib scaling. > No objections has been received. > Next steps: > * Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 ) > * Provide an ability to use nexthops from different fibs > * Remove net.add_addr_allfibs > > Timeline: > > Aug 1: summarising feedback and the usecases, decision on proceeding > further > > Aug 20 (tentative): patches for supported usecases > > Sep 15 (tentative): net.add_addr_allfibs removal. > > > > [1]: [base Contents of /head/sys/net/route.c]( > https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=178888&view=markup > ) > > [2]: [base Diff of /head/sys/net/route.c]( > https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&) > > > > /Alexander > I just want to say that I completely agree with this proposal. -Alan From owner-freebsd-current@freebsd.org Sat Aug 15 18:35:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15F2F37A615; Sat, 15 Aug 2020 18:35:16 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTTWP4V1Bz4ZK6; Sat, 15 Aug 2020 18:35:13 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-vs1-xe43.google.com with SMTP id o184so6304808vsc.0; Sat, 15 Aug 2020 11:35:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ly9dD5ehryicaTmyER9eTsPwkgSLZljkgypspsZET9A=; b=Run3XUthg187wWeZDDbG2U2j6NMRiaZ67dyJhHrGNZwbw64TiWA3EPkRG1DCU7wApY ZcyAMMUy8HrqW0Q2AdU/OJQQk1yz4TreK+FSGfWLB6FRgI4hqP0dFz2CANuj4xwd79ab +u/1K09XMTAhoUF1hc3Ck4uvFNnEcQ/BWltQPzBYqSDaXCqPhRAHKHPPPP/GjxNQXCMt 3db8mJWZnD/GmARVv3KdEeMOLJcRT+z3gLbhKyHhUL+vtnSenIy/qVUqAfOCX0EPvv5P r6MqHlDeSP2mNvvjYFWREI2WQNZaFO14lAZL2m18b79Bo+RhRkJzAYCOJdiFBFrbs+aB 0gqw== X-Gm-Message-State: AOAM532hpgE0SjuxEN35zGmO2/a0cFcBDV7L5ySmYQV1lq+GMQ8LtCTK nTOwLfP5d1QnZjpZ0cWzO9/i0JoZCOqKSxMEFLlesxYWkiFG3Q== X-Google-Smtp-Source: ABdhPJwGj+adNAQYp4JCfgx9sVfLXWBGSmYVjYBO4EaZKCTrZtjXQyg7r4OSCSYBhlnUUoIOEgbmkeBV3y+xMPNSpVE= X-Received: by 2002:a67:fc8c:: with SMTP id x12mr4604614vsp.88.1597516512200; Sat, 15 Aug 2020 11:35:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Nebdal Date: Sat, 15 Aug 2020 20:34:35 +0200 Message-ID: Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images To: Matthew Macy Cc: freebsd-current , freebsd-fs , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597516513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ly9dD5ehryicaTmyER9eTsPwkgSLZljkgypspsZET9A=; b=fGZjiAbmnLrx6P55nMDBJQu6B6lgmetmxkH7MunRXi1R3vyGzs7f8g7qZvu+H5eJ9AZtM8 vpJYSwDhm5Cd5DbfCflXJSuPR+RFVbUGp0u4IlQsjqjk/AoqRE9nweVB0fKN49SfdxxoZB yb4lu2mBP8bNz/ijq+MtKIb+HUpvqf0Ikf9vTsDkGsrBZCpXNE4X/xoyVlMhHN1Ywpzv+Q UH5DoCRsIzVcu4wJSvrUqwMwnBH2OnUFGuH4I18byH8uEoFpmu0ixrG6b6OfTNvdUI0W9r zBdWosXHicvZCIc4qB/ElMSWXOb8C0IHJ4YP/lysw4o1ZArt01K2jMlP8Pj5Qg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597516513; a=rsa-sha256; cv=none; b=GybqhcXNwQ9wRo7SeC1RLSMsoZoAUJOyXADL09F9Q7RYNub65JR/iOCS57qHgszGF7oYhs AIwu2aHFnhbg1Z4aLkJzCtQ9b+MCGsoW2/+vJigZrabnS1JwHiE8YCebCJBYqDL7UJxa66 PDkfk5no7yKQCu5WxZwuGlDRX8tk53IJoskQRe/BNBUq9fNwWaiB5JHZkTHZkENWD1BxrS ZPTLEfb4PWHFDlRYWoVOw8xkZozM8qAn65dTS0i+29TwBW+my1yytX4UHLWscVh18Ibwei 15dyrtCgG0JuSsvTEak5VssdgkEUe5SWKFmsghsZZr7UBDXwzwUKl0aHcsQCNA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ryQkcHVg; spf=pass (mx1.freebsd.org: domain of dnebdal@gmail.com designates 2607:f8b0:4864:20::e43 as permitted sender) smtp.mailfrom=dnebdal@gmail.com X-Rspamd-Queue-Id: 4BTTWP4V1Bz4ZK6 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.06)[-1.064]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; ARC_SIGNED(0.00)[i=1]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.06)[-1.055]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e43:from]; NEURAL_HAM_SHORT(-0.46)[-0.462]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 18:35:16 -0000 On Tue, 4 Aug 2020 at 02:25, Matthew Macy wrote: > > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The tentative merge date is August > 17th. > > Again, I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > > amd64, i386, and aarch64 memdisk images can be found at: > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/ > > If you're using a platform not listed above and would be inclined to > test if you had an image to work with, let us know. Alternatively, you > can still build following the instructions below. > > The review for merging in to base can be found at: > https://reviews.freebsd.org/D25872 > > ========================================================== > NB: Do NOT zpool upgrade unless you are willing to live without the > ability to ever rollback to the legacy zfs kmod. > > Checkout updated HEAD: > % git clone https://github.com/mattmacy/networking.git -b > projects/openzfs_vendor freebsd > > Checkout updated openzfs in to sys/contrib: > % git clone https://github.com/zfsonfreebsd/ZoF.git -b > projects/openzfs_vendor freebsd/sys/contrib/openzfs > > Build world and kernel with whatever your usual configuration is. > Where possible the openzfs kmod is backward compatible with the cmd > utils in HEAD so common operations work with existing tools and the > new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries > are backward compatible with the zfs kmod in HEAD. Although ideally > one would test this in a separate boot environment, the > interoperability should allow one to rollback without too much > difficulty. > > NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools > other than the root pool will not be imported at boot. > > Thanks in advance for your time. > > -M > _______________________________________________ > 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" Hi. I have some problems downloading the amd64 image: baymax /home/djn > fetch -a https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps 04m07s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 134152192/687158140 bytes baymax /home/djn > fetch -ar https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 882 kBps 09m10s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 139132928/687158140 bytes baymax /home/djn > fetch -ar https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 647 kBps 12m23s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 142065664/687158140 bytes baymax /home/djn > It also fails using Firefox on windows on a different machine. (It's also much slower from that machine, about 200 kB/sec. I have no idea if that's relevant.) -- Daniel Nebdal From owner-freebsd-current@freebsd.org Sat Aug 15 19:30:23 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 55B9B37C04B; Sat, 15 Aug 2020 19:30:23 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTVl31fmWz4dCX; Sat, 15 Aug 2020 19:30:23 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 16CCF2CAB6; Sat, 15 Aug 2020 19:30:23 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f51.google.com with SMTP id b30so6427224lfj.12; Sat, 15 Aug 2020 12:30:23 -0700 (PDT) X-Gm-Message-State: AOAM533EWLk8oqkQAASaWwoWIZf+o/SsQSbD5HDdUf11LHYtlIugpAtM PE7mNyDUzVeabwLSASWPun1bneWs95yhUhoeKDY= X-Google-Smtp-Source: ABdhPJxOrSmfJbJf/TGBvMgiRyCIsYfty5VK5vXpvADcYLaXpZB+m5OhuURb9jEhJzPb4xWkX0cnYxaOab96l925QUY= X-Received: by 2002:a19:189:: with SMTP id 131mr4003208lfb.128.1597519821598; Sat, 15 Aug 2020 12:30:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Sat, 15 Aug 2020 12:30:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images To: Daniel Nebdal Cc: freebsd-current , freebsd-fs , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:30:23 -0000 > > Hi. I have some problems downloading the amd64 image: > > baymax /home/djn > fetch -a > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps 04m07s > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > truncated: 134152192/687158140 bytes > baymax /home/djn > fetch -ar > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 882 kBps 09m10s > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > truncated: 139132928/687158140 bytes > baymax /home/djn > fetch -ar > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 647 kBps 12m23s > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > truncated: 142065664/687158140 bytes > baymax /home/djn > > > It also fails using Firefox on windows on a different machine. (It's > also much slower from that machine, about 200 kB/sec. I have no idea > if that's relevant.) Yes, this appears to have been going on for at least the last week. The FreeBSD infrastructure directly available to developers appears to be unreliable for serving large files. Individuals with accounts on freefall have been able to scp the files. It's possible that we may just end up sharing images more widely by way of releng generated images after commit. I'll see if there's an alternative for the last week of the CFT. Cheers. -M > > -- > Daniel Nebdal From owner-freebsd-current@freebsd.org Sat Aug 15 19:35:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5398E37C5D5 for ; Sat, 15 Aug 2020 19:35:19 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTVrk44dxz4dfv for ; Sat, 15 Aug 2020 19:35:18 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id k20so10642896wmi.5 for ; Sat, 15 Aug 2020 12:35:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOcAvoa0PH0sgNYbTYdUdhKFSYiMjvYrg7qqHrXB3Bg=; b=P0YXflqOsUXz2S0I7Ut87tPtOyBzGLk7JwAJzgv+R3MJCQ96BuwmDxXxFfqyfZXyAY s2NLjCjQ5VjpAALk+v5Q/Clb0clX1UOyyhuULlRYZ7ze3lCQFG1p0wd0BUsLPISNUwAD Nkxz/eOQ+naePnx/Z+/MGoBT72Ypl5xZX4iOs29+gTaTzNca2A11UJ6QkLnyVUTv6Y8s FJGzHMqPy/HeZeKuQ8HwQ4EKKw5fU8eVr68ILPrYCXGhJUl7y1ZDA/gdi9NElaE215vE zvFGfQuf9TjwG82IWyU83D98SIpW/E9E5RibMybtDu5imJOF2+Bgx4vvtZytxO0VuFaa MKrg== X-Gm-Message-State: AOAM5338wTqMYAQfZ7XBxv0JMpJiqAVEIJE62uV3OKXvUJ82zbS8GJX1 2EW6diGCm0bvKlmqFKzSnMYeZSmEErir/+Y06GwfS0/yDsCc6dgg X-Google-Smtp-Source: ABdhPJyNqls1zVdSCD8mDC5nvFKSe/2cUrAsTnRbKlzcsNfwpgceSU2Bhfd2kWaus4P/JYUjMix74pbtNq9Ep1vwcAc= X-Received: by 2002:a1c:6243:: with SMTP id w64mr7825701wmb.3.1597520116517; Sat, 15 Aug 2020 12:35:16 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> In-Reply-To: <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> From: Alexandre Levy Date: Sat, 15 Aug 2020 20:35:05 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597520118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yOcAvoa0PH0sgNYbTYdUdhKFSYiMjvYrg7qqHrXB3Bg=; b=EcTEJc+eSi32GE4/bJODu/XKEZ9J0ToLIbeYDBX/4H9EyNDwX2k0OYt+CDhjX/y/ViVU5C mIFSIGRZYrCNAyFZDIqCBXTvHYY59T9Wa25UC8SdAdEFNYfr8HEr7xA3N1yXtc2OmbDDDU +LRITEcEnPi5dYKc08tLkyjjtdRAYjhzd5OyML9HSR7nUJFPH/UkvS1Tg9pi4vCD+HEgkR YN1yqGH60eQ20AaJwYrwder6aXY+zsWDn9MszGgAu3bRJIePh/VBfuaEpahz3vhcxU17f2 qyGIVIFaDk1eTuxsQFyuXi9NMiYS18JQF9/rQeaB8LSUxBdNFMHeYbUOScSuaA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597520118; a=rsa-sha256; cv=none; b=TCBICpMoZlB4wQELwFvHW2pO+GAyl7te3PCbGb4tOdP62zUOMvsui/Q7ChwOe4enZKBk7Y NsC7tYVXnF9AtJhEvv7/3mWfrnSvCiiGM+1GtJnuW9RhsnLCDBeuiJPPgx2UXz9e8WHbdD 0rm6LHFBadlw2gF4CBFoeh3LTiimXxIZyP1u07zldCzMEBC9tdVnyHabYxj1zcjcCmvBkE qzbcATD1U/UTLyWN0I0P6z8W7dZrNF/veTTnFI9km1J0tqirqHJ9II77t/Q+KIvH0G9+uY m7dvYEQaByrM9bJfYttoEUbAM0HrZDaJdrpnpIYw1DuxkGUAk4y3lmwyDTScwA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mFDkTLbG; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::341 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Rspamd-Queue-Id: 4BTVrk44dxz4dfv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.049]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_LONG(-1.02)[-1.020]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::341:from]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:35:19 -0000 Hi, I could finally generate a crash dump even with a black screen, I had to guess I was in the crash handler and I type "dump" and enter which worked. The driver logs "[drm] Cannot find any crtc or sizes" which I guess is the reason why I couldn't see anything on my screen. Back to the initial problem, I could start a kgdb session, loaded the i915kms.ko symbols and here are the results : (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff8049c26a in db_dump (dummy=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff8049c02c in db_command (last_cmdp=3D, cmd_table=3D, dopager=3D1) at /usr/src/sys/ddb/db_command.c:= 482 #4 0xffffffff8049bd9d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff8049f048 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80c1b374 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:699 #7 0xffffffff8100ca98 in trap (frame=3D0xfffffe00d7567300) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=3D0xffffffff811d5de0 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:486 #10 0xffffffff80bd00be in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:902 #11 0xffffffff80bcfe53 in panic (fmt=3D0xffffffff81c8c7c8 "\b\214\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:839 #12 0xffffffff8100cee7 in trap_fatal (frame=3D0xfffffe00d7567600, eva=3D0) = at /usr/src/sys/amd64/amd64/trap.c:915 #13 0xffffffff8100c360 in trap (frame=3D0xfffffe00d7567600) at /usr/src/sys/amd64/amd64/trap.c:212 #14 #15 _rw_wowned (c=3D0x2659c92217d5aa52) at /usr/src/sys/kern/kern_rwlock.c:= 270 #16 0xffffffff80ec23ed in vm_page_busy_acquire (m=3D0xfffffe00040ff9e8, allocflags=3D16) at /usr/src/sys/vm/vm_page.c:884 #17 0xffffffff82b4e980 in remap_io_mapping (vma=3D0xfffff80315148300, addr=3D, pfn=3D, size=3D, iomap=3D) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/intel_freebsd.c:193 #18 0xffffffff82be1c5f in i915_gem_fault (dummy=3D, vmf=3D) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/gem/i915_gem_mman.c:367 #19 0xffffffff82cb5ddf in linux_cdev_pager_populate (vm_obj=3D0xfffff80368501420, pidx=3D, fault_type=3D, max_prot=3D, first=3D0xfffffe00d7567868, last=3D0xfffffe00d7567888) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:554 #20 0xffffffff80ea9e8f in vm_pager_populate (object=3D0x2659c92217d5aa52, pidx=3D18446741874754451944, fault_type=3D0, max_prot=3D0 '\000', first=3D, last=3D) at /usr/src/sys/vm/vm_pager.h:172 #21 vm_fault_populate (fs=3D) at /usr/src/sys/vm/vm_fault.c:= 444 #22 vm_fault_allocate (fs=3D) at /usr/src/sys/vm/vm_fault.c:1028 #23 vm_fault (map=3D, vaddr=3D, fault_type=3D, fault_flags=3D, m_hold=3D) at /usr/src/sys/vm/vm_fault.c:1338 #24 0xffffffff80ea98ee in vm_fault_trap (map=3D0xfffffe00c0f539e8, vaddr=3D, fault_type=3D, fault_flags=3D0, signo=3D0xfffffe00d7567ac4, ucode=3D0xfffffe00d7567ac0) at /usr/src/sys/vm/vm_fault.c:585 #25 0xffffffff8100d0de in trap_pfault (frame=3D0xfffffe00d7567b00, usermode=3D, signo=3D, ucode=3D0xffffffff81d1= de80 ) at /usr/src/sys/amd64/amd64/trap.c:817 #26 0xffffffff8100c72c in trap (frame=3D0xfffffe00d7567b00) at /usr/src/sys/amd64/amd64/trap.c:340 #27 #28 0x000000080296659a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffbf38 (kgdb) list *0xffffffff82be1c5f 0xffffffff82be1c5f is in i915_gem_fault (/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/dr= m/i915/gem/i915_gem_mman.c:367). 362 ret =3D i915_vma_pin_fence(vma); 363 if (ret) 364 goto err_unpin; 365 366 /* Finally, remap it using the new GTT offset */ 367 ret =3D remap_io_mapping(area, 368 area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT), 369 (ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT, 370 min_t(u64, vma->size, area->vm_end - area->vm_start), 371 &ggtt->iomap); (kgdb) list *0xffffffff82b4e980 0xffffffff82b4e980 is in remap_io_mapping (/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/dr= m/i915/intel_freebsd.c:193). 188 pidx++, pa +=3D PAGE_SIZE) { 189 retry: 190 m =3D vm_page_grab(vm_obj, pidx, VM_ALLOC_NOCREAT); 191 if (m =3D=3D NULL) { 192 m =3D PHYS_TO_VM_PAGE(pa); 193 if (!vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL)) 194 goto retry; 195 if (vm_page_insert(m, vm_obj, pidx)) { 196 vm_page_xunbusy(m); 197 VM_OBJECT_WUNLOCK(vm_obj); (kgdb) list *0xffffffff80ec23ed 0xffffffff80ec23ed is in vm_page_busy_acquire (/usr/src/sys/vm/vm_page.c:884). 879 if (vm_page_tryacquire(m, allocflags)) 880 return (true); 881 if ((allocflags & VM_ALLOC_NOWAIT) !=3D 0) 882 return (false); 883 if (obj !=3D NULL) 884 locked =3D VM_OBJECT_WOWNED(obj); 885 else 886 locked =3D false; 887 MPASS(locked || vm_page_wired(m)); 888 if (_vm_page_busy_sleep(obj, m, m->pindex, "vmpba", allocflags, It seems like the problem occured when calling vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL) where m might be a NULL pointer ? I am very new to kernel debugging so not sure where to go from there. Thanks. Le lun. 10 ao=C3=BBt 2020 =C3=A0 12:04, Hans Petter Selasky a =C3=A9crit : > Hi, > > On 2020-08-10 12:59, Alexandre Levy wrote: > > Looking at the code, the error happens during the call to VM_OBJECT_WLO= CK > > (memory page locking for write ?) in the intel_freebsd.c (see [1] below= ). > > I'm out for a few days but I'll try to dig more into it when I'm back > next > > weekend although I have no experience in the drm-devel-kmod codebase. I= n > > the meantime if you have any suggestions on debugging this further I'm > > happy to follow them. > > The problem is likely that the vm_obj is NULL. > > I think I recall that this function is special and can only be called > from a certain context, unlike in Linux. Will need the full backtrace > with line numbers in order to debug this. > > --HPS > From owner-freebsd-current@freebsd.org Sat Aug 15 19:48:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E1C9437CD80; Sat, 15 Aug 2020 19:48:05 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTW7T45PXz4fV4; Sat, 15 Aug 2020 19:48:05 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-vs1-xe43.google.com with SMTP id j188so6360204vsd.2; Sat, 15 Aug 2020 12:48:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1wIk44cxuFg2/xCBgg6BX78mBe5IH2uL3Il+FrK9V/8=; b=NkaJcsrbJl8El22rVNCggVsqFMoyv9dXdneH51nM8J5xeqeRTm4Sa1Oa3UkV+soGWF ubcjudoIMnuFiEm69hf3LbbOy0TLYbyg/jZSlfNIHgzRQktk6yMjUX8v/hfVy0qNsUCd 0v1cokRQW1xgyeFj37U+A7cboQ8hH1CFzqWo/AOdTOFKfi7Nw8ArysJ7+v+SKHA2Q/H8 ECs1o3WCRfU2cY/XIXcumsUH/JZfeOBxyUDTG5h2SSkdWht3SuwqDVWroYfbQ7kePwSE Emf45T0A+tmtLG5idBrYgON//ujY1jfazL+V2O1LWnAiSq+d00xw6uXsBw6f6ph6JRzk WmRA== X-Gm-Message-State: AOAM530TvE2ybWuDoNujlRixWPexoZ1Fy//KTHAQ8CDGN0MyWIRHZ/Sa gizzkJJGCwACaldDU5ZBO37niv3lNT5p40+cnsX4DUXB7CU= X-Google-Smtp-Source: ABdhPJxriUejqB8LInt6yXy/K6oVRUQ91MKJHjtBJeOlAxOuuiz1gFDHY8C421vphH0hdJvMKPGTCt35f4CYB5mbjbA= X-Received: by 2002:a67:e415:: with SMTP id d21mr4620201vsf.65.1597520884380; Sat, 15 Aug 2020 12:48:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Nebdal Date: Sat, 15 Aug 2020 21:47:28 +0200 Message-ID: Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images To: Matthew Macy Cc: freebsd-current , freebsd-fs , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BTW7T45PXz4fV4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:48:05 -0000 On Sat, 15 Aug 2020 at 21:30, Matthew Macy wrote: > > > > > Hi. I have some problems downloading the amd64 image: > > > > baymax /home/djn > fetch -a > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps 04m07s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 134152192/687158140 bytes > > baymax /home/djn > fetch -ar > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 882 kBps 09m10s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 139132928/687158140 bytes > > baymax /home/djn > fetch -ar > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 647 kBps 12m23s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 142065664/687158140 bytes > > baymax /home/djn > > > > > It also fails using Firefox on windows on a different machine. (It's > > also much slower from that machine, about 200 kB/sec. I have no idea > > if that's relevant.) > > Yes, this appears to have been going on for at least the last week. > The FreeBSD infrastructure directly available to developers appears to > be unreliable for serving large files. Individuals with accounts on > freefall have been able to scp the files. It's possible that we may > just end up sharing images more widely by way of releng generated > images after commit. I'll see if there's an alternative for the last > week of the CFT. > > Cheers. > -M The instructions for building it myself seem easy enough, so it's not a problem for *me* - but I'm sure it can't hurt. :) Thanks, -- Daniel Nebdal