From owner-freebsd-current@freebsd.org Sun Mar 19 00:53:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33ECBD08272 for ; Sun, 19 Mar 2017 00:53:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 D47D21C9B for ; Sun, 19 Mar 2017 00:53:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19111 invoked from network); 19 Mar 2017 00:53:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2017 00:53:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sat, 18 Mar 2017 20:53:42 -0400 (EDT) Received: (qmail 27325 invoked from network); 19 Mar 2017 00:53:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Mar 2017 00:53:41 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4149CEC7ED1; Sat, 18 Mar 2017 17:53:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> Date: Sat, 18 Mar 2017 17:53:40 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> To: Andrew Turner X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 00:53:50 -0000 A new, significant discovery follows. . . While checking out use of procstat -v I ran into the following common property for the 3 programs that I looked at: A) My small test program that fails for a dynamically allocated space. B) sh reporting Failed assertion: "tsd_booted". C) su reporting Failed assertion: "tsd_booted". Here are example addresses from the area of incorrectly zeroed memory (A then B then C): (lldb) print dyn_region (region *volatile) $0 = 0x0000000040616000 (lldb) print &__je_tsd_booted (bool *) $0 = 0x0000000040618520 (lldb) print &__je_tsd_booted (bool *) $0 = 0x0000000040618520 The first is from dynamic allocation ending up in the area. The other two are from libc.so.7 globals/statics ending up in the general area. It looks like something is trashing a specific memory area for some reason, rather independently of what the program specifics are. Other notes: At least for my small program showing failure: Being explicit about the combined conditions for failure for my test program. . . Both tcache enabled and allocations fitting in SMALL_MAXCLASS are required in order to make the program fail. Note: lldb) print __je_tcache_maxclass (size_t) $0 = 32768 which is larger than SMALL_MAXCLASS. I've not observed failures for sizes above SMALL_MAXCLASS but not exceeding __je_tcache_maxclass. Thus tcache use by itself does not seen sufficient for my program to get corruption of its dynamically allocated memory: the small allocation size also matters. Be warned that I can not eliminate the possibility that the trashing changed what region of memory it trashed for larger allocations or when tcache is disabled. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Mar 19 04:10:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 746BDD134E9 for ; Sun, 19 Mar 2017 04:10:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 244B1B9B for ; Sun, 19 Mar 2017 04:10:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3309 invoked from network); 19 Mar 2017 04:11:27 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2017 04:11:27 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 19 Mar 2017 00:10:36 -0400 (EDT) Received: (qmail 2340 invoked from network); 19 Mar 2017 04:10:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Mar 2017 04:10:36 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 70116EC894B; Sat, 18 Mar 2017 21:10:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> Date: Sat, 18 Mar 2017 21:10:34 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> To: Andrew Turner , freebsd-arm X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 04:10:39 -0000 On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: > A new, significant discovery follows. . . > > While checking out use of procstat -v I ran > into the following common property for the 3 > programs that I looked at: > > A) My small test program that fails for > a dynamically allocated space. > > B) sh reporting Failed assertion: "tsd_booted". > > C) su reporting Failed assertion: "tsd_booted". > > Here are example addresses from the area of > incorrectly zeroed memory (A then B then C): > > (lldb) print dyn_region > (region *volatile) $0 = 0x0000000040616000 > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x0000000040618520 > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x0000000040618520 That last above was a copy/paste error. Correction: (lldb) print &__je_tsd_booted (bool *) $0 = 0x000000004061d520 > The first is from dynamic allocation ending up > in the area. The other two are from libc.so.7 > globals/statics ending up in the general area. > > It looks like something is trashing a specific > memory area for some reason, rather independently > of what the program specifics are. > > > Other notes: > > At least for my small program showing failure: > > Being explicit about the combined conditions for failure > for my test program. . . > > Both tcache enabled and allocations fitting in SMALL_MAXCLASS > are required in order to make the program fail. > > Note: > > lldb) print __je_tcache_maxclass > (size_t) $0 = 32768 > > which is larger than SMALL_MAXCLASS. I've not observed > failures for sizes above SMALL_MAXCLASS but not exceeding > __je_tcache_maxclass. > > Thus tcache use by itself does not seen sufficient for > my program to get corruption of its dynamically allocated > memory: the small allocation size also matters. > > > Be warned that I can not eliminate the possibility that > the trashing changed what region of memory it trashed > for larger allocations or when tcache is disabled. The pine64+ 2GB eventually got into a state where: /etc/malloc.conf -> tcache:false made no difference and the failure kept occurring with that symbolic link in place. But after a reboot of the pin46+ 2GB /etc/malloc.conf -> tcache:false was again effective for my test program. (It was still present from before the reboot.) I checked the .core files and the allocated address assigned to dyn_region was the same in the tries before and after the reboot. (I had put in an additional raise(SIGABRT) so I'd always have a core file to look at.) Apparently /etc/malloc.conf -> tcache:false was being ignored before the reboot for some reason? === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Mar 19 07:00:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41C74D13369; Sun, 19 Mar 2017 07:00:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEBD9100B; Sun, 19 Mar 2017 07:00:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x22a.google.com with SMTP id l37so74357793wrc.1; Sun, 19 Mar 2017 00:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=dSPYDuICpp8LflwFJl3nsZaR6JDtD3bQRDrOGAi/FAU=; b=ZTBlX0OctYfPS/4qRuZWnU+h2xv79EeJH+pYMeeCF8H4JTVAN7ALWTD6mnA44ZoymX oEfmOd8/wZEwKiMX6zcwTistaM/Oc21GmQsAKJDY+tqFOJvCWeouuAQ96Vbne5CKJYTG rXVSvFhTsD3iPhndFV1Zvk+tANE64e/xvw5U6e3QQvt7M73oDriSlz8zThbfnCDSPFUj RxvYPVSLHqP5XYhk8gEJJPN8n3PDHEUVqdY+5aGBHokJvlo1mevqb8yB4mngUboi9fGX YC3fXxPCQnY9c0PhYVG9w6P86wjh2feePWoDwWS2yqTU+eedTig3Qw4ZlDby6PGiqazC HOAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=dSPYDuICpp8LflwFJl3nsZaR6JDtD3bQRDrOGAi/FAU=; b=kRPaP5yUPAsOGVA5ESY9ccR2+VGJuv5UXiJgobxnCfAucrfI0N5zIg615YtMlcSjeA QXDWucIv5STs26XDWR9ec+LXs0umulwccb+2yBq0uDIhGh7sWcHhNTyh6/kLEnSmA1e6 eQUtYvYDZ03iA/c6OlkzmjWFaw/07UoUxAH+T9PjwhyUdoUOyPHF4wRddpbBkXsBXWpO M9NVdyBPrcM+aELHdMiP9Fx/DXFzcwtg9ugdZMhPpItjgph5PJnGR3Yg2l+txhQf6IrL h93Je2XE4gKgEHnc2O0ixSv1mct0tsqWWhyHFbZnmSZfDti3/5rkofX/qIii3U7pNRH1 hckg== X-Gm-Message-State: AFeK/H01KOypeK1/YS2S/VUa88jmbGzIA/olcXfKdWDc1OHTkx4e9J6NMMNFs1XLPi7SDuIW/eMIdJPv/GVqEw== X-Received: by 10.223.179.15 with SMTP id j15mr22199585wrd.62.1489906806505; Sun, 19 Mar 2017 00:00:06 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.128.133 with HTTP; Sun, 19 Mar 2017 00:00:05 -0700 (PDT) From: Adrian Chadd Date: Sun, 19 Mar 2017 00:00:05 -0700 X-Google-Sender-Auth: G9UY4pG__q_UKEna_xHFOICxrSE Message-ID: Subject: cross compiling freebsd-head is sigh, now broken - thanks libllvm To: "freebsd-mips@freebsd.org" , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 07:00:11 -0000 ===> lib/clang (all) ===> lib/clang/libllvm (all) In file included from /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0, from /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305, from /usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Support/DataTypes.h:34, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/Hashing.h:48, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMapInfo.h:17, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:17, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/IR/ValueMap.h:29, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Transforms/Utils/ValueMapper.h:18, from /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:15: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits: In substitution of 'template static std::__1::true_type std::__1::__is_constructible_helper::__test_nary(int) [with _Tp = {anonymous}::MDNodeMapper::Data; _Args = {}; = ]': /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2993:59: required from 'struct std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data, false>' /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3015:8: required from 'struct std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>' /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3043:29: required from 'struct std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>' /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3229:29: required from 'struct std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>' /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:15: required from 'static constexpr bool std::__1::pair<_T1, _T2>::_CheckArgs::__enable_default() [with _U1 = const llvm::Metadata*; _U2 = {anonymous}::MDNodeMapper::Data; _T1 = const llvm::Metadata*; _T2 = {anonymous}::MDNodeMapper::Data]' /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:71: required by substitution of 'template::_CheckArgs, std::__1::__check_tuple_constructor_fail>::type:: __enable_default(), bool>::type > constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy = true; typename std::__1::enable_if::_CheckArgs, std::__1::__check_tuple_constructor_fail>::type:: __enable_default(), bool>::type = ]' /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:39:8: required from 'struct llvm::detail::DenseMapPair' /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:111:6: required from 'class llvm::detail::AlignerImpl [32], llvm::SmallDenseMap::LargeRep, char, char, char, char, char, char, char, char>' /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8: required from 'struct llvm::AlignedCharArrayUnion [32], llvm::SmallDenseMap::LargeRep, char, char, char, char, char, char, char, char>' /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:759:59: required from 'class llvm::SmallDenseMap' /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:182:47: required from here /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9: error: constructor required before non-static data member for '{anonymous}::MDNodeMapper::Data::HasChanged' has been parsed class = decltype(_Tp(_VSTD::declval<_Args>()...))> ^ /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9: error: constructor required before non-static data member for '{anonymous}::MDNodeMapper::Data::ID' has been parsed *** Error code 1 Using adrian@sabrina:~/work/freebsd/head-embedded/src % mips-portbld-freebsd12.0-gcc-5.3.0 -v Using built-in specs. COLLECT_GCC=mips-portbld-freebsd12.0-gcc-5.3.0 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/mips-portbld-freebsd12.0/5.3.0/lto-wrapper Target: mips-portbld-freebsd12.0 Configured with: /wrkdirs/usr/ports/devel/mips-gcc/work/gcc-5.3.0/configure --target=mips-portbld-freebsd12.0 --disable-nls --enable-languages=c,c++ --without-headers --with-gmp=/usr/local --with-pkgversion='FreeBSD Ports Collection for mips' --with-system-zlib --with-as=/usr/local/bin/mips-freebsd-as --with-ld=/usr/local/bin/mips-freebsd-ld --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ --build=x86_64-portbld-freebsd12.0 Thread model: posix gcc version 5.3.0 (FreeBSD Ports Collection for mips) ... so uhm, why are we building libllvm? -adrian From owner-freebsd-current@freebsd.org Sun Mar 19 12:30:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4E8ED10452 for ; Sun, 19 Mar 2017 12:30:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C0F57196F for ; Sun, 19 Mar 2017 12:30:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id C04E8D10451; Sun, 19 Mar 2017 12:30:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF54D10450 for ; Sun, 19 Mar 2017 12:30:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84EA4196E for ; Sun, 19 Mar 2017 12:30:43 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1cpZyk-0000pK-U0 for current@freebsd.org; Sun, 19 Mar 2017 13:30:35 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1cpZyk-00085n-SK for current@freebsd.org; Sun, 19 Mar 2017 13:30:34 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Sun, 19 Mar 2017 12:30:34 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: Duplicate? dmesg backtrace, ignore if useless please. Date: Sun, 19 Mar 2017 05:30:34 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 12:30:44 -0000 A.M. security periodic output:=20=20 hostname, pkg audit etc, redacted... backtrace-17-dmesg-maybe-i386-r313487-12C-1200020.txt the above filename explains the build, platform... sort of... kernel log messages: +Expensive timeout(9) function: 0xb55a7b40(0xbe67c000) 0.034612848 s +Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.792115478 s +SMP: AP CPU #7 Launched! +SMP: AP CPU #5 Launched! +SMP: AP CPU #3 Launched! + init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600024599 Hz quality= 1000 + 1st 0xddc34aac bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3500 + 2nd 0xbe4eac00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 +GEOM_SCHED: Loading: mp =3D 0xc0005084, g_sched_class =3D 0xc0005084. +lock order reversal: + 1st 0xc2993914 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600 + 2nd 0xddd208c4 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280 + 3rd 0xc2c9b5c0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600 +stack backtrace: +#0 0xb5c22421 at witness_debugger+0x81 +#1 0xb5c22342 at witness_checkorder+0xd12 +#2 0xb5b9b5d4 at __lockmgr_args+0xa64 +#3 0xb5ebe317 at ffs_lock+0x87 +#4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 +#5 0xb5c9c137 at _vn_lock+0xb7 +#6 0xb5c8a894 at vget+0x64 +#7 0xb5c7c421 at vfs_hash_get+0xd1 +#8 0xb5eb9704 at ffs_vgetf+0x44 +#9 0xb5eaf5d4 at softdep_sync_buf+0x4d4 +#10 0xb5ebf02f at ffs_syncvnode+0x2df +#11 0xb5eae7ea at softdep_fsync+0x46a +#12 0xb5ebe1f1 at ffs_fsync+0x71 +#13 0xb618d671 at VOP_FSYNC_APV+0xd1 +#14 0xb5c9863e at kern_fsync+0x1ce +#15 0xb5c98732 at sys_fsync+0x22 +#16 0xb6155fa5 at syscall+0x3b5 +#17 0xb6140ede at Xint0x80_syscall+0x2e comments welcome. Cannot kgbd if ever still...=20= From owner-freebsd-current@freebsd.org Sun Mar 19 12:37:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6109DD106FE for ; Sun, 19 Mar 2017 12:37:12 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E15981D87 for ; Sun, 19 Mar 2017 12:37:11 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id z15so46785609lfd.1 for ; Sun, 19 Mar 2017 05:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EqQFbyqUeVMCwKAmMR8aptiOmHK+9kTjK5EnVuZJU/Q=; b=FDwlLbkIr6A+Di91eRnF57fJ9Gm/AUBuoYGYmfiCUL+obgoGIrMggN5MxnULtztI+T K+cDzkF3ZrBx0j6eG7qas+8oUNfyk3LO9G2C5Zl3P1K+IxyLnOQlPAF27J+NZgHEko3K BXj3MtAyqG9ChHz/8cQ7Q9oKf/o30qgv92aQ/1QjZc+QyawzZzb2VL55rslS6ucI0XqK IBu6JcaQ36hc9PvH9mOzjXT8tHLGMisGZ6mywU4nQ+px4or0VpGphRdd+/oaYg28iHxS vDYakeONHY+zbNs0IYZW0LNnq41ijvie01WenBWEmdhCAYFULRlG9auy3bJDiLwHEmwr BPrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EqQFbyqUeVMCwKAmMR8aptiOmHK+9kTjK5EnVuZJU/Q=; b=Z2SIVL9s4n8YLU63BItwOO/OkZlOsH9mSwSt5YNcAKC3ukl2rvWM1burnBdfDyD23D 5HCNZCyA0xOwGd7pWGT9rdM37Xfkgk6xcu2UFDwEHuTEOeJ5i0NXA26Gnd83n/+VyPmb OWc0KRlasmJCATdZCQtuWHR0jMyt1+IRt/fMWZQQCJ+N3XXbt/1RDEI+npSCdH8nBR/n xF8I2RFMBnOsifW1RO8UkXfOQjddDELKgqlEppuRWR+c9c53eBEUMe8422T7mg9eUIb0 I2YucBAjqTKTcmq0dPrzbanprv7+3D86Ys8o/r7ecUiQ/Lu0/7csDOpVpLW3MXG155OG B/SA== X-Gm-Message-State: AFeK/H2zS0X1FAwD8rlZMPWlRoszpuc5ZUJS7i5Bd8dKrQebBN15uHIIChYmUln9wMgG5g== X-Received: by 10.25.155.132 with SMTP id d126mr6916273lfe.110.1489927028455; Sun, 19 Mar 2017 05:37:08 -0700 (PDT) Received: from rimwks ([2001:470:28:81a:6ef0:49ff:fe75:38e3]) by smtp.gmail.com with ESMTPSA id g102sm2472812lfi.38.2017.03.19.05.37.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 19 Mar 2017 05:37:07 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sun, 19 Mar 2017 15:36:58 +0300 To: "O. Hartmann" Cc: Slawa Olhovchenkov , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170319153658.7f2b0038@rimwks> In-Reply-To: <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 12:37:12 -0000 On Fri, 17 Mar 2017 17:53:24 +0100 "O. Hartmann" wrote: > > Other OS detect AES-NI on this server? > > I havn't ried so far, the box is in heavy use. I'd like to check with > some live USB drive versions and report later. > You can write or find some program that read and decode CPUID and check AES-NI support without reboot. From owner-freebsd-current@freebsd.org Sun Mar 19 15:58:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F8E5D13EB2 for ; Sun, 19 Mar 2017 15:58:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D94453EB for ; Sun, 19 Mar 2017 15:58:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::700c:efaa:fa5a:3f35] (unknown [IPv6:2001:7b8:3a7:0:700c:efaa:fa5a:3f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD08B311DC; Sun, 19 Mar 2017 16:58:47 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E3231C59-6BB4-441A-B802-A6229B55DD7C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Date: Sun, 19 Mar 2017 16:58:40 +0100 In-Reply-To: <20170319153658.7f2b0038@rimwks> Cc: "O. Hartmann" , Slawa Olhovchenkov , freebsd-current To: Rozhuk Ivan References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170319153658.7f2b0038@rimwks> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 15:58:51 -0000 --Apple-Mail=_E3231C59-6BB4-441A-B802-A6229B55DD7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: >=20 > On Fri, 17 Mar 2017 17:53:24 +0100 > "O. Hartmann" wrote: >=20 >>> Other OS detect AES-NI on this server? >>=20 >> I havn't ried so far, the box is in heavy use. I'd like to check with >> some live USB drive versions and report later. >>=20 >=20 > You can write or find some program that read and decode CPUID and = check > AES-NI support without reboot. The kernel already does this at boot time, and show the results, e.g.: CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) Origin=3D"GenuineIntel" Id=3D0x306a9 Family=3D0x6 Model=3D0x3a = Stepping=3D9 = Features=3D0xfa3fbff = Features2=3D0xffba2203 AMD Features=3D0x28100000 AMD Features2=3D0x1 Structured Extended Features=3D0x202 TSC: P-state invariant Unfortunately the kernel does not expose this information via any sysctl, so some time after booting it may have "scrolled away" in dmesg. In that case, you can use either the misc/cpuid or the sysutils/cpuid ports to show this information, and even quite a lot more. -Dimitry --Apple-Mail=_E3231C59-6BB4-441A-B802-A6229B55DD7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljOqrcACgkQsF6jCi4glqOw0gCfa41TVzeek6jN0X00//kMk3Wl lLMAnRCr+KwM5hDyaGTW4TzM5hgL+FGd =VnTQ -----END PGP SIGNATURE----- --Apple-Mail=_E3231C59-6BB4-441A-B802-A6229B55DD7C-- From owner-freebsd-current@freebsd.org Sun Mar 19 16:03:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BFCED13153 for ; Sun, 19 Mar 2017 16:03:11 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 1DBA0B95; Sun, 19 Mar 2017 16:03:11 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cpdIS-000E9H-LZ; Sun, 19 Mar 2017 19:03:08 +0300 Date: Sun, 19 Mar 2017 19:03:08 +0300 From: Slawa Olhovchenkov To: Dimitry Andric Cc: Rozhuk Ivan , "O. Hartmann" , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170319160308.GV70430@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170319153658.7f2b0038@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 16:03:11 -0000 On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > "O. Hartmann" wrote: > > > >>> Other OS detect AES-NI on this server? > >> > >> I havn't ried so far, the box is in heavy use. I'd like to check with > >> some live USB drive versions and report later. > >> > > > > You can write or find some program that read and decode CPUID and check > > AES-NI support without reboot. > > The kernel already does this at boot time, and show the results, e.g.: > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > Features=0xfa3fbff > Features2=0xffba2203 > AMD Features=0x28100000 > AMD Features2=0x1 > Structured Extended Features=0x202 > TSC: P-state invariant > > Unfortunately the kernel does not expose this information via any > sysctl, so some time after booting it may have "scrolled away" in > dmesg. /var/run/dmesg.boot From owner-freebsd-current@freebsd.org Sun Mar 19 16:07:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C491D133C9 for ; Sun, 19 Mar 2017 16:07:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE218F3C; Sun, 19 Mar 2017 16:07:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2JG7XYi046018 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Mar 2017 18:07:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2JG7XYi046018 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2JG7XH8046017; Sun, 19 Mar 2017 18:07:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Mar 2017 18:07:33 +0200 From: Konstantin Belousov To: Dimitry Andric Cc: Rozhuk Ivan , "O. Hartmann" , Slawa Olhovchenkov , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170319160733.GA43712@kib.kiev.ua> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170319153658.7f2b0038@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 16:07:43 -0000 On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > "O. Hartmann" wrote: > > > >>> Other OS detect AES-NI on this server? > >> > >> I havn't ried so far, the box is in heavy use. I'd like to check with > >> some live USB drive versions and report later. > >> > > > > You can write or find some program that read and decode CPUID and check > > AES-NI support without reboot. > > The kernel already does this at boot time, and show the results, e.g.: > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > Features=0xfa3fbff > Features2=0xffba2203 > AMD Features=0x28100000 > AMD Features2=0x1 > Structured Extended Features=0x202 > TSC: P-state invariant > > Unfortunately the kernel does not expose this information via any > sysctl, so some time after booting it may have "scrolled away" in > dmesg. It is quite pointless to expose the information through a sysctl, because it is non-privileged and is available to usermode via execution of the CPUID instruction, which is utilized by utilities listed below. Also, look at cpucontrol -i. > > In that case, you can use either the misc/cpuid or the sysutils/cpuid > ports to show this information, and even quite a lot more. Or better, sysutils/x86info. From owner-freebsd-current@freebsd.org Sun Mar 19 16:16:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8286FD136BF for ; Sun, 19 Mar 2017 16:16:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 3648D14BF; Sun, 19 Mar 2017 16:16:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cpdVc-000EMF-Si; Sun, 19 Mar 2017 19:16:44 +0300 Date: Sun, 19 Mar 2017 19:16:44 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: Dimitry Andric , Rozhuk Ivan , "O. Hartmann" , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170319161644.GW70430@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170319153658.7f2b0038@rimwks> <20170319160733.GA43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170319160733.GA43712@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 16:16:47 -0000 On Sun, Mar 19, 2017 at 06:07:33PM +0200, Konstantin Belousov wrote: > On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > > "O. Hartmann" wrote: > > > > > >>> Other OS detect AES-NI on this server? > > >> > > >> I havn't ried so far, the box is in heavy use. I'd like to check with > > >> some live USB drive versions and report later. > > >> > > > > > > You can write or find some program that read and decode CPUID and check > > > AES-NI support without reboot. > > > > The kernel already does this at boot time, and show the results, e.g.: > > > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) > > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > Features=0xfa3fbff > > Features2=0xffba2203 > > AMD Features=0x28100000 > > AMD Features2=0x1 > > Structured Extended Features=0x202 > > TSC: P-state invariant > > > > Unfortunately the kernel does not expose this information via any > > sysctl, so some time after booting it may have "scrolled away" in > > dmesg. > It is quite pointless to expose the information through a sysctl, because > it is non-privileged and is available to usermode via execution of the > CPUID instruction, which is utilized by utilities listed below. > > Also, look at cpucontrol -i. % cpucontrol -i 0x1 /dev/cpuctl1 cpucontrol: error opening /dev/cpuctl1 for reading: Permission denied > > > > In that case, you can use either the misc/cpuid or the sysutils/cpuid > > ports to show this information, and even quite a lot more. > Or better, sysutils/x86info. % x86info x86info v1.31pre /dev/cpuctl0: Permission denied Found 24 identical CPUs Extended Family: 0 Extended Model: 4 Family: 6 Model: 79 Stepping: 1 Type: 0 (Original OEM) CPU Model (x86info's best guess): Unknown model. Processor name string (BIOS programmed): Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz Total processor threads: 24 This system has 2 six-core processors with hyper-threading (2 threads per core) running at an estimated 2.20GHz From owner-freebsd-current@freebsd.org Sun Mar 19 20:29:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE3B2D13713 for ; Sun, 19 Mar 2017 20:29:30 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84954C43 for ; Sun, 19 Mar 2017 20:29:30 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id g138so75743475itb.0 for ; Sun, 19 Mar 2017 13:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Nlj2vgO2S2Yl7qHiu/bN26U3QRO8LNsRsz3Uabv50Uc=; b=Q9toGbnqwjOx4rD/JkNQ0Gbm/byCYrmrWj0xSPW7xAXkYeN/cfDnD4dXSnJgrVKkbx VKCLkXCioQmb1cPDh471109+lQ0EYlSar/M82zG9LVCa/n1gR+8MOkHzBA7WGxjMjP9k cwUIDWHxoX9IdxNcWShpsSIS8dwGzAMIdqwsUqEqBmtDEOgl80zaFpTfp4Ov82fahwEI 2WYdh1jg480rF0WIm3Z5WWOE8Q3Om0U8Lus4c9fC5weMPeFPePvVN/LK6jCg2EJz7+uI sMIiMGiLf/ZbdBlWMLcImictihgEs/TzJV+Lp7XrJcup0kFqtYag/iBpfUem8FrhgHxJ zqEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Nlj2vgO2S2Yl7qHiu/bN26U3QRO8LNsRsz3Uabv50Uc=; b=A16PhFtEikWWoae97vxMTtEn//19ruK5qj1o+GBOeVWCETEcQCWv+Mi49j5Bziwv8D JJL6sLIoDFzumWziEqV3urjJhanuoPrTSQWePSv0tSO5xCqzSEYLpbuqtRCLi1DRBeWX lSnmhY7y+oE38fgd5N31iuJzpM39uDIbbCs6AQ8mfztPp4QPxsv7udaM7Mgvtl7JBFQl l3EGJDaTvYlaCB6QWAFmr+hW0cjnP9DhOkJilfS0+5K6dccOcjQXmPw2WNmD7BO47Y5o IFZwqa60Ygcjui1+tl0aVR9BCoLW1aeVNUA1JDvwxcOdVJTBVHx56PlWh80NQO8jNUYt 0srg== X-Gm-Message-State: AFeK/H0gMv4TmnCjbsMlgSM5oEWQH8QvbEK4fy8I+KPxtTgoOVta1ow08tdpr2lA+u1/LsaQchhU+IJx+77FvQ== X-Received: by 10.107.58.131 with SMTP id h125mr27121421ioa.37.1489955369666; Sun, 19 Mar 2017 13:29:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sun, 19 Mar 2017 13:29:29 -0700 (PDT) In-Reply-To: <58ce02e3.833a6b0a.453fb.d824.GMRIR@mx.google.com> References: <20170315230723.GR1341@albert.catwhisker.org> <58ce02e3.833a6b0a.453fb.d824.GMRIR@mx.google.com> From: Roberto Rodriguez Jr Date: Sun, 19 Mar 2017 20:29:29 +0000 Message-ID: Subject: Re: Delivery Status Notification (Failure) To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 20:29:30 -0000 Hi all, My latest findings... Revision: 315577 Last Changed Author: ian Last Changed Rev: 315577 Last Changed Date: 2017-03-19 18:50:03 +0000 (Sun, 19 Mar 2017) FreeBSD krsna 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315577: Sun Mar 19 19:22:52 UTC 2017 # make -j5 buildworld --- libc.a --- ranlib -D libc.a --- libc.so.7.full --- /usr/bin/ld: _clock_nanosleep.pico: relocation R_X86_64_32 against `SYS_clock_nanosleep' can not be used when making a shared object; recompile with -fPIC _clock_nanosleep.pico: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7.full] Error code 1 make[4]: stopped in /usr/src/head/lib/libc 1 error From owner-freebsd-current@freebsd.org Sun Mar 19 20:52:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1430FD13F3E for ; Sun, 19 Mar 2017 20:52:54 +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-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B321C1997; Sun, 19 Mar 2017 20:52:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Sun, 19 Mar 2017 20:52:50 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.018; Sun, 19 Mar 2017 20:52:50 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZA== Date: Sun, 19 Mar 2017 20:52:50 +0000 Message-ID: References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> , <20170318032150.GW16105@kib.kiev.ua> In-Reply-To: <20170318032150.GW16105@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:s+Iv45gHx4CQWzDZjy5mhIG8H9z0Zi3ftLg8yW8CxqkanztdUdVZU1krJwSmlpvCwo9BB+lgkm670G8vjm/fdmQYw+vx8iOCrI9lVMFRgH9G/F/3CuXx1bUt+X6kQJUudtsbEN6c1SgmW0mPPYZF468FJAwwYdry/YWhqUMxHZVwNrOU9TCImUVbctULfIISY+nIEoZ8pifEEVtmI/6Z7N0le8CuGfnjnkMZvJnJjKlPATLowlYaAcbqX8bn3W43XDqO8zCQYWKPHc93pKtl6N47vMqDvey7Ctx5PukMwNyE+HDd/pzBkpk7HcgUBinRanAEdDtRV6Kctq1irVslMQ== x-ms-office365-filtering-correlation-id: 0b85209a-db9d-4891-c5a8-08d46f09e851 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 025100C802 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(39060400002)(54356999)(54906002)(6246003)(33656002)(86362001)(9686003)(81166006)(6506006)(55016002)(110136004)(77096006)(8676002)(122556002)(8936002)(5660300001)(38730400002)(76176999)(93886004)(305945005)(74316002)(53936002)(7696004)(3280700002)(6916009)(3660700001)(2950100002)(50986999)(2906002)(229853002)(1411001)(4326008)(6436002)(102836003)(189998001)(2900100001)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 19 Mar 2017 20:52:50.6442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 20:52:54 -0000 Kostik wrote: [stuff snipped] >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages= and >> >> async vm_object_page_clean() is called on the vnode' vm_object, we ge= t >> >> a bunch of delayed-write AKA dirty buffers. This is possible even af= ter >> >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving >> >> vfs_msync(). >> When I was talking about ncl_flush() above, I was referring to buffer ca= che >> buffers written by a write(2) syscall, not the case of mmap'd pages. > But dirty buffers can appear on the vnode queue due to dirty pages msynci= ng > by syncer, for instance. Ok, just to clarify this, in case I don't understand it... - You aren't saying that anything will be added to v_bufobj.bo_dirty.bv_hd = by vfs_msync() or similar, after VOP_CLOSE(), right? --> ncl_flush() { was called nfs_flush() in the old NFS client } only deals= with "struct buf's" hanging off v_bufobj.bo_dirty.bv_hd, so I don't see a u= se for it in the patch. As for pages added to v_bufobj.bo_object...the patch assumes that the proce= ss that was writing the executable file mmap'd is done { normally exited } bef= ore the exec() syscall occurs. If it is still dirtying pages when the exec() oc= curs, then failing with "Text file modified" seems correct to me. As you mentioned, an= other client can do this to the file anyhow. My understanding is that vm_object_page_clean() will get all the dirty page= s written back to the server at that point and if that is done in VOP_SET_TEXT() as t= his patch does, what more can the NFS client do? [more stuff snipped] > Syncer does not open the vnode inside the vfs_msync() operations. Ok, but this doesn't put "struct buf's" on v_bufobj.bo_dirty.bv_hd. Am I ri= ght? (When I said "buffers". I meant "struct buf's" under bo_dirty, not stuff un= der v_bufobj.bo_object.) > We do track writeability to the file, and do not allow execution if there= is > an active writer, be it a file descriptor opened for write, or a writeabl= e > mapping. And in reverse, if the file is executed (VV_TEXT is set), then > we disallow opening the file for write. Yes, and that was why I figured doing this in VOP_SET_TEXT(), just before setting VV_TEXT, was the right place to do it. [more stuff snipped] > > Thanks for testing the patch. Now, if others can test it...rick > Again, hopefully others (especially the original reporter) will be able to test the patch, rick From owner-freebsd-current@freebsd.org Sun Mar 19 21:14:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C9A8D12B5F for ; Sun, 19 Mar 2017 21:14:45 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 18E5CBE8; Sun, 19 Mar 2017 21:14:44 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 185-29-81-228.pool.digikabel.hu ([185.29.81.228] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cpi7k-0000Ft-SP; Sun, 19 Mar 2017 21:12:24 +0000 Subject: Re: process killed: text file modification To: Rick Macklem , Konstantin Belousov References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> Cc: Dimitry Andric , Ian Lepore , FreeBSD Current From: Gergely Czuczy Message-ID: <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> Date: Sun, 19 Mar 2017 22:12:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 19 Mar 2017 21:14:45 -0000 On 2017. 03. 19. 21:52, Rick Macklem wrote: > Kostik wrote: > [stuff snipped] >>>>> Dirty pages are flushed by writes, so if we have a set of dirty pages and >>>>> async vm_object_page_clean() is called on the vnode' vm_object, we get >>>>> a bunch of delayed-write AKA dirty buffers. This is possible even after >>>>> VOP_CLOSE() was done, e.g. by syncer performing regular run involving >>>>> vfs_msync(). >>> When I was talking about ncl_flush() above, I was referring to buffer cache >>> buffers written by a write(2) syscall, not the case of mmap'd pages. >> But dirty buffers can appear on the vnode queue due to dirty pages msyncing >> by syncer, for instance. > Ok, just to clarify this, in case I don't understand it... > - You aren't saying that anything will be added to v_bufobj.bo_dirty.bv_hd by > vfs_msync() or similar, after VOP_CLOSE(), right? > --> ncl_flush() { was called nfs_flush() in the old NFS client } only deals with > "struct buf's" hanging off v_bufobj.bo_dirty.bv_hd, so I don't see a use for > it in the patch. > > As for pages added to v_bufobj.bo_object...the patch assumes that the process > that was writing the executable file mmap'd is done { normally exited } before > the exec() syscall occurs. If it is still dirtying pages when the exec() occurs, then > failing with "Text file modified" seems correct to me. As you mentioned, another > client can do this to the file anyhow. > > My understanding is that vm_object_page_clean() will get all the dirty pages written > back to the server at that point and if that is done in VOP_SET_TEXT() as this patch > does, what more can the NFS client do? > > [more stuff snipped] >> Syncer does not open the vnode inside the vfs_msync() operations. > Ok, but this doesn't put "struct buf's" on v_bufobj.bo_dirty.bv_hd. Am I right? > (When I said "buffers". I meant "struct buf's" under bo_dirty, not stuff under > v_bufobj.bo_object.) > >> We do track writeability to the file, and do not allow execution if there is >> an active writer, be it a file descriptor opened for write, or a writeable >> mapping. And in reverse, if the file is executed (VV_TEXT is set), then >> we disallow opening the file for write. > Yes, and that was why I figured doing this in VOP_SET_TEXT(), just before > setting VV_TEXT, was the right place to do it. > [more stuff snipped] >> Thanks for testing the patch. Now, if others can test it...rick >> > Again, hopefully others (especially the original reporter) will be able to > test the patch, rick Actually I want to test it, but you guys are so vehemently discussing it, I thought it would be better to do so, once you guys settled your analysis on the code. Also, me not having the problem occurring, I don't think would mean it's solved, since that would only mean, the codepath for my specific usecase works. There might be other things there as well, what I don't hit. Let me know which patch should I test, and I will see to it in the next couple of days, when I get the time to do it. Regards, -czg From owner-freebsd-current@freebsd.org Mon Mar 20 13:15:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 958C3D13D58; Mon, 20 Mar 2017 13:15:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DB8B1239; Mon, 20 Mar 2017 13:15:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.15.239.37] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cpx9D-0002Kr-7r; Mon, 20 Mar 2017 14:14:55 +0100 Received: from localhost.my.domain (c720-r314251 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v2KDEqfX002499 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Mar 2017 14:14:52 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v2KDEo2t002498; Mon, 20 Mar 2017 14:14:50 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 20 Mar 2017 14:14:50 +0100 From: Matthias Apitz To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org Subject: debugging webcamd in CURRENT Message-ID: <20170320131450.GA2446@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.15.239.37 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 13:15:04 -0000 Hello, I have a very recent 12-CURRENT on amd64 (r314251) with all ports from beginning of March. While testing multimedia/webcamd in debug mode it says: # /usr/local/sbin/webcamd -i 0 -d ugen0.2 -U webcamd -G webcamd -H : USB HID core driver Linux video capture interface: v2.00 IR NEC protocol handler initialized IR RC5(x/sz) protocol handler initialized IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized IR SANYO protocol handler initialized IR LIRC bridge handler initialized IR XMP protocol handler initialized b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully uvcvideo: Unable to create debugfs directory ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ USB Video Class driver (1.1.1) cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1 pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner pvrusb2: Debug mask is 31 (0x1f) USBVision USB Video Device Driver for Linux : 0.9.11 em28xx: Registered (Em28xx v4l2 Extension) extension em28xx: Registered (Em28xx dvb Extension) extension Attached to ugen0.2[0] uvcvideo: Found UVC 1.00 device HD WebCam (1bcf:2c67) Waiting for HAL USB device. Creating /dev/video0 uvcvideo: Failed to submit URB 0 (-32). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Questions about this: 1. Why it is unable to create the debugfs directory? 2. The UVC driver in multimedia/webcamd/work/webcamd-4.8.0.4/media_tree/drivers/media/usb/uvc is from between 2013-2016, is there any more recent version? 3. Why is it sometimes failing with 'Failed to submit URB 0 (-32)'? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Mon Mar 20 13:22:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E9CFD142BC; Mon, 20 Mar 2017 13:22:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B6161B18; Mon, 20 Mar 2017 13:22:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 139BF1FE021; Mon, 20 Mar 2017 14:21:25 +0100 (CET) Subject: Re: debugging webcamd in CURRENT To: Matthias Apitz , freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org References: <20170320131450.GA2446@c720-r314251> From: Hans Petter Selasky Message-ID: Date: Mon, 20 Mar 2017 14:21:28 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170320131450.GA2446@c720-r314251> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 13:22:29 -0000 On 03/20/17 14:14, Matthias Apitz wrote: > > Hello, > > I have a very recent 12-CURRENT on amd64 (r314251) with all ports from beginning > of March. > > While testing multimedia/webcamd in debug mode it says: > > # /usr/local/sbin/webcamd -i 0 -d ugen0.2 -U webcamd -G webcamd -H > : USB HID core driver > Linux video capture interface: v2.00 > IR NEC protocol handler initialized > IR RC5(x/sz) protocol handler initialized > IR RC6 protocol handler initialized > IR JVC protocol handler initialized > IR Sony protocol handler initialized > IR SANYO protocol handler initialized > IR LIRC bridge handler initialized > IR XMP protocol handler initialized > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully > uvcvideo: Unable to create debugfs directory > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > USB Video Class driver (1.1.1) > cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1 > pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner > pvrusb2: Debug mask is 31 (0x1f) > USBVision USB Video Device Driver for Linux : 0.9.11 > em28xx: Registered (Em28xx v4l2 Extension) extension > em28xx: Registered (Em28xx dvb Extension) extension > Attached to ugen0.2[0] > uvcvideo: Found UVC 1.00 device HD WebCam (1bcf:2c67) > Waiting for HAL USB device. > Creating /dev/video0 > uvcvideo: Failed to submit URB 0 (-32). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Questions about this: > > 1. Why it is unable to create the debugfs directory? > 2. The UVC driver in > multimedia/webcamd/work/webcamd-4.8.0.4/media_tree/drivers/media/usb/uvc > is from between 2013-2016, is there any more recent version? > 3. Why is it sometimes failing with 'Failed to submit URB 0 (-32)'? > Hi, The latest version is in ports. You can compile webcamd with debugging. Then there are some options listed by "webcamd -s" which you can turn on using "webcamd -m xxx=yyy" to get more verbose debugging. You can also try starting "usbdump -i usbusX -f Y -s 65536" where X and Y are numbers after ugen, before plugging the device, to see which USB errors are happening. --HPS --HPS From owner-freebsd-current@freebsd.org Mon Mar 20 18:22:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2A16D14B60 for ; Mon, 20 Mar 2017 18:22:24 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D1DC1F67 for ; Mon, 20 Mar 2017 18:22:24 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ON400E00LO5CQ00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Mon, 20 Mar 2017 18:22:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490034138; bh=XkkfutOtdjuAooh5u+WCiRvGt7Hea11yxibTT90FtrM=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=JCu84AT4cVVWuBjSkEKxQOsNUI7J7EubRyEPSl+cI1QhmxhKtMvQcVkQeSPT8zOAl BPOE0UYJJspFDxLZ6sVtTE7zGrZEUT94bY/Ll0YlgKrgDs1V0stzVtWXcb6cNt5R8/ ot96l3pkskFFIIBtIhh8RRV39q5G6w9eAYO+mfTE1v7sgel6/ITEqf3JLtx3F6l2u7 5EBL39XadJ9LXjHtfK8Hzg7TbdF/LEvDfWqnxSSyQATO7H0NXoThZF+NHMDQH/GmE2 tfnW354fQjpgKtMYCa3ybrApiOgb9UPum2pkGtglVjR2vpAfPIuXEVbFAOA8VyQPbz MY+yR4WQMuIAw== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ON400CQSLP1CF10@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Mon, 20 Mar 2017 18:22:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-20_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703200156 From: Toomas Soome MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: NFSv2 boot & OLD_NFSV2 Message-id: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> Date: Mon, 20 Mar 2017 20:22:12 +0200 To: FreeBSD Current X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 18:22:24 -0000 Hi! The current boot code is building NFSv3, with preprocessor conditional = OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it? rgds, toomas= From owner-freebsd-current@freebsd.org Mon Mar 20 18:24:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4BD6D14C70; Mon, 20 Mar 2017 18:24:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EF8D1167; Mon, 20 Mar 2017 18:24:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x232.google.com with SMTP id w124so97811007itb.1; Mon, 20 Mar 2017 11:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BlUsS+b6Dfjc2aBYNBGujw5w3vzF1qocTmZJqV/HB+A=; b=VmO630TOfHkmkPo6kO0oKZJ93ZzKgvNrym7ZaxaTnVZ6rk3PlmhXA2dzda7Cmd/Qlq Jy8M1u1jh8jV63yKIK17tx9zCxMEELwQ5bpJLMdNLV7NPJ4Jg4byLmfiZokCPBkaut+X dCSFzJvmBVRHEYolRbsmgThvDKuoWC0XF77Wzz7f5Gc0qY5j9OQopfZMTlIIifAFJbAw wn60g3MkO6pIEwKF9s7Qm6imKdxCz5xmzPHtfJBLieP7YpU+AYXYrhNutyYjovAd3ZT8 z4QjZ7Yv5lrYu7jGpyvnzLxq2dOpMMU23hXmV6fY/x2tA6Lqf7/Wm62QGTgUWeZhfv+f wbLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BlUsS+b6Dfjc2aBYNBGujw5w3vzF1qocTmZJqV/HB+A=; b=WwTAZu0Au++SM09MJuL5GKrBkWBhj8b+3g3O2CWfGNOfefgslouL6e0nNoU6pcCV7n 73+1tEXiS1RgWjAo5L37yNJ6IFZzqvIcvcS4v3MclfPRR8eFT45ukS1JmnrW0E01Afaf 2QmVFrZ6zM+Pe2VGjsTFXBOIYoTuuZdcAL6xlHRzgOHMF8gQq1xlnzJ9uoycGhIBsLJ+ oVsvwo8ltaQyx41yzQMF1rToEWIuY7MVXzoEXgpOj7xBRv9NdSWY7Qii1ceVedlTeDZs fM8FFYBfhezhUmRZSw5DDqtOnVMnIiMh7hFIWzijyTC+yMF203f96EedII7rg8zUW+zI NGFw== X-Gm-Message-State: AFeK/H2HbnP6SLDZWoq0eB2QGWeZCdTzNQOC91KVdRJ1eww0Y5bbwEg7eoGeqYEuPv9noO+TWUkqcFaMAl/qwg== X-Received: by 10.107.201.196 with SMTP id z187mr34016124iof.172.1490034256422; Mon, 20 Mar 2017 11:24:16 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.30.209 with HTTP; Mon, 20 Mar 2017 11:23:55 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Mon, 20 Mar 2017 14:23:55 -0400 X-Google-Sender-Auth: BY6YRDD0NGiabw5Gp8LotJzTNNk Message-ID: Subject: Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm To: Adrian Chadd Cc: "freebsd-mips@freebsd.org" , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 18:24:17 -0000 On 19 March 2017 at 03:00, Adrian Chadd wrote: > gcc version 5.3.0 (FreeBSD Ports Collection for mips) > > ... so uhm, why are we building libllvm? As of the Clang 4.0.0 import we build Clang by default, on all architectures other than those unsupported by Clang, if the cross-compiler supports C++11. I'm not sure if the issue you encountered here is in libllvm or GCC. For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in /etc/src.conf. From owner-freebsd-current@freebsd.org Mon Mar 20 19:20:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F875D14DDE for ; Mon, 20 Mar 2017 19:20:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2ADAA11F1; Mon, 20 Mar 2017 19:20:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 7D279631E; Mon, 20 Mar 2017 19:20:00 +0000 (UTC) Date: Mon, 20 Mar 2017 20:20:00 +0100 From: Baptiste Daroussin To: Toomas Soome Cc: FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 Message-ID: <20170320192000.6hal22ibnr3ajog3@ivaldir.net> References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6fmt6pamuwesqyh2" Content-Disposition: inline In-Reply-To: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 19:20:01 -0000 --6fmt6pamuwesqyh2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: > Hi! >=20 > The current boot code is building NFSv3, with preprocessor conditional OL= D_NFSV2. Should NFSv2 code still be kept around or can we burn it? >=20 > rgds, > toomas I vote burn Bapt --6fmt6pamuwesqyh2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAljQK1kACgkQY4mL3PG3 Plq+VBAA4z1TJdreMlLUjqCTKwl2QkU1zgW9b94mPKfn05ZILe1ROzzZc07bOeHj GoZqej7bgdUTzp4MB/JmFxOiR7t+cDXjTQ22XNzkU05RB1xmXFr8a5xrCHdBKbXu /zYo7lDeYeXInzZ+SMKTpUAuWLNSjJ84tCNEd814ma+FzWZ8c/Wz016HerPhrBqB kV7MzZBZuX6aYgfnqI0JJnx61G1ERPydvkdAm+IwOpXiF+s7Rh8LrS525L189ide ijLOgFDBmfwpWID6J3yqK0QTo2uwyKr90/F0B4tAOPshhKX9ChAJhFVCA2gNtfmD Iywmin4CE2cVvWZWV8UVbEMtl953PxoRPD/FzH0mGWToEeIzl5EDxhtqKbPs21Jy EaItw2S0s2NFsUwtwtOkdIOHkwCaEEz0fS03Ri9CwRIU0yP5Tn5wqjeqL41VPrOc kfBUwxqeelGOZJjfGAZtSvdoeHUzeZyq5mkS4Sa450t1GbuLHbRg+eJh/FCucSO8 Dx6NvJ3Ix751Vy+6MzkMpTHT/HhEdYGNhag3r2zSJUqxGGNnijybNSRdBX70UT79 XDtYJ8yFS+2a4YlKurPROsMQRcXgzEgRVFlltF+jdxWo4ylagLniJ3yiaiEFZT7U J2OZgN/YCcqguru8yJ0HCTRZ0/MrVfshe4+r9EUsFcZSqHgFblE= =Ktz8 -----END PGP SIGNATURE----- --6fmt6pamuwesqyh2-- From owner-freebsd-current@freebsd.org Mon Mar 20 21:53:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0058D1320E for ; Mon, 20 Mar 2017 21:53:38 +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-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 613881823; Mon, 20 Mar 2017 21:53:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Mon, 20 Mar 2017 21:53:35 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.019; Mon, 20 Mar 2017 21:53:35 +0000 From: Rick Macklem To: Baptiste Daroussin , Toomas Soome CC: FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 Thread-Topic: NFSv2 boot & OLD_NFSV2 Thread-Index: AQHSoabzN3fGlEoBW0OV/vmFdatswaGeGqEAgAAonNo= Date: Mon, 20 Mar 2017 21:53:35 +0000 Message-ID: References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com>, <20170320192000.6hal22ibnr3ajog3@ivaldir.net> In-Reply-To: <20170320192000.6hal22ibnr3ajog3@ivaldir.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:/9+1AewgYnDxi4ypyKW8SPcTZaISG+5jDWk2Wp9JV+QI7lasxusWggsVaCjUgTtB2GtCjlshuaqaLLRP8TapzayBrMvmFiP50lMxO5eF/UnBx2sNKzEGBcmVxB4u3UeS7LrsmAlaaJvRnWtOsQ9dpzSFGfu9E9oyPMMejzHvydUiUzoGXl1hF8UiHWQ32aKdM9EAYeUyzKrIXz6RuW+O4PypltryaENni2/W+Goj9aExzasPWbywhb3Oqel7bWjeI+PyxvacHSmDTLgwQqSFRERsfWFuT+OFCUWc/PbhROfLt45+FkskpTfTZ6dUMPUuyFJhTP4k5PwLr2pMFiIsfA== x-ms-office365-filtering-correlation-id: b62b4c6f-3544-4f17-766b-08d46fdb8f47 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(106356001)(5660300001)(38730400002)(39060400002)(8656002)(77096006)(6436002)(6246003)(53936002)(4326008)(9686003)(6506006)(2906002)(55016002)(86362001)(74316002)(3660700001)(102836003)(3280700002)(305945005)(74482002)(189998001)(2950100002)(7696004)(2900100001)(229853002)(50986999)(54356999)(76176999)(122556002)(33656002)(81166006)(8676002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 20 Mar 2017 21:53:35.7137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 21:53:38 -0000 Baptiste Daroussin wrote: > On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: > > Hi! > > > > The current boot code is building NFSv3, with preprocessor conditional = OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it? > > > > rgds, > > toomas > > I vote burn > > Bapt I would be happy to see NFSv2 go away. However, depending on how people con= figure their diskless root fs, they do end up using NFSv2 for their root fs. Does booting over NFSv3 affect this? I think the answer is no for a FreeBSD server (since the NFSv2 File Handle = is the same as the NFSv3 one, except padded with 0 bytes to 32bytes long). However, there might be non-FreeBSD NFS servers where the NFSv2 file handle= is different than the NFSv3 one and for that case, the user would need NFSv2 boot code (= or reconfigure their root fs to use NFSv3). To be honest, I suspect few realize that they are using NFSv2 for their roo= t fs. (They'd see it in a packet trace or via "nfsstat -m", but otherwise they pr= obably think they are using NFSv3 for their root fs.) rick= From owner-freebsd-current@freebsd.org Mon Mar 20 21:55:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF652D1345F for ; Mon, 20 Mar 2017 21:55:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B90271B14; Mon, 20 Mar 2017 21:55:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ON400D00V5AF600@st13p35im-asmtp002.me.com>; Mon, 20 Mar 2017 21:55:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490046944; bh=O6SAKKYHv+r60WgH9pObO5b7Zn9iRnlhutwMToiJd+0=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Qp2yopjiLL4r62B05+ANR1DOOO/T7fWp7AN+/Z0y9m9yYLZJulc2IZfbsdyWo+4/9 n4JQ7dkihO5hJ0RELc4ijh4KcScwsuvh2XH5xJWD+ZVPPfLEoj1++U4dsInRLDb7yz onllYABZyNu30Bg8ZJvPvWOGN+99zEbLyuUgsg+mwsfH5hnuqamlvuJW0uoRnTtq1s Uu0+To+Wkc+Nm53XMuDM6omHqyBtzTIYYP9VfXa37GYm1ybzuV5GPOBTKiG8fTz/uT gHzusLLdhCLRNlTcIMYZKu4mH0Mxldc4INci5/tzGZ43dsmifBFMh6HR5Q1WgKn+rM eXZBckv7eLHMQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ON4000J7VKUF240@st13p35im-asmtp002.me.com>; Mon, 20 Mar 2017 21:55:44 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-20_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703200186 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 From: Toomas Soome In-reply-to: Date: Mon, 20 Mar 2017 23:55:41 +0200 Cc: Baptiste Daroussin , FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> To: Rick Macklem X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 21:55:51 -0000 > On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem = wrote: >=20 > Baptiste Daroussin wrote: >> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>> Hi! >>>=20 >>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>=20 >>> rgds, >>> toomas >>=20 >> I vote burn >>=20 >> Bapt > I would be happy to see NFSv2 go away. However, depending on how = people configure > their diskless root fs, they do end up using NFSv2 for their root fs. >=20 > Does booting over NFSv3 affect this? >=20 > I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as > the NFSv3 one, except padded with 0 bytes to 32bytes long). > However, there might be non-FreeBSD NFS servers where the NFSv2 file = handle is different > than the NFSv3 one and for that case, the user would need NFSv2 boot = code (or > reconfigure their root fs to use NFSv3). >=20 > To be honest, I suspect few realize that they are using NFSv2 for = their root fs. > (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably > think they are using NFSv3 for their root fs.) >=20 > rick if they do not suspect, they most likely use v3 - due to simple fact = that you have to rebuild loader to use NFSv2 - it is compile time = option. rgds, toomas= From owner-freebsd-current@freebsd.org Mon Mar 20 21:58:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE4F1D1355C for ; Mon, 20 Mar 2017 21:58:17 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91A931CB4 for ; Mon, 20 Mar 2017 21:58:17 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2KLwLvd052756 for ; Mon, 20 Mar 2017 14:58:27 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: Are textmode consoles/terminals still supported? Date: Mon, 20 Mar 2017 14:58:27 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 21:58:17 -0000 I'm attempting to get a video card that DTRT on FreeBSD. I started with the graphics provided by an AMD A6-7470K, only to discover it's not yet supported. So I forked out for a recent nvidia card, and build/installed a new world/kernel. Everything seemed to be as one would expect, except there was an issue with loader.efi. So I had to move mine aside, and use the one off the install media (tho I understand the (u)efi has since been fixed). Now, I'm attempting to obtain textmode. The text stripped from a tty, and pasted to a new file in a textmode editor -- ee(1) for example; pads the line with spaces to EOL, and prefaces each line following the first line with rubbish (about 1 to 2 characters worth). So "graphics mode" or vt(4) isn't going to get it, for me. Textmode, and syscons(4) has always worked as expected, and I thought I'd try to re-enable it, or get textmode via vt(4). But all attempts fail. excerpt from my KERNCONF device vga options VESA device sc options SC_PIXEL_MODE device vt device vt_vga device vt_efifb However, following the advice on the freebsd wiki, querying the value in sysctl(8) returns: # sysctl hw.vga.textmode sysctl: unknown oid 'hw.vga.textmode' OK how bout vidcontrol(1) # vidcontrol -i adapter vidcontrol: obtaining adapter information: Inappropriate ioctl for device So, it appears from my standpoint that textmode is no longer supported? FWIW: FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: Sun Mar 5 09:01:30 PST 2017 root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 Thank you for anything that might help me obtain textmode again. --Chris From owner-freebsd-current@freebsd.org Mon Mar 20 22:02:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAECDD13930 for ; Mon, 20 Mar 2017 22:02:09 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5E512C6 for ; Mon, 20 Mar 2017 22:02:09 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x232.google.com with SMTP id n11so75407276wma.0 for ; Mon, 20 Mar 2017 15:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=KleOoh7atuzbX+989cqpjXP014iyjpSa0Kc0UHaFVpI=; b=l/E2FR6Ez69ln/NNhHSjSwhkzP0Ik/bdMLSBvMHaNidxyVJHG5DBmImLYnnGD+Xyvj Vr6mUjgH4gaff7pT8qVyNpWz3kz6zM05qgZDTiRztAxcuiQ59Ypu3vTrm8dyJuobV2TR 0XakUDvziN8nvg2v6pdAMX5XvT5s3IX5lFcmuSZr04GnDIUq44quJ7P24jU0icxkgYiH /S6AFGYSvOVGUYXYGmrMeVc+RCnQf7PdzxKJhT3f0hqCDDsuWI+slyvwPc/Jl/WI6zpr /98AzM9APQntFAieio8mWeEmLEGz/OJlkaIANWKwjT25ZmcgO4RQcdliri3ssZhaLm2K 1W5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=KleOoh7atuzbX+989cqpjXP014iyjpSa0Kc0UHaFVpI=; b=GYE4ok+5hxmLOWWJXVTC0/kTGzizzLkXek8iYIeRogm6xMHSGF03yWjyYstQFVeOwg bUoRZqKXx7aJLN6xqXGjiL7HPr/pUXtv/zOP04q5nHVnWkMd4elh4alOEGtO9aSt6gWU FbJpHluWzlS47Vk1cn9bl7Kzvhfyg0sqXquDbkhlnz3HWTSxU1V5qFtMbVINog9W/OD1 5t2ZveLeRBHkahklPEhSaGmV0CBZZko7t25KOUT8XmsMno92dXYAYANqKT9kWMvd2xaA xqorlF/yhOhgxXKfAWT9yHt0S3HBn4PBUgbMcd+El+7cfpQCKMGQx607k5+QvKUdHFAl GohQ== X-Gm-Message-State: AFeK/H3LEaru75zqy3HTG657Wvn5rHtWhZuIfdSVqmabcTrx4elkJ6z0cRgXI7MhAAZv8RLI X-Received: by 10.28.19.207 with SMTP id 198mr11544548wmt.49.1490047327397; Mon, 20 Mar 2017 15:02:07 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id j34sm22175774wre.7.2017.03.20.15.02.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 15:02:06 -0700 (PDT) Subject: Re: Are textmode consoles/terminals still supported? To: freebsd-current@freebsd.org References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> From: Steven Hartland Message-ID: <4c0a947f-34b3-2188-269d-8b79286700b2@multiplay.co.uk> Date: Mon, 20 Mar 2017 22:02:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 22:02:09 -0000 Add the following to /boot/loader.conf Its a tunable but not a sysctl so you can't query it, you just need to set it by adding it to /boot/loader.conf: hw.vga.textmode="1" On 20/03/2017 21:58, Chris H wrote: > I'm attempting to get a video card that DTRT on FreeBSD. > I started with the graphics provided by an AMD A6-7470K, > only to discover it's not yet supported. So I forked out > for a recent nvidia card, and build/installed a new > world/kernel. > Everything seemed to be as one would expect, except there > was an issue with loader.efi. So I had to move mine aside, > and use the one off the install media (tho I understand > the (u)efi has since been fixed). Now, I'm attempting to > obtain textmode. The text stripped from a tty, and pasted > to a new file in a textmode editor -- ee(1) for example; > pads the line with spaces to EOL, and prefaces each line > following the first line with rubbish (about 1 to 2 > characters worth). > So "graphics mode" or vt(4) isn't going to get it, for me. > Textmode, and syscons(4) has always worked as expected, and > I thought I'd try to re-enable it, or get textmode via vt(4). > But all attempts fail. > excerpt from my KERNCONF > > device vga > options VESA > > device sc > options SC_PIXEL_MODE > > device vt > device vt_vga > device vt_efifb > > However, following the advice on the freebsd wiki, querying > the value in sysctl(8) returns: > # sysctl hw.vga.textmode > sysctl: unknown oid 'hw.vga.textmode' > > OK how bout vidcontrol(1) > # vidcontrol -i adapter > vidcontrol: obtaining adapter information: Inappropriate ioctl for device > > So, it appears from my standpoint that textmode is no longer > supported? > > FWIW: > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > Sun Mar 5 09:01:30 PST 2017 > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 > > Thank you for anything that might help me obtain textmode again. > > --Chris > > > _______________________________________________ > 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 Mar 20 22:09:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6890D13DC1 for ; Mon, 20 Mar 2017 22:09:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F619175D for ; Mon, 20 Mar 2017 22:09:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ON400200W1MRQ00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Mon, 20 Mar 2017 22:09:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490047749; bh=R4mG0amDhOYhko/2szjD6PoOLmak7vdlRZcE95BSX34=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=dbRmxwPZxqN4/CyifcQif3EqGiYO1DaKT1ZSEeiHu334nHqAcUSA9FNmat9m4jlRF mIESQUFKlksFvf49N1AkDrfrIwQiXMGkzoq6XH6ey8EcNii2yx06BW3KaL1Ri/2zj2 tktt5NIXrPrAvTW4jJyDx0lyNcmTnriWybpjIEETMntFa52j0gwg2mn5t29R5E+UI9 fldi61g5BNISnS1Vcn2q+chZpyFFb/rYKxaaCM6crrpQQDjoP1HOUF9+FpP2ZAa56A azvsOXhfxfM6qqNe5H5GonhoBwdBHmyqYCP9t+KlODHJLeb/mbwbSeKpC/HYV38jh3 qCjQ/AK5YkqTQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ON400BKWW760540@st13p35im-asmtp002.me.com>; Mon, 20 Mar 2017 22:09:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-20_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703200188 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Are textmode consoles/terminals still supported? From: Toomas Soome In-reply-to: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> Date: Tue, 21 Mar 2017 00:09:06 +0200 Cc: FreeBSD CURRENT Content-transfer-encoding: quoted-printable Message-id: References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 22:09:10 -0000 > On 20. m=C3=A4rts 2017, at 23:58, Chris H = wrote: >=20 > I'm attempting to get a video card that DTRT on FreeBSD. > I started with the graphics provided by an AMD A6-7470K, > only to discover it's not yet supported. So I forked out > for a recent nvidia card, and build/installed a new > world/kernel. > Everything seemed to be as one would expect, except there > was an issue with loader.efi. So I had to move mine aside, > and use the one off the install media (tho I understand > the (u)efi has since been fixed). Now, I'm attempting to > obtain textmode. The text stripped from a tty, and pasted > to a new file in a textmode editor -- ee(1) for example; > pads the line with spaces to EOL, and prefaces each line > following the first line with rubbish (about 1 to 2 > characters worth). > So "graphics mode" or vt(4) isn't going to get it, for me. > Textmode, and syscons(4) has always worked as expected, and > I thought I'd try to re-enable it, or get textmode via vt(4). > But all attempts fail. > excerpt from my KERNCONF >=20 > device vga > options VESA >=20 > device sc > options SC_PIXEL_MODE >=20 > device vt > device vt_vga > device vt_efifb >=20 > However, following the advice on the freebsd wiki, querying > the value in sysctl(8) returns: > # sysctl hw.vga.textmode > sysctl: unknown oid 'hw.vga.textmode' >=20 > OK how bout vidcontrol(1) > # vidcontrol -i adapter > vidcontrol: obtaining adapter information: Inappropriate ioctl for = device >=20 > So, it appears from my standpoint that textmode is no longer > supported? >=20 > FWIW: > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 = r314700: > Sun Mar 5 09:01:30 PST 2017 > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 >=20 > Thank you for anything that might help me obtain textmode again. >=20 > - The problem with UEFI is that the fact if you can only get =E2=80=9Ctext=E2= =80=9D aka VGA text mode if your card happens to have the proper = firmware and you can set up the card=E2=80=A6 UEFI as such does only = provide framebuffer based console, and that framebuffer is either linear = memory mapped or pure software - in last case only KMS console = framebuffer will do any good. rgds, toomas From owner-freebsd-current@freebsd.org Mon Mar 20 22:18:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83A18D13FEC for ; Mon, 20 Mar 2017 22:18:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 138701C15; Mon, 20 Mar 2017 22:18:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2KMIIVa044555 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 00:18:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2KMIIVa044555 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2KMIIku044554; Tue, 21 Mar 2017 00:18:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Mar 2017 00:18:18 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170320221818.GM43712@kib.kiev.ua> References: <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 22:18:24 -0000 On Sun, Mar 19, 2017 at 08:52:50PM +0000, Rick Macklem wrote: > Kostik wrote: > [stuff snipped] > >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages and > >> >> async vm_object_page_clean() is called on the vnode' vm_object, we get > >> >> a bunch of delayed-write AKA dirty buffers. This is possible even after > >> >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving > >> >> vfs_msync(). > >> When I was talking about ncl_flush() above, I was referring to buffer cache > >> buffers written by a write(2) syscall, not the case of mmap'd pages. > > But dirty buffers can appear on the vnode queue due to dirty pages msyncing > > by syncer, for instance. > Ok, just to clarify this, in case I don't understand it... > - You aren't saying that anything will be added to v_bufobj.bo_dirty.bv_hd by > vfs_msync() or similar, after VOP_CLOSE(), right? Yes, I have to somewhat retract my claims, but then I have another set of surprises. I realized (remembered) that nfs has its own VOP_PUTPAGES() method. Implementation seems to directly initiate write RPC request using the pages as the source buffer. I do not see anything in the code which would mark the buffers, which possibly contain the pages, as clean, or mark the buffer range as undirty. At very least, this might cause unnecessary double-write of the same data. I am not sure if it could cause coherency issues between data written using mappings and write(2). Also, both vm_object_page_clean() and vfs_busy_pages() only ensure the shared-busy state on the pages, so write(2) can occur while pageout sends data to server, causing 'impossible' content transmitted over the wire. Could you, please, explain the reasons for such implementation of ncl_putpage() ? > --> ncl_flush() { was called nfs_flush() in the old NFS client } only deals with > "struct buf's" hanging off v_bufobj.bo_dirty.bv_hd, so I don't see a use for > it in the patch. > > As for pages added to v_bufobj.bo_object...the patch assumes that the > process that was writing the executable file mmap'd is done { normally > exited } before the exec() syscall occurs. If it is still dirtying > pages when the exec() occurs, then failing with "Text file modified" > seems correct to me. As you mentioned, another client can do this to > the file anyhow. > > My understanding is that vm_object_page_clean() will get all the dirty > pages written back to the server at that point and if that is done in > VOP_SET_TEXT() as this patch does, what more can the NFS client do? > > [more stuff snipped] > > Syncer does not open the vnode inside the vfs_msync() operations. > Ok, but this doesn't put "struct buf's" on v_bufobj.bo_dirty.bv_hd. Am I right? > (When I said "buffers". I meant "struct buf's" under bo_dirty, not stuff under > v_bufobj.bo_object.) > > > We do track writeability to the file, and do not allow execution if there is > > an active writer, be it a file descriptor opened for write, or a writeable > > mapping. And in reverse, if the file is executed (VV_TEXT is set), then > > we disallow opening the file for write. > Yes, and that was why I figured doing this in VOP_SET_TEXT(), just before > setting VV_TEXT, was the right place to do it. > [more stuff snipped] > > > > Thanks for testing the patch. Now, if others can test it...rick > > > Again, hopefully others (especially the original reporter) will be able to > test the patch, rick From owner-freebsd-current@freebsd.org Mon Mar 20 23:06:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78777D150AF for ; Mon, 20 Mar 2017 23:06:34 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6DF19E1 for ; Mon, 20 Mar 2017 23:06:33 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2KN6b1P059608 for ; Mon, 20 Mar 2017 16:06:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <4c0a947f-34b3-2188-269d-8b79286700b2@multiplay.co.uk> References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net>, <4c0a947f-34b3-2188-269d-8b79286700b2@multiplay.co.uk> From: "Chris H" Subject: Re: Are textmode consoles/terminals still supported? Date: Mon, 20 Mar 2017 16:06:43 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <1b87a24bfc5450f4af5bdbcfcb534e30@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 23:06:34 -0000 On Mon, 20 Mar 2017 22:02:06 +0000 Steven Hartland wrote > Add the following to /boot/loader.conf > > Its a tunable but not a sysctl so you can't query it, you just need to > set it by adding it to /boot/loader.conf: > hw.vga.textmode="1" > WOW. Thanks for the fast reply! I gave your suggestion a try. But it was ignored. :-( All my other boxes run the nvidia blob, and provide textmode, and support sc/syscons(4). But I'm not using (u)efi on them. Maybe that's the trouble? Thanks again, Steven! --Chris > On 20/03/2017 21:58, Chris H wrote: > > I'm attempting to get a video card that DTRT on FreeBSD. > > I started with the graphics provided by an AMD A6-7470K, > > only to discover it's not yet supported. So I forked out > > for a recent nvidia card, and build/installed a new > > world/kernel. > > Everything seemed to be as one would expect, except there > > was an issue with loader.efi. So I had to move mine aside, > > and use the one off the install media (tho I understand > > the (u)efi has since been fixed). Now, I'm attempting to > > obtain textmode. The text stripped from a tty, and pasted > > to a new file in a textmode editor -- ee(1) for example; > > pads the line with spaces to EOL, and prefaces each line > > following the first line with rubbish (about 1 to 2 > > characters worth). > > So "graphics mode" or vt(4) isn't going to get it, for me. > > Textmode, and syscons(4) has always worked as expected, and > > I thought I'd try to re-enable it, or get textmode via vt(4). > > But all attempts fail. > > excerpt from my KERNCONF > > > > device vga > > options VESA > > > > device sc > > options SC_PIXEL_MODE > > > > device vt > > device vt_vga > > device vt_efifb > > > > However, following the advice on the freebsd wiki, querying > > the value in sysctl(8) returns: > > # sysctl hw.vga.textmode > > sysctl: unknown oid 'hw.vga.textmode' > > > > OK how bout vidcontrol(1) > > # vidcontrol -i adapter > > vidcontrol: obtaining adapter information: Inappropriate ioctl for device > > > > So, it appears from my standpoint that textmode is no longer > > supported? > > > > FWIW: > > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > r314700: Sun Mar 5 09:01:30 PST 2017 > > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 > > > > Thank you for anything that might help me obtain textmode again. > > > > --Chris > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Mar 20 23:18:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71A9CD155DA for ; Mon, 20 Mar 2017 23:18:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA2D6B2 for ; Mon, 20 Mar 2017 23:18:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2KNIZfF060972 for ; Mon, 20 Mar 2017 16:18:41 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net>, From: "Chris H" Subject: Re: Are textmode consoles/terminals still supported? Date: Mon, 20 Mar 2017 16:18:41 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 20 Mar 2017 23:18:31 -0000 On Tue, 21 Mar 2017 00:09:06 +0200 Toomas Soome wrote > > On 20. märts 2017, at 23:58, Chris H wrote: > > > > I'm attempting to get a video card that DTRT on FreeBSD. > > I started with the graphics provided by an AMD A6-7470K, > > only to discover it's not yet supported. So I forked out > > for a recent nvidia card, and build/installed a new > > world/kernel. > > Everything seemed to be as one would expect, except there > > was an issue with loader.efi. So I had to move mine aside, > > and use the one off the install media (tho I understand > > the (u)efi has since been fixed). Now, I'm attempting to > > obtain textmode. The text stripped from a tty, and pasted > > to a new file in a textmode editor -- ee(1) for example; > > pads the line with spaces to EOL, and prefaces each line > > following the first line with rubbish (about 1 to 2 > > characters worth). > > So "graphics mode" or vt(4) isn't going to get it, for me. > > Textmode, and syscons(4) has always worked as expected, and > > I thought I'd try to re-enable it, or get textmode via vt(4). > > But all attempts fail. > > excerpt from my KERNCONF > > > > device vga > > options VESA > > > > device sc > > options SC_PIXEL_MODE > > > > device vt > > device vt_vga > > device vt_efifb > > > > However, following the advice on the freebsd wiki, querying > > the value in sysctl(8) returns: > > # sysctl hw.vga.textmode > > sysctl: unknown oid 'hw.vga.textmode' > > > > OK how bout vidcontrol(1) > > # vidcontrol -i adapter > > vidcontrol: obtaining adapter information: Inappropriate ioctl for device > > > > So, it appears from my standpoint that textmode is no longer > > supported? > > > > FWIW: > > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > r314700: Sun Mar 5 09:01:30 PST 2017 > > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 > > > > Thank you for anything that might help me obtain textmode again. > > > > - > > The problem with UEFI is that the fact if you can only get “text†aka VGA > text mode if your card happens to have the proper firmware and you can set up > the card… UEFI as such does only provide framebuffer based console, and > that framebuffer is either linear memory mapped or pure software - in last > case only KMS console framebuffer will do any good. Thanks for the reply, Toomas. I'm running the nvidia blob from the ports tree, version 375.26_1. Am I to understand it doesn't support textmode through (u)efi? All my other boxes also use the nvidia blob, and provide textmode, along with sc/syscons(4) support. But I'm not booting (u)efi on them either. So I guess (u)efi / vt(4) are to blame? My card is pretty recent. I'd think that it would support all the bells, and whistles. But then again... ;-) Oh well, I guess I don't have to use (u)efi. Thanks again, Toomas! --Chris > > rgds, > toomas > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 21 02:08:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA7CDD144B3 for ; Tue, 21 Mar 2017 02:08:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E52718A for ; Tue, 21 Mar 2017 02:08:30 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L28Z68083833 for ; Mon, 20 Mar 2017 19:08:41 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: why are the GEOM secondary GPT tables always corrupt? Date: Mon, 20 Mar 2017 19:08:41 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 02:08:31 -0000 I've seen this discussed before, but there were so many "solutions", I was left feeling this *must* be some sort of bug in GEOM/gpart. So. I just blew away the tables on a USB3 flash drive: # gpart destroy -F da0 # gpart create -s gpt da0 # gpart add -t freebsd-ufs -l jails da0 # newfs -U /dev/gpt/jails Added an entry to fstab(5) OK this should be good to go. Mount, and umount all return as expected, as does fsck(8). Upon reboot, I receive the following: /dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0% fragmentation) GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery suggested. But why? This is on: FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64 Thanks for any information. --Chris From owner-freebsd-current@freebsd.org Tue Mar 21 02:30:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61FBFD1587A for ; Tue, 21 Mar 2017 02:30:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660074.outbound.protection.outlook.com [40.107.66.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C1471455; Tue, 21 Mar 2017 02:30:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 02:30:38 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 02:30:38 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIABrxcAgAA8zEM= Date: Tue, 21 Mar 2017 02:30:38 +0000 Message-ID: References: <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> , <20170320221818.GM43712@kib.kiev.ua> In-Reply-To: <20170320221818.GM43712@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:MHz/1tiap2wIJadui6svjVdhswddtE4XuOIuLteBJQzzODEFsx++9gF9XAVZo0G3Kgn0YbUX8CbaoJsBI9/6ThBceR44FecibOuDMNPJ/vSfWrtzbitdAwynzpw1NYFT5OT6AzSemofHPkVLZ+W2PRJKTpErx3LCd9oPT/Am7aHtD8ET083CiO6b84aX8MVDS2cGlBHgrrG/hwbJ8OmqcbfQMS8WYMRlSY54GzJuwae7mMK4bVB/N5pBi6YExmhEvb/iCuQqFsLJFeudDBGAIiLqiexGmXJBwiG34dgiziEGCnG6Zh22mwYWKY3ETTZomZ8QEwCjrVKlvRwafVVGcw== x-ms-office365-filtering-correlation-id: 4f11b07f-06f8-454f-f4f3-08d47002430a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(129404003)(24454002)(86362001)(305945005)(2906002)(3280700002)(3660700001)(74316002)(6916009)(2950100002)(38730400002)(50986999)(110136004)(6246003)(76176999)(54356999)(2900100001)(6436002)(5660300001)(7696004)(33656002)(6506006)(93886004)(77096006)(74482002)(53936002)(9686003)(54906002)(55016002)(1411001)(122556002)(229853002)(81166006)(8936002)(8676002)(4326008)(39060400002)(189998001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 21 Mar 2017 02:30:38.1898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 02:30:42 -0000 Konstantin Belousov wrote: [stuff snipped] > Yes, I have to somewhat retract my claims, but then I have another set > of surprises. Righto. > I realized (remembered) that nfs has its own VOP_PUTPAGES() method. > Implementation seems to directly initiate write RPC request using the > pages as the source buffer. I do not see anything in the code which > would mark the buffers, which possibly contain the pages, as clean, > or mark the buffer range as undirty. The only place I know of that the code does this is in the "struct buf's" hanging off of v_bufobj.bo_dirty. I imagine there would be a race between the write-back to the NFS server and further changes to the page by the process. For the most part, the VOP_PUTPAGES() is likely to happen after the process is done modifying the pages (often exited). For cases where it happens sooner, I would expect the page(s) to be written multiple times, but the last write should bring the file "up to date" on the server. > At very least, this might cause unnecessary double-write of the same > data. I am not sure if it could cause coherency issues between data > written using mappings and write(2). Also, both vm_object_page_clean() > and vfs_busy_pages() only ensure the shared-busy state on the pages, > so write(2) can occur while pageout sends data to server, causing > 'impossible' content transmitted over the wire. I'm not sure what you mean by impossible content, but for NFS the only time the file on the NFS server should be "up to date" will be after a file doing write(2) writing has closed the fd (and only then if options like "nocto" has not been used) or after an fsync(2) done by the process doing the writing. For mmap'd writing, I think msync(2) is about the only thing the process can do to ensure the data is written back to the server. (There was a patch to the NFS VOP_CLOSE() that does a vm_object_page_clean(= ) but without the OBJPC_SYNC flag which tries to make sure the pages get wri= tten shortly after the file is closed. Of course, an mmap'd file can still be m= odified by the process after close(2), so it is "just an attempt to make the common case = work". I don't recall, but I don't think I was the author of this patch.) I also wouldn't be surprised that multiple writes of the same page(s) occur= s under certain situations. (NFS has no rules w.r.t. write ordering. Each RPC= is separate and simply writes N bytes at file offset S.) It definitely happens= when there are multiple write(2)s of partial buffers, depending on when a sync()= happens. > Could you, please, explain the reasons for such implementation of > ncl_putpage() ? Well, I wasn't the author (it was just cribbed from the old NFS client and = I don't know who wrote it), so I'm afraid I don't know. (It's code I avoid changing= because I don't really understand it.) I suspect that the author assumed that processes would either mmap the file or use write(2) and wouldn't ever try and mix them to-gether. Hope this helps, rick From owner-freebsd-current@freebsd.org Tue Mar 21 02:40:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 185C7D15030 for ; Tue, 21 Mar 2017 02:40:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660079.outbound.protection.outlook.com [40.107.66.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B25221C8C; Tue, 21 Mar 2017 02:40:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 02:40:47 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 02:40:46 +0000 From: Rick Macklem To: Gergely Czuczy , Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "FreeBSD Current" Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIAAClcAgAHrwIA= Date: Tue, 21 Mar 2017 02:40:46 +0000 Message-ID: References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> , <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> In-Reply-To: <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:h0VuMPScvhoJXuzNjdeDJ3ilq3TBoIGsUzzTrLgv8Ei7uPGe688CvveJyEB+ElGh3U7lKw+4CaJdVSPugWSV7nKaPIDltaiXILiE0xj3P4uB5FX/v9SyebFc/1z7ifmpSxBk9GDIJjLulqCTFGkFqXWJrFBrgxACowMnU/4spWYsFlM3BC8svOdWhAa3ok5Y+cywJT4y6qSs7DUvcZA/YTmmFNo0hlKtisWmz8tC5BDn6zqQAiPn4p3376eb78aaoo7K9E1iVzNnydVxhP6rGVvEZd6UQ4tnIZAmWKAkAdzKyAm0Wz+Lr4s2f9pJEI7FE/Qu+zvq6umPnsiBqh01VA== x-ms-office365-filtering-correlation-id: ef8128bf-3321-406d-2750-08d47003add9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(51874003)(86362001)(305945005)(2906002)(3280700002)(3660700001)(74316002)(2950100002)(99936001)(38730400002)(50986999)(6246003)(76176999)(54356999)(2900100001)(6436002)(5660300001)(7696004)(33656002)(6506006)(93886004)(77096006)(74482002)(53936002)(9686003)(54906002)(55016002)(122556002)(229853002)(81166006)(8936002)(8676002)(5890100001)(4326008)(39060400002)(189998001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB01891633D0486547C3E748E3DD3D0YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 02:40:46.8734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 02:40:50 -0000 --_002_YTXPR01MB01891633D0486547C3E748E3DD3D0YTXPR01MB0189CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gergely Czuczy wrote: [stuff snipped] > Actually I want to test it, but you guys are so vehemently discussing > it, I thought it would be better to do so, once you guys settled your > analysis on the code. Also, me not having the problem occurring, I don't > think would mean it's solved, since that would only mean, the codepath > for my specific usecase works. There might be other things there as > well, what I don't hit. I hope by vehemently, you didn't find my comments as nasty. If they did come out that way, it was not what I intended and I apologize. > Let me know which patch should I test, and I will see to it in the next > couple of days, when I get the time to do it. I've attached it here again and, yes, I would agree that the results you ge= t from testing are just another data point and not definitive.=20 (I'd say this statement is true of all testing of nontrivial code.) Thanks in advance for any testing you can do, rick --_002_YTXPR01MB01891633D0486547C3E748E3DD3D0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="textmod.patch" Content-Description: textmod.patch Content-Disposition: attachment; filename="textmod.patch"; size=1343; creation-date="Tue, 21 Mar 2017 02:39:56 GMT"; modification-date="Tue, 21 Mar 2017 02:39:56 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jLnRleHQJMjAxNy0wMy0xNiAyMTo1NToxNi4y NjMzOTMwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jCTIwMTctMDMtMTcg MDk6MzE6MjMuNjMyODE0MDAwIC0wNDAwCkBAIC0xNDAsNiArMTQwLDcgQEAgc3RhdGljIHZvcF9h ZHZsb2NrX3QJbmZzX2FkdmxvY2s7CiBzdGF0aWMgdm9wX2FkdmxvY2thc3luY190IG5mc19hZHZs b2NrYXN5bmM7CiBzdGF0aWMgdm9wX2dldGFjbF90IG5mc19nZXRhY2w7CiBzdGF0aWMgdm9wX3Nl dGFjbF90IG5mc19zZXRhY2w7CitzdGF0aWMgdm9wX3NldF90ZXh0X3QgbmZzX3NldF90ZXh0Owog CiAvKgogICogR2xvYmFsIHZmcyBkYXRhIHN0cnVjdHVyZXMgZm9yIG5mcwpAQCAtMTc2LDYgKzE3 Nyw3IEBAIHN0cnVjdCB2b3BfdmVjdG9yIG5ld25mc192bm9kZW9wcyA9IHsKIAkudm9wX3dyaXRl ID0JCW5jbF93cml0ZSwKIAkudm9wX2dldGFjbCA9CQluZnNfZ2V0YWNsLAogCS52b3Bfc2V0YWNs ID0JCW5mc19zZXRhY2wsCisJLnZvcF9zZXRfdGV4dCA9CQluZnNfc2V0X3RleHQsCiB9OwogCiBz dHJ1Y3Qgdm9wX3ZlY3RvciBuZXduZnNfZmlmb29wcyA9IHsKQEAgLTMzNzMsNiArMzM3NSwyOSBA QCBuZnNfc2V0YWNsKHN0cnVjdCB2b3Bfc2V0YWNsX2FyZ3MgKmFwKQogCXJldHVybiAoZXJyb3Ip OwogfQogCitzdGF0aWMgaW50CituZnNfc2V0X3RleHQoc3RydWN0IHZvcF9zZXRfdGV4dF9hcmdz ICphcCkKK3sKKwlzdHJ1Y3Qgdm5vZGUgKnZwID0gYXAtPmFfdnA7CisJc3RydWN0IG5mc25vZGUg Km5wOworCisJLyoKKwkgKiBJZiB0aGUgdGV4dCBmaWxlIGhhcyBiZWVuIG1tYXAnZCwgdGhlIGRp cnR5IHBhZ2VzIG11c3QgYmUgZmx1c2hlZAorCSAqIHNvIHRoYXQgdGhlIG1vZGlmeSB0aW1lIG9m IHRoZSBmaWxlIHdpbGwgYmUgdXAgdG8gZGF0ZS4KKwkgKi8KKwlpZiAodnAtPnZfb2JqZWN0ICE9 IE5VTEwpIHsKKwkJbnAgPSBWVE9ORlModnApOworCQlWTV9PQkpFQ1RfV0xPQ0sodnAtPnZfb2Jq ZWN0KTsKKwkJdm1fb2JqZWN0X3BhZ2VfY2xlYW4odnAtPnZfb2JqZWN0LCAwLCAwLCBPQkpQQ19T WU5DKTsKKwkJVk1fT0JKRUNUX1dVTkxPQ0sodnAtPnZfb2JqZWN0KTsKKwkJbXR4X2xvY2soJm5w LT5uX210eCk7CisJCW5wLT5uX210aW1lID0gbnAtPm5fdmF0dHIubmFfbXRpbWU7CisJCW10eF91 bmxvY2soJm5wLT5uX210eCk7CisJfQorCXZwLT52X3ZmbGFnIHw9IFZWX1RFWFQ7CisJcmV0dXJu ICgwKTsKK30KKwogLyoKICAqIFJldHVybiBQT1NJWCBwYXRoY29uZiBpbmZvcm1hdGlvbiBhcHBs aWNhYmxlIHRvIG5mcyBmaWxlc3lzdGVtcy4KICAqLwo= --_002_YTXPR01MB01891633D0486547C3E748E3DD3D0YTXPR01MB0189CANP_-- From owner-freebsd-current@freebsd.org Tue Mar 21 03:10:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE96CD15239; Tue, 21 Mar 2017 03:10:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 606881197; Tue, 21 Mar 2017 03:10:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id n11so2600802wma.1; Mon, 20 Mar 2017 20:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4KJvboAgc++ZkzDDeuf+b2F5Bw3ynvUJ8otbE06sevE=; b=WATwQDpZ+rBMzT6mQU4u5anTSFuk7ItiJ2ZHQpBAR/Ju9lrshlkQ5KW0beNL8Ckb/t d5RSaPzzOnIjf8lZQlu0rJPZTgxPHLuoVsTHUS8DlUnNXkzyDsBiB1qQ44OBsc51VZVr 8Cfrt78smn1gbtvvehdyc+5FTO8NyKB/uWNqrAQPu/2jF2KI5/AjBi1T4q1CrOcjl0dQ sXwQyl9PB2o/89QeLjlSzT/ZeQHkiFg7zVYzW2UTbhyEobMTRLnSLEffNo6VLgEtz1zB ZsOGZIshzn0UqHljPRYjD95ZPvgT3QE9OCM8rpWSilqcE1XJ2q9Egjv34Y1A1BHkqzLW nydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4KJvboAgc++ZkzDDeuf+b2F5Bw3ynvUJ8otbE06sevE=; b=nLbwFLJ6yk6nruOCa6wHv5REj3A4DjR1FVT7AfHmwmxbqWX2fv8kzDEcXUMrkeAa1Q 3RnmnAQaK+9AU3uOlGH3HujcWd+eiEJ9hYhNbzuPoJ6WWVVJHa2ycEHNkxZm68TVDRZA kwZGlEVRNYMamfv9rTGrUIYD4/+VANjuepG5iQAAaC/bF7VbgdpBQzL9wvHqz6giD8Ny ILjOX4vZvK/OOT43SJkr4uJtG3nq7QlpIGEnkgROTppOQbJobMO2TZW44DnwZQ/xtnLn 1CmGMpJkZ3A36fmMHRN6aZ86tdMVSGLBywl3Stgpry3xT67oCCR/rph2zqjw0z/KPxnt 2J8w== X-Gm-Message-State: AFeK/H2aAJ62XBJe9gypBfy/e6RVJ5iOLiG/AKwtu0MjB9nFAChrqIuVWgT9Gf6hbcBLiW1PlbbOmVR6zMBy3w== X-Received: by 10.28.72.193 with SMTP id v184mr543636wma.105.1490065821374; Mon, 20 Mar 2017 20:10:21 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.128.133 with HTTP; Mon, 20 Mar 2017 20:10:20 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Mon, 20 Mar 2017 20:10:20 -0700 X-Google-Sender-Auth: 2wY1NDiM7VYLaxceSzkjkpMv19Y Message-ID: Subject: Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm To: Ed Maste Cc: "freebsd-mips@freebsd.org" , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 03:10:23 -0000 WITHOUT_CLANG fixed it for me. Thanks. -adrian On 20 March 2017 at 11:23, Ed Maste wrote: > On 19 March 2017 at 03:00, Adrian Chadd wrote: >> gcc version 5.3.0 (FreeBSD Ports Collection for mips) >> >> ... so uhm, why are we building libllvm? > > As of the Clang 4.0.0 import we build Clang by default, on all > architectures other than those unsupported by Clang, if the > cross-compiler supports C++11. > > I'm not sure if the issue you encountered here is in libllvm or GCC. > For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in > /etc/src.conf. From owner-freebsd-current@freebsd.org Tue Mar 21 03:55:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 076BDD15A2D; Tue, 21 Mar 2017 03:55:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D22FC102A; Tue, 21 Mar 2017 03:55:55 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L3txL3093544; Mon, 20 Mar 2017 20:56:05 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" Cc: "FreeBSD CURRENT" From: "Chris H" Subject: ELF binary type "3" not known. Date: Mon, 20 Mar 2017 20:56:05 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 03:55:56 -0000 I'm not sure which of the two lists I'm directing this to is the best/correct one. So I picked both. To the point; I received this message during a big build session. I was only able to catch the one from x11/nvidia-driver in such a way as to actually get the entire message: Installing nvidia-driver-375.26_1... ELF binary type "3" not known. /bin/sh: /compat/linux/sbin/ldconfig: Exec format error I built && installed emulators/linux_base-c7 *prior* to installing this. This is on a: FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: Sun Mar 5 09:01:30 PST 2017 amd64 Should I anticipate any problems? All and all, it seems to work. But are there going to be some subtle repercussions? Is this a 32bit-v-64bit problem with linux_base || the nvidia blob? Thanks. --Chris From owner-freebsd-current@freebsd.org Tue Mar 21 04:11:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B1A9D15457; Tue, 21 Mar 2017 04:11:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E65C2195E; Tue, 21 Mar 2017 04:11:33 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L4Bc2x095115; Mon, 20 Mar 2017 21:11:44 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" Cc: FreeBSD CURRENT In-Reply-To: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> From: "Chris H" Subject: Re: ELF binary type "3" not known. Date: Mon, 20 Mar 2017 21:11:44 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 04:11:35 -0000 On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" wrote > I'm not sure which of the two lists I'm directing > this to is the best/correct one. So I picked both. > > To the point; I received this message during a big > build session. I was only able to catch the one from > x11/nvidia-driver in such a way as to actually get > the entire message: > > Installing nvidia-driver-375.26_1... > ELF binary type "3" not known. > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > I built && installed emulators/linux_base-c7 *prior* > to installing this. This is on a: > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > Sun Mar 5 09:01:30 PST 2017 amd64 Sorry. Forgot to add the ports revision. revision 435383 > > Should I anticipate any problems? All and all, it seems > to work. But are there going to be some subtle repercussions? > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > blob? > > Thanks. > > --Chris > > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 21 05:12:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E408AD15A47; Tue, 21 Mar 2017 05:12:25 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F8A91D66; Tue, 21 Mar 2017 05:12:24 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LjaEi-1cJ4GI1G1I-00balP; Tue, 21 Mar 2017 06:12:02 +0100 Date: Tue, 21 Mar 2017 06:11:53 +0100 From: "O. Hartmann" To: "Chris H" Cc: "FreeBSD ports" , FreeBSD CURRENT Subject: Re: ELF binary type "3" not known. Message-ID: <20170321061141.0fe7bc4a@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WUoyGz67AG/Vu+Hc0hZmpUKusOZs6qgl9QQIj5rzBEXxsIWTOND LwL5kJF5fCkc4Ybj21pfQNTWV5L6aAkfX0Sr/0eMt9R6jqqoNq+sMWdl7ZaoFDZ4ESvACTj QjFZbQf+ABfKLRqK19YhXp8eU7n4Wu0pp2M3KEjjRQDuo0SzIRdbAk4NdKFUGUL3Aq2zBHi J8Xa89XyByzjAKXK6fb7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:o7rNbS8ra+M=:o0XBPnPqkvYPiZSfklu43g Wva800fFGeN9PUfZx+VHcFXRDzn1aG2oKJqlhMFcjYme/OLQ6lrmwOYdmldhsMoMK3g2LSgC5 GqFF/oh/MP/sw0NohJG4Jr582LH9d/Jl7S3uEz8jpnNatuk7d7H5q3TGvHW4aiOom6IHk8zH4 SHUPxY+vIfeGQCUHbpEZ6Mo76WIGSD0VytVwaxM4IS15C3I8LyPGRaU52go/WBRHt9p79yKHo vLL4xY/8xtzgV0yNQADWgXUKTWEjdBIGhbagKjMnOBCF0vwK2UdSEo4JvW8T/vza8N4GBiHWM jsQLzLdyS7kd+L7qcinyqSxPr0cjpMUgS4wcZSxfFC3gVnqzoyH/PWlfnVaA2aCJAN1WbPhHG ry1hdI1y8hnrSNmMyGWblTcILrd8aqRNiICq4AW3Y2OcsT4Q8LgQj7zsdnn1oCCSSA0EMiwlU BI8l9fhef7nArv+2jXCaIGoe7XGKKWg0cv+l/rIWMcd0RsMjdYuJrAij3s9nL39F+EXE8tZTq 4e26BCS4L3oG0ZYzOM4p+ck/aWvRKMvJfI5aEpZD+bD2cE1v1cZTvYGLlGLjOZFSuliAllUGQ +ZU80HpAe7Q2O0r9hvsLiLeRNw8Mrx1anlrRRIRYl0MthMPjBRTX5sVsNlwzLh8kA3I4Dj7VR wStjUQE3pQ11UVNnoTxdRcujJERcDVS68E+LXGR+SaJBeXpbgyAsGMS64v10JgsG3zAToWEZ6 ekhKKL8FA4euVUjp/BwwgQ48vE67YQzq9s1FXUoFw//28NzBGychSgO0/lB5Th5TAMXJkft6c 7tPChLd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:12:26 -0000 On Mon, 20 Mar 2017 21:11:44 -0700 "Chris H" wrote: > On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" wrote > > > I'm not sure which of the two lists I'm directing > > this to is the best/correct one. So I picked both. > > > > To the point; I received this message during a big > > build session. I was only able to catch the one from > > x11/nvidia-driver in such a way as to actually get > > the entire message: > > > > Installing nvidia-driver-375.26_1... > > ELF binary type "3" not known. > > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > > > I built && installed emulators/linux_base-c7 *prior* > > to installing this. This is on a: > > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > > Sun Mar 5 09:01:30 PST 2017 amd64 > Sorry. Forgot to add the ports revision. > > revision 435383 > > > > > Should I anticipate any problems? All and all, it seems > > to work. But are there going to be some subtle repercussions? > > > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > > blob? > > > > Thanks. > > > > --Chris [...] I see this in poudriere builds, too. I haven't seen with which builds this occurs, but it occurs quite often. oh From owner-freebsd-current@freebsd.org Tue Mar 21 05:15:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E767BD15D9A; Tue, 21 Mar 2017 05:15:20 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A1D307; Tue, 21 Mar 2017 05:15:19 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id v2L5EvGj038570 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 13:14:58 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id v2L5Eupw038569; Tue, 21 Mar 2017 13:14:56 +0800 (CST) (envelope-from kevlo) Date: Tue, 21 Mar 2017 13:14:56 +0800 From: Kevin Lo To: Chris H Cc: FreeBSD ports , FreeBSD CURRENT Subject: Re: ELF binary type "3" not known. Message-ID: <20170321051455.GA38562@ns.kevlo.org> References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:15:21 -0000 On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote: > > On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" wrote > > > I'm not sure which of the two lists I'm directing > > this to is the best/correct one. So I picked both. > > > > To the point; I received this message during a big > > build session. I was only able to catch the one from > > x11/nvidia-driver in such a way as to actually get > > the entire message: > > > > Installing nvidia-driver-375.26_1... > > ELF binary type "3" not known. > > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > > > I built && installed emulators/linux_base-c7 *prior* > > to installing this. This is on a: > > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > > Sun Mar 5 09:01:30 PST 2017 amd64 > Sorry. Forgot to add the ports revision. > > revision 435383 Did you do kldload linux64 ? > > > > Should I anticipate any problems? All and all, it seems > > to work. But are there going to be some subtle repercussions? > > > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > > blob? > > > > Thanks. > > > > --Chris Kevin From owner-freebsd-current@freebsd.org Tue Mar 21 05:22:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB1CAD163D7; Tue, 21 Mar 2017 05:22:44 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E54FCAC; Tue, 21 Mar 2017 05:22:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L5MmGT001753; Mon, 20 Mar 2017 22:22:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Kevin Lo Cc: FreeBSD CURRENT , FreeBSD ports In-Reply-To: <20170321051455.GA38562@ns.kevlo.org> References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> , <20170321051455.GA38562@ns.kevlo.org> From: "Chris H" Subject: Re: ELF binary type "3" not known. Date: Mon, 20 Mar 2017 22:22:54 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:22:44 -0000 On Tue, 21 Mar 2017 13:14:56 +0800 Kevin Lo wrote > On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote: > > > > On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" wrote > > > > > I'm not sure which of the two lists I'm directing > > > this to is the best/correct one. So I picked both. > > > > > > To the point; I received this message during a big > > > build session. I was only able to catch the one from > > > x11/nvidia-driver in such a way as to actually get > > > the entire message: > > > > > > Installing nvidia-driver-375.26_1... > > > ELF binary type "3" not known. > > > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > > > > > I built && installed emulators/linux_base-c7 *prior* > > > to installing this. This is on a: > > > > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > > > Sun Mar 5 09:01:30 PST 2017 amd64 > > Sorry. Forgot to add the ports revision. > > > > revision 435383 > > Did you do kldload linux64 ? Thanks for the reply, Kevin. Yes. Both before building/installing nvidia-driver, and via loader.conf(5): linux_load="YES" nvidia-modeset_load="YES" Thanks again! --Chris > > > > > > > Should I anticipate any problems? All and all, it seems > > > to work. But are there going to be some subtle repercussions? > > > > > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > > > blob? > > > > > > Thanks. > > > > > > --Chris > > Kevin > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 21 05:26:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CEEAD16545 for ; Tue, 21 Mar 2017 05:26:04 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 BB77FF37; Tue, 21 Mar 2017 05:26:03 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 94-21-205-135.pool.digikabel.hu ([94.21.205.135] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cqCIs-000CmH-SW; Tue, 21 Mar 2017 05:25:54 +0000 Subject: Re: process killed: text file modification To: Rick Macklem , Konstantin Belousov References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> Cc: Dimitry Andric , Ian Lepore , FreeBSD Current From: Gergely Czuczy Message-ID: <467bc693-d2ab-e6d9-a86d-584ca85a1ce4@harmless.hu> Date: Tue, 21 Mar 2017 06:25:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:26:04 -0000 On 2017. 03. 21. 3:40, Rick Macklem wrote: > Gergely Czuczy wrote: > [stuff snipped] >> Actually I want to test it, but you guys are so vehemently discussing >> it, I thought it would be better to do so, once you guys settled your >> analysis on the code. Also, me not having the problem occurring, I don't >> think would mean it's solved, since that would only mean, the codepath >> for my specific usecase works. There might be other things there as >> well, what I don't hit. > I hope by vehemently, you didn't find my comments as nasty. If they did > come out that way, it was not what I intended and I apologize. Oh, totally not. I barely meant that you guys are right in the middle of the technical discussion, and it doesn't seemed settled. > >> Let me know which patch should I test, and I will see to it in the next >> couple of days, when I get the time to do it. > I've attached it here again and, yes, I would agree that the results you get > from testing are just another data point and not definitive. > (I'd say this statement is true of all testing of nontrivial code.) > > Thanks in advance for any testing you can do, rick Updated the tree and the patch has applied: # patch < /home/phoemix/textmod.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- fs/nfsclient/nfs_clvnops.c.text 2017-03-16 21:55:16.263393000 -0400 |+++ fs/nfsclient/nfs_clvnops.c 2017-03-17 09:31:23.632814000 -0400 -------------------------- Patching file fs/nfsclient/nfs_clvnops.c using Plan A... Hunk #1 succeeded at 140. Hunk #2 succeeded at 177. Hunk #3 succeeded at 3375. done When I'm back home from work, I will check the build out, and see how it goes. And thank you very much guys for working on fixing this one. -czg From owner-freebsd-current@freebsd.org Tue Mar 21 05:33:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD4CDD168AD; Tue, 21 Mar 2017 05:33:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA1E13CA; Tue, 21 Mar 2017 05:33:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v2L5WrHQ076773; Mon, 20 Mar 2017 22:32:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201703210532.v2L5WrHQ076773@gw.catspoiler.org> Date: Mon, 20 Mar 2017 22:32:53 -0700 (PDT) From: Don Lewis Subject: Re: ELF binary type "3" not known. To: bsd-lists@bsdforge.com cc: freebsd-ports@FreeBSD.org, freebsd-current@freebsd.org In-Reply-To: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:33:15 -0000 On 20 Mar, Chris H wrote: > I'm not sure which of the two lists I'm directing > this to is the best/correct one. So I picked both. > > To the point; I received this message during a big > build session. I was only able to catch the one from > x11/nvidia-driver in such a way as to actually get > the entire message: > > Installing nvidia-driver-375.26_1... > ELF binary type "3" not known. > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > I built && installed emulators/linux_base-c7 *prior* > to installing this. This is on a: > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > Sun Mar 5 09:01:30 PST 2017 amd64 > > Should I anticipate any problems? All and all, it seems > to work. But are there going to be some subtle repercussions? > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > blob? You should have these kernel modules loaded: %kldstat | grep linux 5 1 0xffffffff82643000 ac488 linux.ko 6 4 0xffffffff826f0000 e5d0 linux_common.ko 7 1 0xffffffff826ff000 99bb8 linux64.ko They will get loaded on boot if you have this in /boot/loader.conf: linux_load="YES" linux64_load="YES" From owner-freebsd-current@freebsd.org Tue Mar 21 05:35:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61103D16A91 for ; Tue, 21 Mar 2017 05:35:32 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26C5216AF for ; Tue, 21 Mar 2017 05:35:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L5ZaV8002949; Mon, 20 Mar 2017 22:35:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "O. Hartmann" Cc: "FreeBSD CURRENT" In-Reply-To: <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> References: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net>, <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> From: "Chris H" Subject: Re: why are the GEOM secondary GPT tables always corrupt? Date: Mon, 20 Mar 2017 22:35:42 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:35:32 -0000 On Tue, 21 Mar 2017 06:16:03 +0100 "O. Hartmann" wrote > On Mon, 20 Mar 2017 19:08:41 -0700 > "Chris H" wrote: > > > I've seen this discussed before, but there were so many > > "solutions", I was left feeling this *must* be some sort > > of bug in GEOM/gpart. So. I just blew away the tables on > > a USB3 flash drive: > > > > # gpart destroy -F da0 > > > > # gpart create -s gpt da0 > > > > # gpart add -t freebsd-ufs -l jails da0 > > > > # newfs -U /dev/gpt/jails > > > > Added an entry to fstab(5) > > OK this should be good to go. Mount, and umount > > all return as expected, as does fsck(8). > > > > Upon reboot, I receive the following: > > > > /dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0% > > fragmentation) > > GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or > > invalid. > > GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery > > suggested. > > > > But why? > > > > This is on: > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64 > > > > Thanks for any information. > > > > --Chris > I see this when I put a disk image, which is smaller than the entire device > (for instance, 8GB USB flash drive with a UEFI booting (GPT) NanoBSD image of > 1 GB in size. I do not know what exactly causes the problem, but it can be > fixed by issuing "gpart recover DEV". I think the secondary GTP table is > supposed to reside on the physically last blocks of the device (physically). > > oh Thanks for the reply. Yes, I've caught that too. But that /almost/ seems reasonable, for that circumstance. What concerns me here; is that this is a fresh partition && newfs. Given the partition spans the entire flash drive. I wouldn't expect there to be any inconsistencies between the 2 records. I'd hate to use the recover option, and have it use wrong results. Why isn't the second table "synced" with the first/primary table? I'd blame it on the flash drive, but it's not limited to just this drive, nor just this box. I have a version 11 box that's some 6mos out, that also does this. Thanks again, for taking the time to reply! --Chris From owner-freebsd-current@freebsd.org Tue Mar 21 05:42:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7906CD16E72; Tue, 21 Mar 2017 05:42:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B5141C2E; Tue, 21 Mar 2017 05:42:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L5gfnt003767; Mon, 20 Mar 2017 22:42:47 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Don Lewis Cc: freebsd-ports@FreeBSD.org, In-Reply-To: <201703210532.v2L5WrHQ076773@gw.catspoiler.org> References: <201703210532.v2L5WrHQ076773@gw.catspoiler.org> From: "Chris H" Subject: Re: ELF binary type "3" not known. Date: Mon, 20 Mar 2017 22:42:47 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:42:36 -0000 On Mon, 20 Mar 2017 22:32:53 -0700 (PDT) Don Lewis wrote > On 20 Mar, Chris H wrote: > > I'm not sure which of the two lists I'm directing > > this to is the best/correct one. So I picked both. > > > > To the point; I received this message during a big > > build session. I was only able to catch the one from > > x11/nvidia-driver in such a way as to actually get > > the entire message: > > > > Installing nvidia-driver-375.26_1... > > ELF binary type "3" not known. > > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > > > I built && installed emulators/linux_base-c7 *prior* > > to installing this. This is on a: > > > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > > Sun Mar 5 09:01:30 PST 2017 amd64 > > > > Should I anticipate any problems? All and all, it seems > > to work. But are there going to be some subtle repercussions? > > > > Is this a 32bit-v-64bit problem with linux_base || the nvidia > > blob? > > You should have these kernel modules loaded: > > %kldstat | grep linux > 5 1 0xffffffff82643000 ac488 linux.ko > 6 4 0xffffffff826f0000 e5d0 linux_common.ko > 7 1 0xffffffff826ff000 99bb8 linux64.ko > > They will get loaded on boot if you have this in /boot/loader.conf: > > linux_load="YES" > linux64_load="YES" Thanks for the reply, Don. this is what I have: # kldstat Id Refs Address Size Name 1 20 0xffffffff80200000 13c1810 kernel 2 3 0xffffffff815c3000 ac568 linux.ko 3 3 0xffffffff81670000 e000 linux_common.ko 4 1 0xffffffff8167e000 115128 nvidia-modeset.ko 5 2 0xffffffff81794000 ff44b8 nvidia.ko 6 1 0xffffffff82d11000 a954 linprocfs.ko Which seems to be missing linux64.ko Looks like I'll need to add it to loader.conf(5) and seems to me to explain the error message. Should I rebuild/install the nvidia-driver? Thanks again, Don! --Chris From owner-freebsd-current@freebsd.org Tue Mar 21 08:01:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD089D16231 for ; Tue, 21 Mar 2017 08:01:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C3F6A43; Tue, 21 Mar 2017 08:01:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cqEja-000MWN-P2; Tue, 21 Mar 2017 10:01:38 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 From: Daniel Braniss In-Reply-To: Date: Tue, 21 Mar 2017 10:01:38 +0200 Cc: Baptiste Daroussin , Toomas Soome , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3429CB2E-AAF1-47C2-B1B2-400A3819C7FB@cs.huji.ac.il> References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> To: Rick Macklem X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 08:01:42 -0000 > On 20 Mar 2017, at 23:53, Rick Macklem wrote: >=20 > Baptiste Daroussin wrote: >> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>> Hi! >>>=20 >>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>=20 >>> rgds, >>> toomas >>=20 >> I vote burn >>=20 >> Bapt > I would be happy to see NFSv2 go away. However, depending on how = people configure > their diskless root fs, they do end up using NFSv2 for their root fs. >=20 > Does booting over NFSv3 affect this? >=20 > I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as > the NFSv3 one, except padded with 0 bytes to 32bytes long). > However, there might be non-FreeBSD NFS servers where the NFSv2 file = handle is different > than the NFSv3 one and for that case, the user would need NFSv2 boot = code (or > reconfigure their root fs to use NFSv3). >=20 > To be honest, I suspect few realize that they are using NFSv2 for = their root fs. > (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably > think they are using NFSv3 for their root fs.) this just what happened here, we upgraded our main NetApp, and few = machines started working funny, so we moved them to use FreeBSD instead and all was ok again.=20 danny >=20 > rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 21 08:02:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 540EDD162DC for ; Tue, 21 Mar 2017 08:02:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5DFBD3D; Tue, 21 Mar 2017 08:02:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cqEgP-000MN1-9K; Tue, 21 Mar 2017 09:58:21 +0200 From: Daniel Braniss Message-Id: <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 Date: Tue, 21 Mar 2017 09:58:21 +0200 In-Reply-To: <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> Cc: Rick Macklem , Baptiste Daroussin , FreeBSD Current To: Toomas Soome References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 08:02:30 -0000 > On 20 Mar 2017, at 23:55, Toomas Soome wrote: >=20 >>=20 >> On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem = wrote: >>=20 >> Baptiste Daroussin wrote: >>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>>> Hi! >>>>=20 >>>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>>=20 >>>> rgds, >>>> toomas >>>=20 >>> I vote burn >>>=20 >>> Bapt >> I would be happy to see NFSv2 go away. However, depending on how = people configure >> their diskless root fs, they do end up using NFSv2 for their root fs. >>=20 >> Does booting over NFSv3 affect this? >>=20 >> I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as >> the NFSv3 one, except padded with 0 bytes to 32bytes long). >> However, there might be non-FreeBSD NFS servers where the NFSv2 file = handle is different >> than the NFSv3 one and for that case, the user would need NFSv2 boot = code (or >> reconfigure their root fs to use NFSv3). >>=20 >> To be honest, I suspect few realize that they are using NFSv2 for = their root fs. >> (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably >> think they are using NFSv3 for their root fs.) >>=20 >> rick >=20 > if they do not suspect, they most likely use v3 - due to simple fact = that you have to rebuild loader to use NFSv2 - it is compile time = option. >=20 old systems, 8.x, still use/boot v2, and so do old linux. NetApp has discontinued support for v2, so we had to move this machines = to use FreeBSD server and the day was saved. So, till these machines get upgraded/discontinued we have a = problem. There are several solutions to this issue, but as long as it's a matter of getting rid for the sake = of it, I would vote to keep it a while longer. danny From owner-freebsd-current@freebsd.org Tue Mar 21 08:13:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24954D16630 for ; Tue, 21 Mar 2017 08:13:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D897D1410; Tue, 21 Mar 2017 08:13:40 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 2B9097319; Tue, 21 Mar 2017 08:13:40 +0000 (UTC) Date: Tue, 21 Mar 2017 09:13:39 +0100 From: Baptiste Daroussin To: Daniel Braniss Cc: Toomas Soome , Rick Macklem , FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 Message-ID: <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jr2dkby6gacluzxz" Content-Disposition: inline In-Reply-To: <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 08:13:41 -0000 --jr2dkby6gacluzxz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: >=20 > > On 20 Mar 2017, at 23:55, Toomas Soome wrote: > >=20 > >>=20 > >> On 20. m=E4rts 2017, at 23:53, Rick Macklem wro= te: > >>=20 > >> Baptiste Daroussin wrote: > >>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: > >>>> Hi! > >>>>=20 > >>>> The current boot code is building NFSv3, with preprocessor condition= al OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it? > >>>>=20 > >>>> rgds, > >>>> toomas > >>>=20 > >>> I vote burn > >>>=20 > >>> Bapt > >> I would be happy to see NFSv2 go away. However, depending on how peopl= e configure > >> their diskless root fs, they do end up using NFSv2 for their root fs. > >>=20 > >> Does booting over NFSv3 affect this? > >>=20 > >> I think the answer is no for a FreeBSD server (since the NFSv2 File Ha= ndle is the same as > >> the NFSv3 one, except padded with 0 bytes to 32bytes long). > >> However, there might be non-FreeBSD NFS servers where the NFSv2 file h= andle is different > >> than the NFSv3 one and for that case, the user would need NFSv2 boot c= ode (or > >> reconfigure their root fs to use NFSv3). > >>=20 > >> To be honest, I suspect few realize that they are using NFSv2 for thei= r root fs. > >> (They'd see it in a packet trace or via "nfsstat -m", but otherwise th= ey probably > >> think they are using NFSv3 for their root fs.) > >>=20 > >> rick > >=20 > > if they do not suspect, they most likely use v3 - due to simple fact th= at you have to rebuild loader to use NFSv2 - it is compile time option. > >=20 >=20 > old systems, 8.x, still use/boot v2, and so do old linux. > NetApp has discontinued support for v2, so we had to move this machines t= o use FreeBSD server and the day was > saved. So, till these machines get upgraded/discontinued we have a proble= m. There are several solutions > to this issue, but as long as it's a matter of getting rid for the sake o= f it, I would vote to keep it a while longer. >=20 > danny >=20 >=20 Given you are speaking of 8.x I suppose you are using the loader that comes= with it, meaning you are safe if we remove it from the loader in 12.0 (note as s= aid by Toomas that is it is already off by default in the 12.0 loader) am I mis= sing something? Best regards, Bapt --jr2dkby6gacluzxz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAljQ4LEACgkQY4mL3PG3 PlonNBAAru0NFlMmWVL/sjemOgzwm3rc0tarbB1wJTDt6fGuyIgGIMp7ZOVdl7wN ZR0KhfVhdpxcLXjBt36QqNQ/V6WTXUMyrQyRP0C2mUpWab/fc49hMbx25Lb7P1aB CHWXjV0+fbeDcK6Tq+1cAmm0fZM8yBzgOShW3m7tBO5O5UtyVIWVvRRJFdSOoTXw 0C7lw6zaxaY4R1/qGAKKLtEvEgTocdtMWOErIxFCjXSo+QerSGZbjBve6etbbtr5 Maw2YOXC6i/Xp596njGJhqg9izGzE2OUxUqkyQ51s4SR766n4brK77LFe5f4+sG+ HOAfmUDDxyMDNwBG34yhfzm0UxQfmBZXzJGA7OPn2GrkX2IB24za8XrCEQoYjJiw LV7xGbLVogZ/Ye21hVGuJODmgWMlb1yEgvKuQFSSjIGnaBJtzSFjquR1i1WXvEfg UN50pU2V5hHxjN4QsXA6fRUqwk2faEUOIUZxOPKYnBCmapbMCh2WCiePzBAt1In6 UemhrDerSLelnDVFHO02dtpkOwI1SzmRHbXQpPZQuUckG2WKn93zkkln3dVl06TR 0hgKxf6mC6OgksBO3AkXmTVv9Q4zkcLExtVmNJyUqnsMJwG6g00GyU6qunyaeR+b oAIGd+90X9b1ddzbQYJzG7hWvE6tgcKxbLY4QB40BeyFbgdLgf0= =iGWJ -----END PGP SIGNATURE----- --jr2dkby6gacluzxz-- From owner-freebsd-current@freebsd.org Tue Mar 21 08:48:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51079D0A366 for ; Tue, 21 Mar 2017 08:48:04 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 287A26A8; Tue, 21 Mar 2017 08:48:04 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ON500M00PC8M300@st13p35im-asmtp002.me.com>; Tue, 21 Mar 2017 08:48:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490086083; bh=5KByKSKX/D1x5bqK5h4flIbx8JJvF1UY6eUpMDweRjI=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Yk2BSRCw825SIXhSWIW0KA5ZqSG5iNeM+Rh5gO6rwa9Fe9Qf1Ybiq8Z3tjmQ6bg7G z4XgZ5+tmVvUh5gZT96sYnH+Xr5Px2KBdU2FEqXhM8nZn1WMj/BXbPxFwfL2OShyhw 9FkXWLNAGqizh1kUVroMYaK9+znKITHNBv3d5C1cagj1/I6P9Z6EqQAdptW4FCJFk9 lFTEZi2xPVO6gXXlO4Gkto45xjIo+3uvB87OryMtffbjoi0Pj+h4NKzrokV819e0LP ugyoYJudM/CXAdfJJOqYnf8ch3K/rX9hScygbxuMreTHGe7HLF1Nq7RrDOZyebkC94 OU1y/DINlLw6A== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ON500D6FPS0I910@st13p35im-asmtp002.me.com>; Tue, 21 Mar 2017 08:48:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-21_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703210079 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 From: Toomas Soome In-reply-to: <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> Date: Tue, 21 Mar 2017 10:47:57 +0200 Cc: Daniel Braniss , Rick Macklem , FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: <1CAABCFC-2385-444D-B909-F5F1C33F8A88@me.com> References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 08:48:04 -0000 > On 21. m=C3=A4rts 2017, at 10:13, Baptiste Daroussin = wrote: >=20 > On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: >>=20 >>> On 20 Mar 2017, at 23:55, Toomas Soome wrote: >>>=20 >>>>=20 >>>> On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem = wrote: >>>>=20 >>>> Baptiste Daroussin wrote: >>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>>>>> Hi! >>>>>>=20 >>>>>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>>>>=20 >>>>>> rgds, >>>>>> toomas >>>>>=20 >>>>> I vote burn >>>>>=20 >>>>> Bapt >>>> I would be happy to see NFSv2 go away. However, depending on how = people configure >>>> their diskless root fs, they do end up using NFSv2 for their root = fs. >>>>=20 >>>> Does booting over NFSv3 affect this? >>>>=20 >>>> I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as >>>> the NFSv3 one, except padded with 0 bytes to 32bytes long). >>>> However, there might be non-FreeBSD NFS servers where the NFSv2 = file handle is different >>>> than the NFSv3 one and for that case, the user would need NFSv2 = boot code (or >>>> reconfigure their root fs to use NFSv3). >>>>=20 >>>> To be honest, I suspect few realize that they are using NFSv2 for = their root fs. >>>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably >>>> think they are using NFSv3 for their root fs.) >>>>=20 >>>> rick >>>=20 >>> if they do not suspect, they most likely use v3 - due to simple fact = that you have to rebuild loader to use NFSv2 - it is compile time = option. >>>=20 >>=20 >> old systems, 8.x, still use/boot v2, and so do old linux. >> NetApp has discontinued support for v2, so we had to move this = machines to use FreeBSD server and the day was >> saved. So, till these machines get upgraded/discontinued we have a = problem. There are several solutions >> to this issue, but as long as it's a matter of getting rid for the = sake of it, I would vote to keep it a while longer. >>=20 >> danny >>=20 >>=20 > Given you are speaking of 8.x I suppose you are using the loader that = comes with > it, meaning you are safe if we remove it from the loader in 12.0 (note = as said > by Toomas that is it is already off by default in the 12.0 loader) am = I missing > something? >=20 >=20 Indeed, we definitely are *not* talking about back porting the removal, = there is no reason for that whatsoever. In fact at least 11 is = distributing loader based on NFSv3, likely even 10 (I havent checked = that). So yes, just talking about possible removal in current only. rgds, toomas From owner-freebsd-current@freebsd.org Tue Mar 21 08:50:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8077AD0A4B4 for ; Tue, 21 Mar 2017 08:50:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0FDB8AE; Tue, 21 Mar 2017 08:50:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cqFV9-000NQL-Kt; Tue, 21 Mar 2017 10:50:47 +0200 From: Daniel Braniss Message-Id: <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 Date: Tue, 21 Mar 2017 10:50:47 +0200 In-Reply-To: <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> Cc: Toomas Soome , Rick Macklem , FreeBSD Current To: Baptiste Daroussin References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 08:50:51 -0000 > On 21 Mar 2017, at 10:13, Baptiste Daroussin wrote: >=20 > On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: >>=20 >>> On 20 Mar 2017, at 23:55, Toomas Soome wrote: >>>=20 >>>>=20 >>>> On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem = wrote: >>>>=20 >>>> Baptiste Daroussin wrote: >>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>>>>> Hi! >>>>>>=20 >>>>>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>>>>=20 >>>>>> rgds, >>>>>> toomas >>>>>=20 >>>>> I vote burn >>>>>=20 >>>>> Bapt >>>> I would be happy to see NFSv2 go away. However, depending on how = people configure >>>> their diskless root fs, they do end up using NFSv2 for their root = fs. >>>>=20 >>>> Does booting over NFSv3 affect this? >>>>=20 >>>> I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as >>>> the NFSv3 one, except padded with 0 bytes to 32bytes long). >>>> However, there might be non-FreeBSD NFS servers where the NFSv2 = file handle is different >>>> than the NFSv3 one and for that case, the user would need NFSv2 = boot code (or >>>> reconfigure their root fs to use NFSv3). >>>>=20 >>>> To be honest, I suspect few realize that they are using NFSv2 for = their root fs. >>>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably >>>> think they are using NFSv3 for their root fs.) >>>>=20 >>>> rick >>>=20 >>> if they do not suspect, they most likely use v3 - due to simple fact = that you have to rebuild loader to use NFSv2 - it is compile time = option. >>>=20 >>=20 >> old systems, 8.x, still use/boot v2, and so do old linux. >> NetApp has discontinued support for v2, so we had to move this = machines to use FreeBSD server and the day was >> saved. So, till these machines get upgraded/discontinued we have a = problem. There are several solutions >> to this issue, but as long as it's a matter of getting rid for the = sake of it, I would vote to keep it a while longer. >>=20 >> danny >>=20 >>=20 > Given you are speaking of 8.x I suppose you are using the loader that = comes with > it, meaning you are safe if we remove it from the loader in 12.0 (note = as said > by Toomas that is it is already off by default in the 12.0 loader) am = I missing > something? >=20 as usual, did not read the whole thread, I assumed - wrongly - that = support for v2 would be discontinued. removing v2 support from the boot process is fine! great, go for it. It = will only involve newer hosts, and simplifying the boot process is always a good idea. sorry for the noise. danny > Best regards, > Bapt From owner-freebsd-current@freebsd.org Tue Mar 21 09:05:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01B8CD14023 for ; Tue, 21 Mar 2017 09:05:04 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4414162A; Tue, 21 Mar 2017 09:05:04 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ON500900QACR000@st13p35im-asmtp001.me.com>; Tue, 21 Mar 2017 09:05:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490087103; bh=UOa/z9BLi1z+9Gc7dUteVUv0ZBD7f7MbJtX4/3LbmqU=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=GlmhEmNws4tqip0R9MXze+4xDfX3ZUspwPW08hVmUvKb7L5qF0bYfzZD5xDzdXWQW cRqycNUTJNNjfePtm3Bh2vGo6uAH/IxYSVcFm8hsC0LnlC/IzxJQZ+38bK2bOBmKDn PwBu1p+iJcDpeMNkQZrSbvmFan9j4MzhnjB99bSJqgGraC1CiFA8TIHQCTm7vHsBvN bGUu1gcobtiXNNbMfvdQCRirs5Jc7odvcSjDUODkrYHRqQE9eVGxM/PqGmzoVlDV00 BDPJ/tH3KiGEBd444yYPCjjt3fDdBH5qksI0aBlb4ILhGLvIdT95gf+UgiRyo/iD0Q c9/gYoL+VNe2g== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ON500M1DQKCHI30@st13p35im-asmtp001.me.com>; Tue, 21 Mar 2017 09:05:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-21_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703210082 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 Date: Tue, 21 Mar 2017 11:04:59 +0200 In-reply-to: <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il> Cc: Baptiste Daroussin , Rick Macklem , FreeBSD Current To: Daniel Braniss References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 09:05:05 -0000 > On 21. m=C3=A4rts 2017, at 10:50, Daniel Braniss = wrote: >=20 >=20 >> On 21 Mar 2017, at 10:13, Baptiste Daroussin > wrote: >>=20 >> On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: >>>=20 >>>> On 20 Mar 2017, at 23:55, Toomas Soome > wrote: >>>>=20 >>>>>=20 >>>>> On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem = > wrote: >>>>>=20 >>>>> Baptiste Daroussin wrote: >>>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: >>>>>>> Hi! >>>>>>>=20 >>>>>>> The current boot code is building NFSv3, with preprocessor = conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we = burn it? >>>>>>>=20 >>>>>>> rgds, >>>>>>> toomas >>>>>>=20 >>>>>> I vote burn >>>>>>=20 >>>>>> Bapt >>>>> I would be happy to see NFSv2 go away. However, depending on how = people configure >>>>> their diskless root fs, they do end up using NFSv2 for their root = fs. >>>>>=20 >>>>> Does booting over NFSv3 affect this? >>>>>=20 >>>>> I think the answer is no for a FreeBSD server (since the NFSv2 = File Handle is the same as >>>>> the NFSv3 one, except padded with 0 bytes to 32bytes long). >>>>> However, there might be non-FreeBSD NFS servers where the NFSv2 = file handle is different >>>>> than the NFSv3 one and for that case, the user would need NFSv2 = boot code (or >>>>> reconfigure their root fs to use NFSv3). >>>>>=20 >>>>> To be honest, I suspect few realize that they are using NFSv2 for = their root fs. >>>>> (They'd see it in a packet trace or via "nfsstat -m", but = otherwise they probably >>>>> think they are using NFSv3 for their root fs.) >>>>>=20 >>>>> rick >>>>=20 >>>> if they do not suspect, they most likely use v3 - due to simple = fact that you have to rebuild loader to use NFSv2 - it is compile time = option. >>>>=20 >>>=20 >>> old systems, 8.x, still use/boot v2, and so do old linux. >>> NetApp has discontinued support for v2, so we had to move this = machines to use FreeBSD server and the day was >>> saved. So, till these machines get upgraded/discontinued we have a = problem. There are several solutions >>> to this issue, but as long as it's a matter of getting rid for the = sake of it, I would vote to keep it a while longer. >>>=20 >>> danny >>>=20 >>>=20 >> Given you are speaking of 8.x I suppose you are using the loader that = comes with >> it, meaning you are safe if we remove it from the loader in 12.0 = (note as said >> by Toomas that is it is already off by default in the 12.0 loader) am = I missing >> something? >>=20 >=20 > as usual, did not read the whole thread, I assumed - wrongly - that = support for v2 would be discontinued. > removing v2 support from the boot process is fine! great, go for it. = It will only involve newer > hosts, and simplifying the boot process is always a good idea. >=20 > sorry for the noise. > danny >=20 yes, just to clarify, the current loader code (in current), is having = NFS code implemented as: #ifdef OLD_NFSV2 v2 implementation is here #else v3 implementation is here #endif Which does mean that pxeboot/loader.efi is built by default to use v3 = only, but we do have 2 parallel implementations of the NFS readers. And = yes, the question is just about boot loader reader code (we do not = implement NFS writes) - and we are *not* talking about server side = there. Indeed it also is possible to merge those 2 version implementations, but = to be honest, I see very little point of doing that either, even if = there is some setup still with v2 only server, there is still an option = just to use TFTP based boot - especially given that current boot loader = does provide parallel option to use either NFS or TFTP (via dhcp option = 150), with existing binaries - that is, without having to re-compile. rgds, toomas From owner-freebsd-current@freebsd.org Tue Mar 21 09:15:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF7C9D147DF; Tue, 21 Mar 2017 09:15:39 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4F72E2; Tue, 21 Mar 2017 09:15:39 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 090F2BDC91; Tue, 21 Mar 2017 10:15:37 +0100 (CET) Received: from atuin.in.mat.cc (atuin.in.mat.cc [79.143.241.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by prod2.absolight.net (Postfix) with ESMTPSA id BB2EEBDC89; Tue, 21 Mar 2017 10:15:36 +0100 (CET) Subject: Re: ELF binary type "3" not known. To: Chris H , Kevin Lo References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> <20170321051455.GA38562@ns.kevlo.org> <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> Cc: FreeBSD CURRENT , FreeBSD ports From: Mathieu Arnold Organization: Absolight / The FreeBSD Foundation Message-ID: <4432f7fd-e18a-e8fe-9f7c-681e300c0ff1@FreeBSD.org> Date: Tue, 21 Mar 2017 10:15:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OebqUWdFQjgmbDPdC4vSLw5IMC8vNO7LC" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 09:15:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OebqUWdFQjgmbDPdC4vSLw5IMC8vNO7LC Content-Type: multipart/mixed; boundary="xpm0ojIaiHso3Fr5E3AFJHPqpg7Rf2mHJ"; protected-headers="v1" From: Mathieu Arnold To: Chris H , Kevin Lo Cc: FreeBSD CURRENT , FreeBSD ports Message-ID: <4432f7fd-e18a-e8fe-9f7c-681e300c0ff1@FreeBSD.org> Subject: Re: ELF binary type "3" not known. References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> <20170321051455.GA38562@ns.kevlo.org> <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> In-Reply-To: <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> --xpm0ojIaiHso3Fr5E3AFJHPqpg7Rf2mHJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 21/03/2017 =C3=A0 06:22, Chris H a =C3=A9crit : > On Tue, 21 Mar 2017 13:14:56 +0800 Kevin Lo wrote > >> On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote: >>> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" = wrote >>> >>>> I'm not sure which of the two lists I'm directing >>>> this to is the best/correct one. So I picked both. >>>> >>>> To the point; I received this message during a big >>>> build session. I was only able to catch the one from >>>> x11/nvidia-driver in such a way as to actually get >>>> the entire message: >>>> >>>> Installing nvidia-driver-375.26_1... >>>> ELF binary type "3" not known. >>>> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error >>>> >>>> I built && installed emulators/linux_base-c7 *prior* >>>> to installing this. This is on a: >>>> >>>> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: >>>> Sun Mar 5 09:01:30 PST 2017 amd64 >>> Sorry. Forgot to add the ports revision. >>> >>> revision 435383 >> Did you do kldload linux64 ? > Thanks for the reply, Kevin. > Yes. Both before building/installing nvidia-driver, > and via loader.conf(5): > > linux_load=3D"YES" > nvidia-modeset_load=3D"YES" > So your answer is not "Yes" but "No", you don't have linux64, you need linux64_load=3Dyes too. --=20 Mathieu Arnold --xpm0ojIaiHso3Fr5E3AFJHPqpg7Rf2mHJ-- --OebqUWdFQjgmbDPdC4vSLw5IMC8vNO7LC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJY0O84XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85I5FsP/1HI/4RSpjTQyT5zVuzNPJu6 w5KGZFZ0QUYlusKDfqYSn6MWsyLP+JQsQfk8cKJDXwfASUeoCxnRFUaROtF36cO+ E+wvLmfg1sGd6ClAqh9qZ8zo7O/SsbtWZTeVhPagxe4p5iW0NVJ20UTiqA23uOsB aTzc804RiJURu4iziuCTd8hygwL3MXoHjTSUzLHa5DPpCWIYW3F1Bmk8FxSAOa/H odAz1iNWWPiwHK3kWqnDZHufZI0R7WCtaVE1q/zxHD6ifZhmliGzdk7N73n/4FT7 NIKJTZluQ/Db10TST0X7HR2pl3bSR/6R7XvpOR3WSg1xeUawv5YDQ5h9nonanXJN +kSzeR/b5M9dJshJM7xLBWKZJIZwTfaxRECKvgBlUfsPMBzfBkAOWDy1izu7CTyd aen32hq3T/aoE8wc0YEm1di7qeBWoZVwKM9CKRbukzbzy8CQveMR9Fc0Ly2xS3pN 5CyVJtlbr5SAdEjW3Va9l+up0oG1Z+D+a3rc5C8H58ILOcS5BHDBF9mbHQKXs0ac Kng6a3Tzb8Y0+pAn11WP2EBSSupiD5s0DPiwzYc2yMJoc4hNLbebbQo5Qm/YQ0GT jcdOV8amGuFVmUgx1/lXH1WYjg95eXYSAFR/7L1b12WvUO9OmIBmB1g7givHLZUe heA4gvFJDHFhqKmpH0u0 =/pAf -----END PGP SIGNATURE----- --OebqUWdFQjgmbDPdC4vSLw5IMC8vNO7LC-- From owner-freebsd-current@freebsd.org Tue Mar 21 05:16:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88EDCD15FAF for ; Tue, 21 Mar 2017 05:16:21 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8F587A for ; Tue, 21 Mar 2017 05:16:20 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LZzKf-1cTCg40nrJ-00ljIx; Tue, 21 Mar 2017 06:16:05 +0100 Date: Tue, 21 Mar 2017 06:16:03 +0100 From: "O. Hartmann" To: "Chris H" Cc: "FreeBSD CURRENT" Subject: Re: why are the GEOM secondary GPT tables always corrupt? Message-ID: <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net> References: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D3jbmfa7d0XvX6JemfmlP1VrBNKLuy+ELMIfmbeCB1E8qvtpVLG iz1w2ine7Az9CvdwtRhtdInImefdCWR5vMquWAgI4v2xZ+MttGcwqTjxgCaVU2kvNmcWuq/ M/mgWQezdFfMOJXXLIPQttyPPecwXu5hZjTT/4yEIXK+dwgOwldrh/vSijRIYpQOY2sJ5ok wwSgiWfbkRaHbYzaG5YCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:At3hG7OS7uQ=:gBEc5NHIAoILObmGB3AffI IkMU/7BHEI6a4LyKsfdobCT5HOdtdMB1nh6eUQahV+KEdc1SXhxCLe7Fyp/J5G4NTO6jo53Pv ei/XDMdfpCWA0JFCcggg3nKvtg5P9QJ2PRyF9PJ01oauUd2ghBynGRcDu1a3yPes9Ok6o2lqO Dwm0w/2kcZXLlxZMF0mBqu5Ev62RJUzeFY7Nh2Ezl43aFO1BDGSBH58wkVmUKB1VIYujv9Fy7 9j0NfA02hkulda7XR1p7b/jGBseJDM3EY3mFryPhsHrvvU3Sg+u959qKKQZtDlFsfPmeAv1MZ lrwSKL55AQEB112M6Pa4CMMc5AjrF5e5OseHwiRivFGy2sa0leehBt10u8EPZ8XuJsZR6+btx YkqyFlwk0aPql/ns/6YshUuF6y3gJr5JfRDvugDq9+DmVPjKRr7S/NdtZrhAukPwupkRmY4ow F424Dy0al1IaVoTZSS/nuDrGStNkaAj2sLBPGwGYcVqdDbwLS/C1P3601PGM81ZjILn3HgMTc ViGdvV2soY1xVuB+ixNoq2L/gM4XaPCldteWHqIvW4/wkZFbNHtPgMcEcAPr60sXtkIV42w70 7RNxI0GQ03IAu1EgFEEl+w7ym3bDlD8rcshyS2fw/yDl20vF4XQGMmJv1CAPHOFx23lS4HXsU LW4zfiVt7YLlF2IHkYTu2389J8gGdEeEu/GDqpZRMIZWi9H6QeSxiZSfdmykVrWqbFRAHtlah 8ckc1NEeZt20UwIHcfPguKmxv25hpaATfNOkEFK/Mzz9pKi31zXPcLz00tY6JDHO+ZS0FHxuC yvrtHgM X-Mailman-Approved-At: Tue, 21 Mar 2017 11:03:59 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 05:16:21 -0000 On Mon, 20 Mar 2017 19:08:41 -0700 "Chris H" wrote: > I've seen this discussed before, but there were so many > "solutions", I was left feeling this *must* be some sort > of bug in GEOM/gpart. So. I just blew away the tables on > a USB3 flash drive: > > # gpart destroy -F da0 > > # gpart create -s gpt da0 > > # gpart add -t freebsd-ufs -l jails da0 > > # newfs -U /dev/gpt/jails > > Added an entry to fstab(5) > OK this should be good to go. Mount, and umount > all return as expected, as does fsck(8). > > Upon reboot, I receive the following: > > /dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0% > fragmentation) > GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or > invalid. > GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery > suggested. > > But why? > > This is on: > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64 > > Thanks for any information. > > --Chris > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I see this when I put a disk image, which is smaller than the entire device (for instance, 8GB USB flash drive with a UEFI booting (GPT) NanoBSD image of 1 GB in size. I do not know what exactly causes the problem, but it can be fixed by issuing "gpart recover DEV". I think the secondary GTP table is supposed to reside on the physically last blocks of the device (physically). oh From owner-freebsd-current@freebsd.org Tue Mar 21 11:26:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C872CD16487; Tue, 21 Mar 2017 11:26:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A136A1A98; Tue, 21 Mar 2017 11:26:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (115-166-5-28.dyn.iinet.net.au [115.166.5.28]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v2LBQc3e035713 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Mar 2017 04:26:41 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: effect of strip(1) on du(1) To: "Rodney W. Grimes" , Subbsd References: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Cc: Peter Jeremy , freebsd-hackers , freebsd-current Current From: Julian Elischer Message-ID: <5688704a-83fe-b5dc-fc21-03fb4a560a4b@elischer.org> Date: Tue, 21 Mar 2017 19:26:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Mar 2017 11:33:31 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 11:26:45 -0000 On 3/3/17 8:31 am, Rodney W. Grimes wrote: >> On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: >>> On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: >>>> During some interval after strip call, du will show 512B for any file. >>>> If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: >>> What filesystem are you using? strip(1) rewrites the target file and du(1) >>> reports the number of blocks reported by stat(2). It seems that you are >>> hitting a situation where the file metadata isn't immediately updated. >>> >>> -- >>> Peter Jeremy >> >> Got it. My filesystem is ZFS. Looks like when ZFS open and write data >> to file, we get wrong number of blocks during a small interval after >> writing. Thanks for pointing this out! > Even if that is the case file system cache effects should NOT be > visible to a userland process. This is NOT as if your running > 2 different processing beating on a file. Your test cases are > serialially syncronous shell invoked commands seperated with > && the results should be exact and predictable. > > When strip returns the operation from the userland perspecive > is completed and any and all processeses started after that > should have the view of the completed strip command. > > This IS a bug. actually it's all in how you look at it. Due to the way ZFS is doing the work and the metadata transitions, that amount of storage is actually directly attributable to that file's existence. so from that perspective the du is correct. From owner-freebsd-current@freebsd.org Tue Mar 21 12:47:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0AB4D16622; Tue, 21 Mar 2017 12:47:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 730871F50; Tue, 21 Mar 2017 12:47:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id n11so2726013wma.0; Tue, 21 Mar 2017 05:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=pLN1Olj46FKX3NV4nxCcL/FW+lb0EDmY+GiYb1p93PQ=; b=qwnaZKAqGYdh1PHlFREAUd0I2C5K/XcKD1Yye8I6av4q5ErOGo/LD3xJ4LGCxOat1z 7/bYKGDkq3/A19o3WY+14W0A9o2cMvi4wF1zw6KIMiXoy0OLgpaPGK4hVDMd8C9RUF0I 26cN0Nv5iONdRFqBOGKFtOBXbN8shqQfpcVB3r4l/WgwC3STYt6igxZdhPIceqsxJpS9 IzZVNq1K0WBL8e1d/MOss2mvArNR/AIyC8wjsMDiZMR5/658po8/gZq3UAIOuAx+zR+X kivgwqCfkDWwNMjPDJnwo9AYhtqqCsurJYQpMJwWK5H4uzEiaYL0wBPPbcesEgUZbnzy i6wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=pLN1Olj46FKX3NV4nxCcL/FW+lb0EDmY+GiYb1p93PQ=; b=iN/A165qn8MkqlaV1R0f02CeATjt7v9dn2OTzQRXUmBGUbBRZ9dFE7JawXOIVWcbwW LjAH6Qy00IAw3f/L35WazfNTHmsrT7+3cCEA05kyZYEHoiYiNNlOJp8jyXcao/soYB6n JXE00GfUhQtnO/i0UGFqSWuU8V+Hhyer6kvT9IFoyWgeZj78T55X/Xa6jAzcP7ulKWHR Pld1iI+EYbmHaFVaNM+3wM7MLEyP3m7CeLH4qXIIks7BStuB9cy3219caZ3SZg1wFG5s VqQblRYu/qZ+BbxBEIqbsCTY0U5lyfvb0PFITuY2NmhG66SFoPn20lwuOhoE7SB2Yztx GOjw== X-Gm-Message-State: AFeK/H2sh1jrQEFinTkWBuwFf3VeyADLD5ev3r9VRMH3GCdEBpNTO63Z1ndhacUMDDkeEA== X-Received: by 10.28.55.138 with SMTP id e132mr2612860wma.6.1490100445690; Tue, 21 Mar 2017 05:47:25 -0700 (PDT) Received: from ernst.home (p4FCA6070.dip0.t-ipconnect.de. [79.202.96.112]) by smtp.gmail.com with ESMTPSA id t63sm17504173wme.16.2017.03.21.05.47.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 Mar 2017 05:47:24 -0700 (PDT) Date: Tue, 21 Mar 2017 13:47:23 +0100 From: Gary Jennejohn To: Mathieu Arnold Cc: Chris H , Kevin Lo , FreeBSD CURRENT , FreeBSD ports Subject: Re: ELF binary type "3" not known. Message-ID: <20170321134723.6fd5a1b0@ernst.home> In-Reply-To: <4432f7fd-e18a-e8fe-9f7c-681e300c0ff1@FreeBSD.org> References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> <20170321051455.GA38562@ns.kevlo.org> <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> <4432f7fd-e18a-e8fe-9f7c-681e300c0ff1@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 12:47:29 -0000 On Tue, 21 Mar 2017 10:15:35 +0100 Mathieu Arnold wrote: > Le 21/03/2017 __ 06:22, Chris H a __crit : > > On Tue, 21 Mar 2017 13:14:56 +0800 Kevin Lo wrote > > > >> On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote: > >>> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" wrote > >>> > >>>> I'm not sure which of the two lists I'm directing > >>>> this to is the best/correct one. So I picked both. > >>>> > >>>> To the point; I received this message during a big > >>>> build session. I was only able to catch the one from > >>>> x11/nvidia-driver in such a way as to actually get > >>>> the entire message: > >>>> > >>>> Installing nvidia-driver-375.26_1... > >>>> ELF binary type "3" not known. > >>>> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > >>>> > >>>> I built && installed emulators/linux_base-c7 *prior* > >>>> to installing this. This is on a: > >>>> > >>>> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > >>>> Sun Mar 5 09:01:30 PST 2017 amd64 > >>> Sorry. Forgot to add the ports revision. > >>> > >>> revision 435383 > >> Did you do kldload linux64 ? > > Thanks for the reply, Kevin. > > Yes. Both before building/installing nvidia-driver, > > and via loader.conf(5): > > > > linux_load="YES" > > nvidia-modeset_load="YES" > > > > So your answer is not "Yes" but "No", you don't have linux64, you need > linux64_load=yes too. > Or remove the option for Linux support (make config). I've never used it myself and have no idea what benefits it's supposed to provide. That would eliminate your Linux problems re nvidia-driver. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Mar 21 16:04:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E61B8D168C5 for ; Tue, 21 Mar 2017 16:04:07 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE7141132 for ; Tue, 21 Mar 2017 16:04:07 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cqMGV-000HiV-VQ for freebsd-current@freebsd.org; Tue, 21 Mar 2017 17:04:07 +0100 Date: Tue, 21 Mar 2017 17:04:07 +0100 From: Kurt Jaeger To: freebsd-current@freebsd.org Subject: sysctl -a hangs ? Message-ID: <20170321160407.GJ64587@home.opsec.eu> 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.23 Precedence: 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, 21 Mar 2017 16:04:08 -0000 Hello, I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro X11SSZ-TLN4F board, and pkg install intel-ixl-kmod and now: sysctl -a hangs. Any quick ideas how to debug this ? -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Tue Mar 21 16:14:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3E2BD16E90 for ; Tue, 21 Mar 2017 16:14:43 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id B745D1A42 for ; Tue, 21 Mar 2017 16:14:43 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 912FB17AE9; Tue, 21 Mar 2017 09:14:38 -0700 (PDT) Date: Tue, 21 Mar 2017 09:14:38 -0700 From: hiren panchasara To: Kurt Jaeger Cc: freebsd-current@freebsd.org Subject: Re: sysctl -a hangs ? Message-ID: <20170321161438.GH80268@strugglingcoder.info> References: <20170321160407.GJ64587@home.opsec.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KscVNZbUup0vZz0f" Content-Disposition: inline In-Reply-To: <20170321160407.GJ64587@home.opsec.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 16:14:43 -0000 --KscVNZbUup0vZz0f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/21/17 at 05:04P, Kurt Jaeger wrote: > Hello, >=20 > I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro > X11SSZ-TLN4F board, and >=20 > pkg install intel-ixl-kmod >=20 > and now: >=20 > sysctl -a >=20 > hangs. Any quick ideas how to debug this ? If it's just not responding to anything, you can try to panic the box, got to db> and see if you can find sleepchain/lockchain? You can also take a dump and try to look at same with kgdb scripts. You'd need kernel with WITNESS. Cheers, Hiren --KscVNZbUup0vZz0f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJY0VFrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lKSQH/A8LNNeC/010g2b88Z1Zwauq qndI5h+QATPXJJLr3ESOU6WHNrYg4QjSHFezu2eM+9z3B1D/4pwuuCPqrZM5nR63 v7BGPfyXKFu1CESPPfkP3t1AJyfhxhE6P1oj0UIscteG4swfKHKoEpXda6NT57TP IJJyimuENPs4ooyE1pgADBO5wbX5ARKGt9sQjkU/vA7vnsV2CWycSFL8ma8kBDMo 91+Jvz/xLW0XHrIkFC6VwT8xvi2jJAldq/jlvXLe1ZbBZlsLpzSyDDzis6KoHbML moeaG43cck3vp43tQrkcsC2N40hutlYwG3yZlAwM2rNr0wyoIWHKGJDJf4SHmyY= =Gi7c -----END PGP SIGNATURE----- --KscVNZbUup0vZz0f-- From owner-freebsd-current@freebsd.org Tue Mar 21 16:29:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD8EED16561 for ; Tue, 21 Mar 2017 16:29:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 A86C26E8 for ; Tue, 21 Mar 2017 16:29:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4695A1FE021; Tue, 21 Mar 2017 17:28:55 +0100 (CET) Subject: Re: sysctl -a hangs ? To: hiren panchasara , Kurt Jaeger References: <20170321160407.GJ64587@home.opsec.eu> <20170321161438.GH80268@strugglingcoder.info> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: Date: Tue, 21 Mar 2017 17:29:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170321161438.GH80268@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 16:29:55 -0000 On 03/21/17 17:14, hiren panchasara wrote: > On 03/21/17 at 05:04P, Kurt Jaeger wrote: >> Hello, >> >> I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro >> X11SSZ-TLN4F board, and >> >> pkg install intel-ixl-kmod >> >> and now: >> >> sysctl -a >> >> hangs. Any quick ideas how to debug this ? > > If it's just not responding to anything, you can try to panic the box, > got to db> and see if you can find sleepchain/lockchain? > You can also take a dump and try to look at same with kgdb scripts. > You'd need kernel with WITNESS. Hi, procstat -ak Will tell you where it is stuck. --HPS From owner-freebsd-current@freebsd.org Tue Mar 21 16:31:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19E73D1665D for ; Tue, 21 Mar 2017 16:31:57 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3E5EADF for ; Tue, 21 Mar 2017 16:31:56 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cqMhS-000HmR-Pd; Tue, 21 Mar 2017 17:31:58 +0100 Date: Tue, 21 Mar 2017 17:31:58 +0100 From: Kurt Jaeger To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sysctl -a hangs ? Message-ID: <20170321163158.GK64587@home.opsec.eu> References: <20170321160407.GJ64587@home.opsec.eu> <20170321161438.GH80268@strugglingcoder.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 16:31:57 -0000 Hi! > >> I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro > >> X11SSZ-TLN4F board, and > >> > >> pkg install intel-ixl-kmod > >> > >> and now: > >> > >> sysctl -a > >> > >> hangs. Any quick ideas how to debug this ? > > > > If it's just not responding to anything, you can try to panic the box, > > got to db> and see if you can find sleepchain/lockchain? > > You can also take a dump and try to look at same with kgdb scripts. > > You'd need kernel with WITNESS. > > Hi, > > procstat -ak > > Will tell you where it is stuck. Here we go: 1489 100739 sysctl - __mtx_lock_sleep sleepq_catch_signals sleepq_wait_sig _sleep AcpiOsAcquireMutex AcpiUtAcquireMutex AcpiExEnterInterpreter AcpiNsEvaluate AcpiUtEvaluateObject AcpiUtExecute_HID AcpiGetObjectInfo acpi_child_pnpinfo_str_method device_sysctl_handler sysctl_root_handler_locked sysctl_root userland_sysctl sys___sysctl amd64_syscall -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Tue Mar 21 17:05:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC233D165EE for ; Tue, 21 Mar 2017 17:05:57 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8236777F for ; Tue, 21 Mar 2017 17:05:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2LH63GN004333 for ; Tue, 21 Mar 2017 10:06:09 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20170321134723.6fd5a1b0@ernst.home> References: <5014933e6348cb6eedcc2d33eab7b21d@ultimatedns.net> <20170321051455.GA38562@ns.kevlo.org> <6925bec4dc110e60a955ee773a368aef@ultimatedns.net> <4432f7fd-e18a-e8fe-9f7c-681e300c0ff1@FreeBSD.org>, <20170321134723.6fd5a1b0@ernst.home> From: "Chris H" Subject: Re: ELF binary type "3" not known. Date: Tue, 21 Mar 2017 10:06:09 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <7002670eabc16779ed8f141f24a6771d@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 17:05:57 -0000 On Tue, 21 Mar 2017 13:47:23 +0100 Gary Jennejohn wrote > On Tue, 21 Mar 2017 10:15:35 +0100 > Mathieu Arnold wrote: > > > Le 21/03/2017 __ 06:22, Chris H a __crit : > > > On Tue, 21 Mar 2017 13:14:56 +0800 Kevin Lo wrote > > > > > >> On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote: > > >>> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H" > > >>> wrote > > >>>> I'm not sure which of the two lists I'm directing > > >>>> this to is the best/correct one. So I picked both. > > >>>> > > >>>> To the point; I received this message during a big > > >>>> build session. I was only able to catch the one from > > >>>> x11/nvidia-driver in such a way as to actually get > > >>>> the entire message: > > >>>> > > >>>> Installing nvidia-driver-375.26_1... > > >>>> ELF binary type "3" not known. > > >>>> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error > > >>>> > > >>>> I built && installed emulators/linux_base-c7 *prior* > > >>>> to installing this. This is on a: > > >>>> > > >>>> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: > > >>>> Sun Mar 5 09:01:30 PST 2017 amd64 > > >>> Sorry. Forgot to add the ports revision. > > >>> > > >>> revision 435383 > > >> Did you do kldload linux64 ? > > > Thanks for the reply, Kevin. > > > Yes. Both before building/installing nvidia-driver, > > > and via loader.conf(5): > > > > > > linux_load="YES" > > > nvidia-modeset_load="YES" > > > > > > > So your answer is not "Yes" but "No", you don't have linux64, you need > > linux64_load=yes too. > > > > Or remove the option for Linux support (make config). I've never > used it myself and have no idea what benefits it's supposed to > provide. > > That would eliminate your Linux problems re nvidia-driver. Last I checked (actually read all the data), the Linux ABI is pretty much a requirement. As it's (nvidia-driver) actually the Linux (version of the) driver. But since FreeBSD (can) supports the Linux ABI, it just "works". > > -- > Gary Jennejohn Thanks for taking the time to reply, Gary. --Chris From owner-freebsd-current@freebsd.org Tue Mar 21 17:55:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A66B1D16B03 for ; Tue, 21 Mar 2017 17:55:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34142AFE; Tue, 21 Mar 2017 17:55:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2LHtS4L003198 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 19:55:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2LHtS4L003198 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2LHtRWX003134; Tue, 21 Mar 2017 19:55:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Mar 2017 19:55:27 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170321175527.GN43712@kib.kiev.ua> References: <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 17:55:40 -0000 On Tue, Mar 21, 2017 at 02:30:38AM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > > Yes, I have to somewhat retract my claims, but then I have another set > > of surprises. > Righto. > > > I realized (remembered) that nfs has its own VOP_PUTPAGES() method. > > Implementation seems to directly initiate write RPC request using the > > pages as the source buffer. I do not see anything in the code which > > would mark the buffers, which possibly contain the pages, as clean, > > or mark the buffer range as undirty. > The only place I know of that the code does this is in the "struct buf's" > hanging off of v_bufobj.bo_dirty. > I imagine there would be a race between the write-back to the NFS server > and further changes to the page by the process. For the most part, the > VOP_PUTPAGES() is likely to happen after the process is done modifying > the pages (often exited). For cases where it happens sooner, I would expect > the page(s) to be written multiple times, but the last write should bring > the file "up to date" on the server. > > > At very least, this might cause unnecessary double-write of the same > > data. I am not sure if it could cause coherency issues between data > > written using mappings and write(2). Also, both vm_object_page_clean() > > and vfs_busy_pages() only ensure the shared-busy state on the pages, > > so write(2) can occur while pageout sends data to server, causing > > 'impossible' content transmitted over the wire. > I'm not sure what you mean by impossible content, but for NFS the only > time the file on the NFS server should be "up to date" will be after a file > doing write(2) writing has closed the fd (and only then if options like > "nocto" has not been used) or after an fsync(2) done by the process > doing the writing. By 'impossible' I mean some arbitrary combination of bytes which were written by many means to the file at arbitrary moments. In other words, the file content, or even a single page/block content is not atomic WRT the client updates. > For mmap'd writing, I think msync(2) is about the only > thing the process can do to ensure the data is written back to the server. > (There was a patch to the NFS VOP_CLOSE() that does a vm_object_page_clean() > but without the OBJPC_SYNC flag which tries to make sure the pages get written > shortly after the file is closed. Of course, an mmap'd file can still be modified by the > process after close(2), so it is "just an attempt to make the common case work". > I don't recall, but I don't think I was the author of this patch.) > > I also wouldn't be surprised that multiple writes of the same page(s) occurs > under certain situations. (NFS has no rules w.r.t. write ordering. Each RPC is > separate and simply writes N bytes at file offset S.) It definitely happens when > there are multiple write(2)s of partial buffers, depending on when a sync() happens. > > > Could you, please, explain the reasons for such implementation of > > ncl_putpage() ? > Well, I wasn't the author (it was just cribbed from the old NFS client and I don't > know who wrote it), so I'm afraid I don't know. (It's code I avoid changing because I don't > really understand it.) > > I suspect that the author assumed that processes would either mmap the file > or use write(2) and wouldn't ever try and mix them to-gether. Or, what seems more likely to me, the code was written on a system where buffer cache and page queues are not coherent. Anyway, my position is that nfs VOP_PUTPAGES() should do write through buffer cache, not issuing the direct rpc call with the pages as source. Then your patch would need an update with the mentioned call to ncl_flush(). From owner-freebsd-current@freebsd.org Tue Mar 21 21:41:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65ED3D17CFD for ; Tue, 21 Mar 2017 21:41:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660057.outbound.protection.outlook.com [40.107.66.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0859916F6; Tue, 21 Mar 2017 21:41:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM (10.169.141.138) by YQBPR01MB0178.CANPRD01.PROD.OUTLOOK.COM (10.169.141.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 21:41:19 +0000 Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) by YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 21:41:19 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIABrxcAgAA8zEOAAQwZgIAAO42g Date: Tue, 21 Mar 2017 21:41:19 +0000 Message-ID: References: <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> , <20170321175527.GN43712@kib.kiev.ua> In-Reply-To: <20170321175527.GN43712@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YQBPR01MB0178; 7:HPiQDFBvN5uxzY98+VJSmz7B/5B4xAWraNMQ6nnHd80i6y3ZMu6IYCyRH3zR3N9rhShUZ/hwIRp6q96/kPZbU7ivcaEb82ELukPGddUYF6YdYTyqgiuwdVVaejqpje0UoQJOnsugNFv4wJKFo6LYDnSYZWYNC/6WZr1V01WJ77oCHZ/1TMi3TLVwoPsdi8svdyZnvzwN3JimvOf6N6c3lN9PHbI0oeGNI5zpVYbFc9iuEawnPylI4LgTUods2G9udNAQDBtYQDFmNcNCelKDUBAwlRhMMduFtNfq/R8Pe/I4Vn+JtoWAXGmB+U074PB6Qaye+vpPX66UowGRBI4UIg== x-ms-office365-filtering-correlation-id: d91edc00-9a0b-496a-b643-08d470a302d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YQBPR01MB0178; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:YQBPR01MB0178; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0178; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(52314003)(39060400002)(93886004)(106356001)(6246003)(110136004)(38730400002)(4326008)(74482002)(8676002)(189998001)(2950100002)(7696004)(6916009)(6506006)(77096006)(6436002)(2906002)(54906002)(9686003)(55016002)(1411001)(86362001)(54356999)(50986999)(76176999)(8936002)(81166006)(305945005)(2900100001)(53936002)(3660700001)(68736007)(5660300001)(122556002)(74316002)(3280700002)(33656002)(102836003)(229853002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0178; H:YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 21 Mar 2017 21:41:19.4544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0178 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 21 Mar 2017 21:41:24 -0000 Konstantin Belousov wrote: [stuff snipped] > By 'impossible' I mean some arbitrary combination of bytes which were > written by many means to the file at arbitrary moments. In other words, > the file content, or even a single page/block content is not atomic > WRT the client updates. Yes. For multiple processes writing the same file, I'd agree that's going t= o happen unless the processes use advisoty byte range locking to order the updates. And, I'm pretty sure a process that does both write(2) syscalls on a file a= nd modifies pages of it that are mmap()'d will produce "interesting" results a= s you describe. [stuff snipped] > Or, what seems more likely to me, the code was written on a system where > buffer cache and page queues are not coherent. > > Anyway, my position is that nfs VOP_PUTPAGES() should do write through > buffer cache, not issuing the direct rpc call with the pages as source. Hmm. Interesting idea. Since a "struct buf" can only refer to contiguous by= tes, I suspect each page might end up as a separate "struct buf", at least until= some clustering algorithm succeeded in merging them. I would agree that it would be nice to change VOP_PUTPAGES(), since it curr= ently results in a lot of 4K writes (with FILE_SYNC I think?) and this is normall= y slow/inefficient for the server. (It would be interesting to try your suggestion above and s= ee if the pages would cluster into larger writes. Also, the "struct buf" code knows h= ow to do UNSTABLE writes followed by a Commit.) --> I am currently working on a pNFS server (which is coming along fairly w= ell), so I have no idea if/when I might get around to trying to do this. > Then your patch would need an update with the mentioned call to ncl_flush= (). Yes. rick From owner-freebsd-current@freebsd.org Wed Mar 22 02:21:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06193D17CB0 for ; Wed, 22 Mar 2017 02:21:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 BA7811C2A for ; Wed, 22 Mar 2017 02:21:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3244 invoked from network); 22 Mar 2017 02:21:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2017 02:21:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 21 Mar 2017 22:21:11 -0400 (EDT) Received: (qmail 8016 invoked from network); 22 Mar 2017 02:21:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Mar 2017 02:21:11 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id F217DEC8974; Tue, 21 Mar 2017 19:21:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: Date: Tue, 21 Mar 2017 19:21:08 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> To: Andrew Turner X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 02:21:19 -0000 On 2017-Mar-18, at 9:10 PM, Mark Millard wrote: > > On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: > >> A new, significant discovery follows. . . >> >> While checking out use of procstat -v I ran >> into the following common property for the 3 >> programs that I looked at: >> >> A) My small test program that fails for >> a dynamically allocated space. >> >> B) sh reporting Failed assertion: "tsd_booted". >> >> C) su reporting Failed assertion: "tsd_booted". >> >> Here are example addresses from the area of >> incorrectly zeroed memory (A then B then C): >> >> (lldb) print dyn_region >> (region *volatile) $0 = 0x0000000040616000 >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x0000000040618520 >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x0000000040618520 > > That last above was a copy/paste error. Correction: > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x000000004061d520 > >> The first is from dynamic allocation ending up >> in the area. The other two are from libc.so.7 >> globals/statics ending up in the general area. >> >> It looks like something is trashing a specific >> memory area for some reason, rather independently >> of what the program specifics are. I probably should have noted that the processes involved were: child/parent then grandparent and then great grandparent. The grandparent was sh and the great grandparent was su. The ancestors in the process tree are being damaged, not just the instances of the program that demonstrates the problem. >> Other notes: >> >> At least for my small program showing failure: >> >> Being explicit about the combined conditions for failure >> for my test program. . . >> >> Both tcache enabled and allocations fitting in SMALL_MAXCLASS >> are required in order to make the program fail. >> >> Note: >> >> lldb) print __je_tcache_maxclass >> (size_t) $0 = 32768 >> >> which is larger than SMALL_MAXCLASS. I've not observed >> failures for sizes above SMALL_MAXCLASS but not exceeding >> __je_tcache_maxclass. >> >> Thus tcache use by itself does not seen sufficient for >> my program to get corruption of its dynamically allocated >> memory: the small allocation size also matters. >> >> >> Be warned that I can not eliminate the possibility that >> the trashing changed what region of memory it trashed >> for larger allocations or when tcache is disabled. > > The pine64+ 2GB eventually got into a state where: > > /etc/malloc.conf -> tcache:false > > made no difference and the failure kept occurring > with that symbolic link in place. > > But after a reboot of the pin46+ 2GB > /etc/malloc.conf -> tcache:false was again effective > for my test program. (It was still present from > before the reboot.) > > I checked the .core files and the allocated address > assigned to dyn_region was the same in the tries > before and after the reboot. (I had put in an > additional raise(SIGABRT) so I'd always have > a core file to look at.) > > Apparently /etc/malloc.conf -> tcache:false was > being ignored before the reboot for some reason? I have also discovered that if the child process in an example like my program does a: (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED); after the fork but before the sleep/swap-out/wait then the problem does not happen. This is without any read or write access to the memory between the fork and sleep/swap-out/wait. By contrast such POSIX_MADV_WILLNEED use in the parent process does not change the failure behavior. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Mar 22 07:23:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5AA8D17926 for ; Wed, 22 Mar 2017 07:23:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43FB1CBD; Wed, 22 Mar 2017 07:23:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2M7NVDe079850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Mar 2017 09:23:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2M7NVDe079850 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2M7NVvJ079849; Wed, 22 Mar 2017 09:23:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Mar 2017 09:23:31 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170322072331.GQ43712@kib.kiev.ua> References: <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> <20170321175527.GN43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 07:23:42 -0000 On Tue, Mar 21, 2017 at 09:41:19PM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > > Anyway, my position is that nfs VOP_PUTPAGES() should do write through > > buffer cache, not issuing the direct rpc call with the pages as source. > Hmm. Interesting idea. Since a "struct buf" can only refer to > contiguous bytes, I suspect each page might end up as a separate > "struct buf", at least until some clustering algorithm succeeded in > merging them. > > I would agree that it would be nice to change VOP_PUTPAGES(), since > it currently results in a lot of 4K writes (with FILE_SYNC I think?) > and this is normally slow/inefficient for the server. (It would be > interesting to try your suggestion above and see if the pages would > cluster into larger writes. Also, the "struct buf" code knows how to > do UNSTABLE writes followed by a Commit.) Below is something to discuss. This is not finished, but it worked for the simple tests I performed. Clustering should be somewhat handled by the ncl_write() as is. As an additional advantage, I removed the now unneeded phys buffer allocation. If you agree with the approach on principle, I want to ask what to do about the commit stuff there (I simply removed that for now). Things that needs to be done is to add missed handling of the IO flags to ncl_write(). diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c index 1c225c1469a..562754609b1 100644 --- a/sys/fs/nfsclient/nfs_clbio.c +++ b/sys/fs/nfsclient/nfs_clbio.c @@ -266,9 +266,7 @@ ncl_putpages(struct vop_putpages_args *ap) { struct uio uio; struct iovec iov; - vm_offset_t kva; - struct buf *bp; - int iomode, must_commit, i, error, npages, count; + int ioflags, i, error, npages, count; off_t offset; int *rtvals; struct vnode *vp; @@ -322,44 +320,34 @@ ncl_putpages(struct vop_putpages_args *ap) } mtx_unlock(&np->n_mtx); - /* - * We use only the kva address for the buffer, but this is extremely - * convenient and fast. - */ - bp = getpbuf(&ncl_pbuf_freecnt); - - kva = (vm_offset_t) bp->b_data; - pmap_qenter(kva, pages, npages); PCPU_INC(cnt.v_vnodeout); PCPU_ADD(cnt.v_vnodepgsout, count); - iov.iov_base = (caddr_t) kva; + iov.iov_base = unmapped_buf; iov.iov_len = count; uio.uio_iov = &iov; uio.uio_iovcnt = 1; uio.uio_offset = offset; uio.uio_resid = count; - uio.uio_segflg = UIO_SYSSPACE; + uio.uio_segflg = UIO_NOCOPY; uio.uio_rw = UIO_WRITE; uio.uio_td = td; - if ((ap->a_sync & VM_PAGER_PUT_SYNC) == 0) - iomode = NFSWRITE_UNSTABLE; - else - iomode = NFSWRITE_FILESYNC; + ioflags = IO_VMIO; + if (ap->a_sync & (VM_PAGER_PUT_SYNC | VM_PAGER_PUT_INVAL)) + ioflags |= IO_SYNC; + else if ((ap->a_sync & VM_PAGER_CLUSTER_OK) == 0) + ioflags |= IO_ASYNC; + ioflags |= (ap->a_sync & VM_PAGER_PUT_INVAL) ? IO_INVAL: 0; + ioflags |= (ap->a_sync & VM_PAGER_PUT_NOREUSE) ? IO_NOREUSE : 0; + ioflags |= IO_SEQMAX << IO_SEQSHIFT; - error = ncl_writerpc(vp, &uio, cred, &iomode, &must_commit, 0); + error = VOP_WRITE(vp, &uio, ioflags, cred); crfree(cred); - pmap_qremove(kva, npages); - relpbuf(bp, &ncl_pbuf_freecnt); - - if (error == 0 || !nfs_keep_dirty_on_error) { + if (error == 0 || !nfs_keep_dirty_on_error) vnode_pager_undirty_pages(pages, rtvals, count - uio.uio_resid); - if (must_commit) - ncl_clearcommit(vp->v_mount); - } - return rtvals[0]; + return (rtvals[0]); } /* From owner-freebsd-current@freebsd.org Wed Mar 22 08:05:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20BB2D178BE for ; Wed, 22 Mar 2017 08:05:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1057E2FA for ; Wed, 22 Mar 2017 08:05:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2M857oF055610 for ; Wed, 22 Mar 2017 08:05:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine Date: Wed, 22 Mar 2017 08:05:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Mar 2017 11:04:47 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 08:05:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217994 Sylvain Garrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avg@FreeBSD.org, | |freebsd-current@FreeBSD.org | |, jhb@FreeBSD.org, | |kib@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Mar 22 08:08:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72091D179AA for ; Wed, 22 Mar 2017 08:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61E5D637 for ; Wed, 22 Mar 2017 08:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2M88JE6059928 for ; Wed, 22 Mar 2017 08:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine Date: Wed, 22 Mar 2017 08:08:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Mar 2017 11:19:46 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 08:08:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217994 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-current@FreeBSD.org | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Mar 22 12:57:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BDFDD17D0B for ; Wed, 22 Mar 2017 12:57:30 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBE2A14A9 for ; Wed, 22 Mar 2017 12:57:29 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: by mailman.ysv.freebsd.org (Postfix) id E8614D17D0A; Wed, 22 Mar 2017 12:57:29 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7B25D17D09 for ; Wed, 22 Mar 2017 12:57:29 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: from dyslexicfish.net (deadcat.mail.dyslexicfish.net [45.63.12.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B144D14A8 for ; Wed, 22 Mar 2017 12:57:29 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: from dyslexicfish.net (deadcat.mail.dyslexicfish.net [45.63.12.202]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id v2MCtwIP037010; Wed, 22 Mar 2017 12:55:58 GMT (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id v2MCtwMg037009; Wed, 22 Mar 2017 12:55:58 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201703221255.v2MCtwMg037009@dyslexicfish.net> Date: Wed, 22 Mar 2017 12:55:58 +0000 To: jbtakk@iherebuywisely.com, david@catwhisker.org Cc: current@freebsd.org Subject: Re: how to SVN regenerate [ man awk ] References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [45.63.12.202]); Wed, 22 Mar 2017 12:55:58 +0000 (GMT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 12:57:30 -0000 "Jeffrey Bouquet" wrote: > > If you intend to use "svn up", you should probably review, and > > follow the instructions in, /usr/src/UPDATING. > > but just for one binary? and one man page update? > As in, it is only two files, how to update singly if does not require a buildworld... I've no idea what is causing your current problem, but it's perfectly fine to do: cd /usr/src/usr.bin/awk (for example) make make install make clean make cleandepends I do this kind of thing all the time. Obvious caveats apply: 1) You are no longer tracking a "standard" installation. 2) You may create a problem with mismatched versions of things. 3) Relating to 2), some things may not compile or work as intended due to changes elsewhere that would need to also be applied to the system. But other than that, things should work (to use your example, awk should work fine) Are you doing the 'make install' rather than installing manually? cheers, Jamie From owner-freebsd-current@freebsd.org Wed Mar 22 14:06:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28CF8D17777 for ; Wed, 22 Mar 2017 14:06:11 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 145651D26 for ; Wed, 22 Mar 2017 14:06:11 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 10CD0D17776; Wed, 22 Mar 2017 14:06:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 106BAD17774 for ; Wed, 22 Mar 2017 14:06:11 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C966C1D25 for ; Wed, 22 Mar 2017 14:06:10 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1cqgti-0003qT-N7; Wed, 22 Mar 2017 15:05:58 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1cqgti-00079w-L3; Wed, 22 Mar 2017 15:05:58 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Wed, 22 Mar 2017 14:05:58 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "Jamie Landeg-Jones" CC: "david" , "current" Subject: Re: how to SVN regenerate [ man awk ] Date: Wed, 22 Mar 2017 07:05:58 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <201703221255.v2MCtwMg037009@dyslexicfish.net> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 14:06:11 -0000 On Wed, 22 Mar 2017 12:55:58 +0000, Jamie Landeg-Jones wrote: > "Jeffrey Bouquet" wrote: >=20 > > > If you intend to use "svn up", you should probably review, and > > > follow the instructions in, /usr/src/UPDATING. > > > > but just for one binary? and one man page update?=20 > > As in, it is only two files, how to update singly if does not require a= buildworld... >=20 > I've no idea what is causing your current problem, but it's perfectly fin= e to do: >=20 > cd /usr/src/usr.bin/awk (for example) > make > make install > make clean > make cleandepends >=20 > I do this kind of thing all the time. Obvious caveats apply: >=20 > 1) You are no longer tracking a "standard" installation. > 2) You may create a problem with mismatched versions of things. > 3) Relating to 2), some things may not compile or work as intended due > to changes elsewhere that would need to also be applied to the system. >=20 > But other than that, things should work (to use your example, awk should = work fine) >=20 > Are you doing the 'make install' rather than installing manually? >=20 > cheers, Jamie Hmm... I crafted a reply, then noticed the email was to me. I've been using cd /usr/src/usr.sbin/[someplace] svn up . [indent so not as to appear in history] make cleandepend make depend make obj and if that fails mmv /etc/make.conf / [ not precisely that but same thing ] zsh /tmp/llvm39.sh #/bin/sh export CC=3D/usr/local/bin/clang39=20=20 export CXX=3D/usr/local/bin/clang++39=20=20 export CPP=3D/usr/local/bin/clang-cpp=20 cd $1 # /usr/src/usr.sbin/pw make cleandepend make obj make depend make install ............... to make the build with a new clang that may work better. .............. I've more or less given up until a new buildworld/installworld risky at here, installworld sometimes fails though, and only hope that the many migrating to BSD I see on linux.reddit.com and elsewhere don't pick up on ZFS so much as improvements and robust current fails-installworld-less-often, reinvoke/reinvigorate portmanager [of old], pkgdb -F [long since forgotten], portmaster, portupgrade, etc to be again 2004 style seamlessly integrated into/with packages and the other wish-list stuff I once wrote about [parallel pkg-fetch for production machines depending upon a flat-file /var/db/pkg 'local.sqlite3' that can be awked sed'ed into temporary forgiveness upon a hosed=20 pkg upgrade, then switched back to the newer pkg commands in a duplicate-pkg-methodology on same-production machine framework that would stand far above anything debian arch ubuntu centos etc could do,=20=20 ....................... but mystified still by terse not upto newbie speed in=20 /usr/src/UPDATING to cover all the edge cases, mfsbsd methodologies etc, that people detail in the forums, and on blog posts, that never actually make it into local new-install documentation, that could be done if persons wrote as verbosely and profusely as I seem to do, but only in an ask ask ask and never produce produce manner, for which I apologize, for I have other demands upon my time that conflict and as you can see broadly limit my input to email and the once-yearly bugzilla of note or that passes into irrelevance upon the next iteration of an installworld. ............ OTOH I closely follow HAMMER HAMMER2 improvements as a on-up on UFS2, and openbsd forum details for howtos that do not appear sometimes in the FreeBSD forum. .......... So thanks for the reply to my email. ........... Things are peachy more or less here with FreeBSD, for instance uptime, 16:04 despite daily core files and bland ignorance of kgbd upon the debugging custom kernel backtraces that appear during dmesg, starting Xorg, umounting backup filesystems, and the daily browser freeze if I've too many open, or too large pages in links -g. ............ But enough of wall of text. ............ Thanks again. ............ Jeff=20 PS sorry for the rough draft. I am out of time.=20 .......... From owner-freebsd-current@freebsd.org Wed Mar 22 14:09:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFFBCD178F0; Wed, 22 Mar 2017 14:09:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2281FCF; Wed, 22 Mar 2017 14:09:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ldq55-1cPuqd1lKN-00ixaS; Wed, 22 Mar 2017 15:09:56 +0100 Date: Wed, 22 Mar 2017 15:09:48 +0100 From: "O. Hartmann" To: freebsd-current , freebsd-arm Subject: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found Message-ID: <20170322150948.5c94a5ad@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LGItz8T5i2SOb7a9e+QuFUFCQthFYkwbFCOivT+q7J5C/Q7UkY6 Us20cpc0nVVj0ALivVxb8BKyCya8plDKqEQxYkfmJwviITB9V2f72I2X+tzCGU2Cv+GlWOS 75sVyU+g+85OHoQObXnd7GIC6BhZXE9BO3nFKL8xMwRy/4zzh1QnTruz5bk5fW4pccdMRFM ykGfSgAOTuYM/8yI6BP/w== X-UI-Out-Filterresults: notjunk:1;V01:K0:EehVt2pZOgk=:mTf8Pi+KVyjUp7RP8PCzHr L8b3Id1/Y7WyGVbOHzHZEolvvbCdxcj+srUA/WHAaF2zY59nfIr58pPEZAiA6oxCrylXAyfhr W6iG2JSVDfp9hUv6Sq6mXOxR3w0coSAmIEUN5gCAKWLl4rxA7kyw9d5yzmgxOvdud7/am26GV TMnoa3VApaioAfc+C56vV0GlHfPSpJxjkiPYgPvJs37bnUveFb9Bnp06pG7ppGbWBYhf55wij 7Yl656M/xuJUWGjHraWuF6BV37ISn3bljJCl1dQWgHy/BymjCA5rtGIm4zaslLcandOjNZwLj GA1nJ2lOrQWhNGOl2ckDvLjtikT1FxxLRgrci4C8Io2EPyeC77lw93aVHjmrSIcSAjJySIBjJ 7QzJZflu5RXrg0AEWyKvl1+lnwD8AMrfqH0EY6mL4z2kSoQLJbgSu2qzp4QILQO07pUfezkA7 XedoT6FIPZVWRGTqYbDS0TW6VG+wHPX2EMNdYAUtuVGpBr8f8uz7JW75gmOGzW+NzJeYfxd3O ZuqVVn9iEG3hcG28zApIWd5fQrca1Bo8z1UCzoanPHUR4jEm5gLYZsjDgJO9AO/mY3Zg311O+ eKF6rh2waoKQDevgmBql9BU7QFml/CuQy4bXPTVOg8yzO6YHrslmeoE4dq1MNo1eCyNkta6Ho PgzN1m+0mQc83UwpBzKRWfEs1uCwXdAQi/5N1PhaN/uBud0AyybglKyg0dLUyDMrzFeH4CFEg aLx5+TvuSI6ncJckzXymEwYvaxoz6L77dSx4CMvrNLJxGLurtk2vwk0O5W/r+fVwcGXaohsAN uey2lul X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 14:10:00 -0000 Hello List(s), I'm pretty new to cross compiling on FreeBSD, so to make the introduction short: amazed by the possibilities of FreeBSD on Pine64 and poudriere as the basis of our own ports repository, I try to build a repository of selected ports via poudriere for arm64.aarch64 and - fail! When installaing the jail from a prebuilt world via "-m src=...", the installation fails with: [...] make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: Unable to determine compiler type for CC=cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /pool/sources/CURRENT/src *** Error code 1 [...] I use the option "-m src=" with all of my jails, where for amd64 the source tree and object tree resides in /usr/src and /usr/obj respectively from a buildworld. For poudriere jails intended to be used for cross building, I checked out the whole CURRENT tree (among 11 and 10) at /pool/CURRENT/src (or /pool/11-STABLE/src or /pool/10.3-RELEASE/src) to keep the main tree clean and intact in case I have to patch too much. The hosting system is a 12-CURRENT as of recent date: 12.0-CURRENT #30 r315698: Wed Mar 22 06:09:40 CET 2017 amd64. Building a "buildworld" for the arm64.aarch64 has been performed successfully via env MAKEOBJDIRPREFIX=/pool/11-STABLE/obj SRCCONF=/dev/null \ __MAKE_CONF=/dev/null TARGET=arm64 make -j12 buildworld After a successful build, there is a object's folder structure /pool/CURRENT/obj/arm64.aarch/ containing (obviosly?) the world without a kernel. Since I use some optimisation flags and special setting in /etc/src.conf and /etc/make.conf, I needed to neutralise those settings and followed the examples and ways I've learned from using NanoBSD. Now, I try to install this world as the base of my arm64.aarch64 jail, which is supposed to build the ports tree for arm64.aarch64 platforms. As a prerequisite, I have already installed the most recent port emulators/qemu-user-static (qemu-user-static-2.8.50.g20170307) and it has been started as a service, as kldstat seems to indicate: kldstat [...] 4 1 0xffffffff81901000 23d0 filemon.ko 5 1 0xffffffff81904000 14fe imgact_binmisc.ko Well, now I try to install the jail: poudriere jail -c -j head-aarch64 -a arm64.aarch64 \ -M /pool/poudriere/jails/head-aarch64 -m src=/pool/CURRENT/src -v head and as a desperate try also with option "-x". But either way, I fail installing the jail with the error shown above. Something is missing and I think, the recommendation of setting the COMPILER_TYPE has a deeper sense here ;-) I tried to google some advices, but I stumbled only over some "simple and easy" advices which lead me to the failure seen above. Maybe nullifying the SRCCONF and __MAKE_CONF isn't a good idea at that point, but I'd like to to await the professionals advice. Thanks in advance, Oliver From owner-freebsd-current@freebsd.org Wed Mar 22 20:02:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FDA0D171AE for ; Wed, 22 Mar 2017 20:02:41 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B88A1D0E for ; Wed, 22 Mar 2017 20:02:39 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.167.156]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MaV3V-1cba1h0dyb-00KAtm for ; Wed, 22 Mar 2017 21:02:32 +0100 Date: Wed, 22 Mar 2017 21:02:25 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min Message-ID: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/PjN9eALox6k1AyvfnXfulQs"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:JHPFitjF08sJpERSDlpDqqXAjKyV0aLE0T/7qj5ZiO+w3zd/GNI NVZBtW1VlrpJhYT5amrctcR2d6tjg73Ly84kAuNMO2gGmWFK/sZJrYY+AG6BM0lRgu8Shym CudxrC87AiEZLD9300e1mPfvenGVu/idtGjJ/pFk2OgUF3r1tX6QdIBdi6NBwxIfOtOlAgK WiF73hTKvHn3ZPo0ClnxA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kKCK4lnrxho=:CZ9ifhoK0a8dEkXorNn59l ymY5nmHiZ0r7M4pW4I51iFKHsrjl4C7COBG8s6y8UPtgCz0qoq/A9Whmlup1yYOxfw6Dx9EjC GKFvhVhTZ4WXiXZVGxxhzo94fGxAqjMiptysmY/OsG7Ia7hup22bbDYKR5A6+mBWWVObVns1R 9SFCTDveQsglaBxgFL8C/EMc1xAhOn+dBgymN+aU66VScqd7TN+3XQNNrhHXK9NvOK6HCABhq bUfv7CV8qdygkKg97m2KnV6fpKjVB12LPl/heKJRmW2WaSD4VJDOoBG8VdfKmG5b8SsncZjhY myGf4CDdZNEUeVSLuCyWZF9SHR0AqhTrFub1hlMbhj4cQNtAVdLpIWEtavyIei6PbpDLn/t0z qu29CUdPbGxc3VlMVlRrmr7F8K18JVV+UeaYZXA3q88MkeosHuJ98ueFY8adt15M+Zx150n7V Yk/UUXkRWL49FyuJ31xgaZfqthttH5ItJQy6fFnzRf5ySNr37MwBuSjvhfaWZg/PnyF4vbH2C 9OBtWo0gb7cRrgSblIiDf6MYW8L6OLQ4wJzc+1lxrMOf8gNig70yPdB2lnILmSdkNctmtg+88 6iTeHL9OiyHX621zQqLBcNjHoWs9x0yxhsdisrJwKkriqJWuH5HwaoxHqRvCuRTPCF2VjLHcS V/IE2d5Kx6LZvdaBJFgbAb0oyNEQUGg0IgjOPFYQPKx95pAdQBDFUVSGdP/WtorYJh+ciAx96 Ww2X3RwiG7sSa4yl3tAQV+6+BtZq+DuWiRsv+H5w7ZxG48TaYWHb5b9N29M= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 20:02:41 -0000 --Sig_/PjN9eALox6k1AyvfnXfulQs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 amd= 64) is annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updatin= g /usr/ports takes >25 min(!). That is an absolute record now. I do an almost daily update of world and ports tree and have periodic scru= bbing ZFS volumes every 35 days, as it is defined in /etc/defaults. Prts tree hasn't = grown much, the content of the ZFS volume hasn't changed much (~ 100 GB, its fill is ab= out 4 TB now) and this is now for ~ 2 years constant.=20 I've experienced before that while scrubbing the ZFS volume, some operation= s, even the update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bit lo= nger than usual - but never that long like now! Another box is quite unusable while it is scrubbing and it has been usable = times before. The change is dramatic ... Regards, Oliver --Sig_/PjN9eALox6k1AyvfnXfulQs Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNLYUgAKCRDS528fyFhY lESCAf9V/jrfWoRLCW7Ob4vn12HafgH2ud2AQSS/EiFiSUW9bzWa1+WPCrAHZCa9 0/aJxf6TFu1xu4CjcgBvEdovskprAf91dw3mneHR0jsbU8M+Rh4mYrzv199qpPNx jIF+688MDmup0hUnqi+1TjpPF7pzS2aa7fMe+TwwYLI6XAUiD+KO =dDBq -----END PGP SIGNATURE----- --Sig_/PjN9eALox6k1AyvfnXfulQs-- From owner-freebsd-current@freebsd.org Wed Mar 22 20:11:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 543E1D174AC for ; Wed, 22 Mar 2017 20:11:01 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id AC75D1487 for ; Wed, 22 Mar 2017 20:10:59 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 30075 invoked by uid 89); 22 Mar 2017 20:10:51 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.129.140) by mail.grem.de with ESMTPA; 22 Mar 2017 20:10:51 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min From: Michael Gmelin X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> Date: Wed, 22 Mar 2017 21:10:51 +0100 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 20:11:01 -0000 > On 22 Mar 2017, at 21:02, O. Hartmann wrote: >=20 > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 am= d64) is > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updati= ng /usr/ports > takes >25 min(!). That is an absolute record now. >=20 > I do an almost daily update of world and ports tree and have periodic scr= ubbing ZFS > volumes every 35 days, as it is defined in /etc/defaults. Prts tree hasn't= grown much, > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill is a= bout 4 TB now) > and this is now for ~ 2 years constant.=20 >=20 > I've experienced before that while scrubbing the ZFS volume, some operatio= ns, even the > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bit l= onger than > usual - but never that long like now! >=20 > Another box is quite unusable while it is scrubbing and it has been usable= times before. > The change is dramatic ... >=20 What do "zpool list", "gstat" and "zpool status" show? From owner-freebsd-current@freebsd.org Wed Mar 22 23:58:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67EF4D188BB for ; Wed, 22 Mar 2017 23:58:39 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 2FF1A1045 for ; Wed, 22 Mar 2017 23:58:38 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 986EC1392F for ; Wed, 22 Mar 2017 23:58:32 +0000 (UTC) Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min To: freebsd-current@freebsd.org References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> From: Allan Jude Message-ID: <4876fd2f-6dd4-16cc-4e27-b52f5cde0fa6@freebsd.org> Date: Wed, 22 Mar 2017 19:58:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8dibRCHGBO52CELPi8eC21xOCut8HwWGo" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 23:58:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8dibRCHGBO52CELPi8eC21xOCut8HwWGo Content-Type: multipart/mixed; boundary="9sEaRw3b9Ntff5hH2K6Js4Eeq038mL33w"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <4876fd2f-6dd4-16cc-4e27-b52f5cde0fa6@freebsd.org> Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> --9sEaRw3b9Ntff5hH2K6Js4Eeq038mL33w Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-03-22 16:02, O. Hartmann wrote: > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017= amd64) is > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, upd= ating /usr/ports > takes >25 min(!). That is an absolute record now. >=20 > I do an almost daily update of world and ports tree and have periodic = scrubbing ZFS > volumes every 35 days, as it is defined in /etc/defaults. Prts tree has= n't grown much, > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill i= s about 4 TB now) > and this is now for ~ 2 years constant.=20 >=20 > I've experienced before that while scrubbing the ZFS volume, some opera= tions, even the > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bi= t longer than > usual - but never that long like now! >=20 > Another box is quite unusable while it is scrubbing and it has been usa= ble times before. > The change is dramatic ... >=20 > Regards, >=20 > Oliver >=20 Due to differences in the kern.hz setting between IllumOS and FreeBSD, the result is FreeBSD doesn't de-prioritize scrub I/O as much as IllumOS does. try: sysctl vfs.zfs.scrub_delay=3D40 This will speed for 40 ticks (40ms on FreeBSD), between each scrub I/O, allowing your ports update to proceed more quickly. 'zpool list' will show how fragmented your pool is, and how full it is, these may also provide insight. If you run 'top -S' while it is performing badly, what is the CPU load li= ke? Is your /usr/ports dataset compressed? --=20 Allan Jude --9sEaRw3b9Ntff5hH2K6Js4Eeq038mL33w-- --8dibRCHGBO52CELPi8eC21xOCut8HwWGo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJY0w+nAAoJEBmVNT4SmAt+ttIQAJGJOZZ55vDRWWPEtiuyen7A OKHd34kcNhZIz1ebPfuxUewJURFKt8nfdbv7BsccJ+fReEIVb1W2mhBqteF/95Sx wjp6Uvf1D0tQMrHNhScdy4LROjj6QhoaqtSBjJURG1N9hg4o/G5M0bBTTJS7B8y8 m8tkQfVHXcE7xubIH8lNy/+ZIg2aImPYEsb4AJh35TIhH/GHNZGdUwMfvlY30eue 9n0asBrAwC3Inawc2S1D6Vl2jRrLBMVHtfksBgFCFFtGaoCnEuQLDwzzf+gsyMq/ 630tr5MIqJEauL3DsswUhGTaAzNGvKkR7tS83HIfhY0fw/92tqD8xTCQB8A3QzQs qRqOqBrsJ6yoUNlhrKiaUpaNehZedxnjDOzq5NUokHxEUF6eWTOfbVdnAJ15pbsj FEvqKdjdlGNXXN26Zx6i/0V5PLlu7wZXmbARNdGECihDAV05cBbTbasduIi4H72d k2SGQuIoBkqNCAVVr+Dj01UhhBuvIjoP9xrQKZ/nHVvuiK/xGlKDrWEmOSBRQ5I3 jc3hJKNxwiq9WGJSyOW5kc7LCjrn17/LUem8V1XX1GaTuQernGgIwPofo5bxCmhX /cppQ4WHpWymKwlsdKjYYx5cDVHwhckioJLY0A1Os1iBk1HEIcXjARdcI1kBt1Hw tfc6hbELeQ+VNxgee7F6 =y73s -----END PGP SIGNATURE----- --8dibRCHGBO52CELPi8eC21xOCut8HwWGo-- From owner-freebsd-current@freebsd.org Thu Mar 23 00:55:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2F92D16C5D for ; Thu, 23 Mar 2017 00:55:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670075.outbound.protection.outlook.com [40.107.67.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57FF01692; Thu, 23 Mar 2017 00:55:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 00:55:09 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.020; Thu, 23 Mar 2017 00:55:09 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIABrxcAgAA8zEOAAQwZgIAAO42ggACmOICAASAVyw== Date: Thu, 23 Mar 2017 00:55:09 +0000 Message-ID: References: <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> <20170321175527.GN43712@kib.kiev.ua> , <20170322072331.GQ43712@kib.kiev.ua> In-Reply-To: <20170322072331.GQ43712@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:DwUosu4ujl4p2XGMU8Q2rg9ZAPzzYEO2kvWfomIkaFfWHV5y6PGvSzolr4AtTScbr4z9zPwZUjUZMM9I0VhmerYr/m+vx/b9QPCAnoBTjIH4t7iR0azvLeWFKiWV6rCgoVlqogR2vaWJjMhF/ROKdubNHaj0dNowBNespKPnNBIwHJQpRczzjKNOU105PqwbqcPYw17yusLo8yKXQ5LuaGspnFZtsvFZt0Lwzj+KG6f+mArbsX7/8q68+BBikhBZnkpufme/+XMJbM1A+oPopsQ/TZKIcMYTwPmgde4CorSPp0ZdMA9I1BAQgSYt5xNsb9qNPEyTEQfqAvE40vKo5Q== x-ms-office365-filtering-correlation-id: 578082cd-8ec8-44be-adea-08d471874161 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39830400002)(24454002)(74482002)(55016002)(7696004)(25786009)(229853002)(2900100001)(3660700001)(77096006)(54906002)(9686003)(3280700002)(6506006)(86362001)(6436002)(6916009)(2950100002)(102836003)(1411001)(189998001)(122556002)(8936002)(81166006)(305945005)(6246003)(2906002)(33656002)(5660300001)(76176999)(39060400002)(54356999)(4326008)(8676002)(50986999)(74316002)(38730400002)(93886004)(110136004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 23 Mar 2017 00:55:09.6185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 00:55:13 -0000 Konstantin Belousov wrote: [stuff snipped] > Below is something to discuss. This is not finished, but it worked for > the simple tests I performed. Clustering should be somewhat handled by > the ncl_write() as is. As an additional advantage, I removed the now > unneeded phys buffer allocation. > > If you agree with the approach on principle, I want to ask what to do > about the commit stuff there (I simply removed that for now). Wow, this is looking good to me. I had thought that the simple way to make ncl_putpages() go through the buffer cache was to replace ncl_writerpc() wi= th VOP_WRITE(). My concern was all the memory<->memory copying that would go on between the pages being written and the buffers allocated by VOP_WRIT= E(). If there is a way to avoid some (if not all) of this memory<->memory copyin= g, then I think it would be a big improvement.. As far as the commit goes, you don't need to do anything if you are calling= VOP_WRITE(). (The code below VOP_WRITE() takes care of all of that.) --> You might want to implement a function like nfs_write(), but with extra= arguments. If you did that, you could indicate when you want the writes to happe= n synchronously vs. async/delayed and that would decide when FILESYNC would be specif= ied. As far as I know, the unpatched nc_putpages() is badly broken for the UNSTA= BLE/commit case. For UNSTABLE writes, the client is supposed to know how to write the = data again if the server crashes/reboots before a Commit RPC is successfully done for = the data. (The ncl_clearcommit() function is the one called when the server indicates= it has rebooted and needs this. It makes no sense whatsoever and breaks the clien= t to call it in ncl_putpages() when mustcommit is set. All mustcommit being set indi= cates is that the write RPC was done UNSTABLE and the above applies to it. Some ser= vers always do FILESYNC, so it isn't ever necessary to do a Commit PRC or redo the wri= te RPCs.) Summary. If you are calling VOP_WRITE() or a similar call above the buffer = cache, then you don't have to worry about any of this. > Things that needs to be done is to add missed handling of the IO flags to > ncl_write(). > + if (error =3D=3D 0 || !nfs_keep_dirty_on_error) > vnode_pager_undirty_pages(pages, rtvals, count - uio.uio_= resid); If the data isn't copied, will this data still be available to the NFS buff= er cache code, so that it can redo the writes for the UNSTABLE case, if the server reboots= before a Commit RPC has succeeded? > - if (must_commit) > - ncl_clearcommit(vp->v_mount); No matter what else we do, this should go away. As above, it breaks the NFS= client and basically forces all dirty buffer cache blocks to be rewritten when it = shouldn't be necessary. rick= From owner-freebsd-current@freebsd.org Thu Mar 23 02:20:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7485D1855F; Thu, 23 Mar 2017 02:20:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660071.outbound.protection.outlook.com [40.107.66.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74151278; Thu, 23 Mar 2017 02:20:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 02:20:48 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.020; Thu, 23 Mar 2017 02:20:47 +0000 From: Rick Macklem To: Larry Rosenman , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Subject: Re: crash: umount_nfs: Current Thread-Topic: crash: umount_nfs: Current Thread-Index: AQHSnf9DKC+Zb1AjDkCvB/ns2F6CGqGYEmLZgAAQyoCACZXXAA== Date: Thu, 23 Mar 2017 02:20:47 +0000 Message-ID: References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:Zi7jZVptDfuLYMU26XgNTdoJ5BOip+DWl8zwpbM+Di9dPLDPQ2cmYQK/OqnB1idBJi542uRwfytxbOWYHolMXl8QyQ2oyWCNKdlmiohzSqr/jkssRWHXvrCBGHgJb3W/v4T1bb4U1RUxEcMy2dnLKfH4GW5B7xdOq9RUzugqm6KgLi98iAZ6FDr7MBxF1uQfUJX2xxxT8gTj3YOMtCMpL35JdjqSQdu1W1ZaIRwrp8nJX/EXcfgEUkpy82DIQ231oPzUb7RuRpijcIMUJcD2Ft614Bj/kuHJcS+Dh7zQvlmrwrVHHQWeKlww8CF4NzZAMvyXacYKAvxnASevyipXrg== x-ms-office365-filtering-correlation-id: 2720904b-12b3-494e-a4dd-08d471933787 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39410400002)(39450400003)(24454002)(2906002)(6246003)(5660300001)(33656002)(81166006)(8936002)(305945005)(74316002)(38730400002)(53936002)(99936001)(76176999)(8676002)(50986999)(4326008)(54356999)(9686003)(3280700002)(558084003)(3660700001)(2900100001)(77096006)(55016002)(7696004)(74482002)(25786009)(229853002)(102836003)(189998001)(2950100002)(122556002)(6506006)(86362001)(2501003)(6436002)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB01890E5CFDB2C827F50B0991DD3F0YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 02:20:47.0649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 02:20:50 -0000 --_002_YTXPR01MB01890E5CFDB2C827F50B0991DD3F0YTXPR01MB0189CANP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Larry Rosenman wrote: > Err, I=92m at r315289=85. I think the attached patch (only very lightly tested by me) will fix this c= rash. If you have an easy way to test it, that would be appreciated, rick --_002_YTXPR01MB01890E5CFDB2C827F50B0991DD3F0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="clntcrash.patch" Content-Description: clntcrash.patch Content-Disposition: attachment; filename="clntcrash.patch"; size=844; creation-date="Thu, 23 Mar 2017 02:20:34 GMT"; modification-date="Thu, 23 Mar 2017 02:20:34 GMT" Content-Transfer-Encoding: base64 LS0tIHJwYy9jbG50X3ZjLmMuc2F2CTIwMTctMDEtMTcgMjI6NTc6NDIuMTM4MTM4MDAwIC0wNTAw CisrKyBycGMvY2xudF92Yy5jCTIwMTctMDMtMjIgMjE6MzA6MTIuOTQwOTI1MDAwIC0wNDAwCkBA IC03OTAsNyArNzkwLDcgQEAgY2xudF92Y19kZXN0cm95KENMSUVOVCAqY2wpCiAJCXN4X3hsb2Nr KCZ4cHJ0LT54cF9sb2NrKTsKIAkJbXR4X2xvY2soJmN0LT5jdF9sb2NrKTsKIAkJeHBydC0+eHBf cDIgPSBOVUxMOwotCQl4cHJ0X3VucmVnaXN0ZXIoeHBydCk7CisJCXN4X3h1bmxvY2soJnhwcnQt PnhwX2xvY2spOwogCX0KIAogCWlmIChjdC0+Y3Rfc29ja2V0KSB7CkBAIC04MDAsMTAgKzgwMCw2 IEBAIGNsbnRfdmNfZGVzdHJveShDTElFTlQgKmNsKQogCX0KIAogCW10eF91bmxvY2soJmN0LT5j dF9sb2NrKTsKLQlpZiAoeHBydCAhPSBOVUxMKSB7Ci0JCXN4X3h1bmxvY2soJnhwcnQtPnhwX2xv Y2spOwotCQlTVkNfUkVMRUFTRSh4cHJ0KTsKLQl9CiAKIAltdHhfZGVzdHJveSgmY3QtPmN0X2xv Y2spOwogCWlmIChzbykgewotLS0gcnBjL2NsbnRfcmMuYy5zYXYJMjAxNy0wMy0yMiAyMTozMDoy My42MTYwODEwMDAgLTA0MDAKKysrIHJwYy9jbG50X3JjLmMJMjAxNy0wMy0yMiAyMTozMTozNi43 MTkzMTMwMDAgLTA0MDAKQEAgLTQ1MCw3ICs0NTAsNiBAQCBjbG50X3JlY29ubmVjdF9jb250cm9s KENMSUVOVCAqY2wsIHVfaW50CiAKIAljYXNlIENMU0VUX0JBQ0tDSEFOTkVMOgogCQl4cHJ0ID0g KFNWQ1hQUlQgKilpbmZvOwotCQlTVkNfQUNRVUlSRSh4cHJ0KTsKIAkJeHBydF9yZWdpc3Rlcih4 cHJ0KTsKIAkJcmMtPnJjX2JhY2tjaGFubmVsID0gaW5mbzsKIAkJYnJlYWs7Cg== --_002_YTXPR01MB01890E5CFDB2C827F50B0991DD3F0YTXPR01MB0189CANP_-- From owner-freebsd-current@freebsd.org Thu Mar 23 02:24:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45CD0D18B10; Thu, 23 Mar 2017 02:24:09 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 243B6C68; Thu, 23 Mar 2017 02:24:09 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MagHtz/1/dXStyIpES//qnzm7uQ41QnNPz3ZFFtcgZg=; b=QX5nJMaLapGtTcRkp1omQNtheQ pdoTrotY+/BpKXra6Xa43XgW/MM2ZrG1x0zJHvXdx87eR3yXYrhrIGYvaSI+ivnTuf7BarkhZvMLB un/p/sO0aVp1k9H9Lb3yKJivwbLsJB5Q9mbY2zHdUiDUuYXZLFQWOYMULR0+b2MT0v18=; Received: from [47.220.164.50] (port=25831 helo=[192.168.200.198]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cqsQ4-00069d-4f; Wed, 22 Mar 2017 21:24:08 -0500 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Wed, 22 Mar 2017 21:24:06 -0500 Subject: Re: crash: umount_nfs: Current From: Larry Rosenman To: Rick Macklem , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Message-ID: Thread-Topic: crash: umount_nfs: Current References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 02:24:09 -0000 It=E2=80=99s VERY intermittent (=20 I.E. not easy to reproduce. Sorry. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 =20 =20 On 3/22/17, 9:20 PM, "Rick Macklem" wrote: Larry Rosenman wrote: =20 > Err, I=E2=80=99m at r315289=E2=80=A6. I think the attached patch (only very lightly tested by me) will fix th= is crash. If you have an easy way to test it, that would be appreciated, rick =20 =20 From owner-freebsd-current@freebsd.org Thu Mar 23 02:53:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11FF5D195FE for ; Thu, 23 Mar 2017 02:53:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 B7F36CDE for ; Thu, 23 Mar 2017 02:53:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22734 invoked from network); 23 Mar 2017 02:53:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Mar 2017 02:53:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 22 Mar 2017 22:53:25 -0400 (EDT) Received: (qmail 6147 invoked from network); 23 Mar 2017 02:53:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Mar 2017 02:53:25 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 639FDEC7B14 for ; Wed, 22 Mar 2017 19:53:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found Message-Id: <185E974A-A52A-4A2D-A5E2-B9EA06A9FB56@dsl-only.net> Date: Wed, 22 Mar 2017 19:53:23 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 02:53:33 -0000 O. Hartmann ohartmann at walstatt.org wrote on Wed Mar 22 14:10:00 UTC 2017: . . . > make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: Unable > to determine compiler type for CC=cc -target aarch64-unknown-freebsd12.0 > --sysroot=/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp > -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. > *** Error code 1 . . . See bugzilla 215561 for a prior report (powerpc64 context). Other poudriere related notes: When I experimented some with poudriere I also submitted: 216084 216083 215561 (referenced above) 215541 I've not tried much since then but will get back to it someday. Comments 10 and 11 of: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216229 might also be relevant. In effect: avoid using CFLAGS+= or CXXFLAGS+= in a SRCCONF/SRC_ENV_CONF file used in poudriere. (The problem is more general than that.) CFLAGS.clang+= and the like should work okay. Or be sure to use a __MAKE_CONF file in poudriere for the likes of CFLAGS+= . (But this last has issues if system vs. port building needs different options.) Other notes tied to arm64 or pine64+ 2GB specifically: Because you happen to be using arm64 you may want to look at bugzilla 217239 and 217138 (which I've since judged as likely to have the same underlying cause). 217138's original context was tied to buildworld -j4 on a pine64+ 2GB (but I've managed to make a small example program or two that shows relevant behavior). With 2GB of RAM buildworld -j4 can force some processes to be swapped-out at times [zero RES(ident memory)]. There can be problems with trashed (zeroed) memory pages when swapped back in if the memory was allocated before the parent process forks. (That is my small example's way of producing the issue.) The parent, child, and more ancestor processes that swapped-out can see zeroed memory in the same general address range(s) as the child does. (Nasty cross-process damage.) There is more to it (it is complicated): See the last half of: https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015934.html for a summary without all the code examples and the like, including avoiding going through my learn-as-I-went issues. (Also submitted to freebsd-hackers asking for information.) I have occasionally types amd64 in my various materials where it should have been arm64. The zeros caused my self-hosted buildworld's to stop (sh asserting) and I had to restart them twice per buildworld on the pine64+ 2GB (presumes certain things were rebuilt). I've seen the memory trashing on an rpi3 as well, with no device in common with the pine64+ 2GB. Another issue is that while I've been able to do builds on the pine64+ 2GB I have found that running 4 "openssl speed" commands at the same time causes an eventual sudden/silent shutdown, probably for insufficient thermal control. This is with 6 heat sinks and a fan. So the pine64+ 2GB may be marginal from that point of view. (Yep: powerd was running.) I've not tried 2 or 3 "openssl speed"s in parallel. Nor have a tried on a rpi3: was was targeting having more RAM. Yet other notes: With some local adjustments I did get as far as having an amd64-host to-armv6/v7 cross-build environment. But I ended up deciding that I'd need to have access to a more substantial amd64 environment than I had used in order to satisfy my time preferences and in order to deal with the resource limitations of the context that I used for the experiments --ones that I did not want to change in that context. I ended up deleting the packages, jail, and all the files involved. I'll get back to such someday. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Mar 23 04:35:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3BF1D19925 for ; Thu, 23 Mar 2017 04:35:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 8548D89C for ; Thu, 23 Mar 2017 04:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14386 invoked from network); 23 Mar 2017 04:35:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 23 Mar 2017 04:35:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 23 Mar 2017 00:35:51 -0400 (EDT) Received: (qmail 11866 invoked from network); 23 Mar 2017 04:35:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Mar 2017 04:35:51 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 80C14EC7B14; Wed, 22 Mar 2017 21:35:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found From: Mark Millard In-Reply-To: <185E974A-A52A-4A2D-A5E2-B9EA06A9FB56@dsl-only.net> Date: Wed, 22 Mar 2017 21:35:49 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <77B361DA-27CA-4F95-B0B1-069993DFD6EB@dsl-only.net> References: <185E974A-A52A-4A2D-A5E2-B9EA06A9FB56@dsl-only.net> To: ohartmann@walstatt.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 04:35:58 -0000 On 2017-Mar-22, at 7:53 PM, Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Wed Mar 22 14:10:00 UTC = 2017: >=20 > . . . >> make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: = Unable >> to determine compiler type for CC=3Dcc -target = aarch64-unknown-freebsd12.0 >> --sysroot=3D/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp >> -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. >> *** Error code 1 >=20 > . . . >=20 >=20 > See bugzilla 215561 for a prior report (powerpc64 context). >=20 >=20 > Other poudriere related notes: >=20 > When I experimented some with poudriere I also submitted: >=20 > 216084 > 216083 > 215561 (referenced above) > 215541 >=20 > I've not tried much since then but will get back to it > someday. >=20 > Comments 10 and 11 of: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216229 >=20 > might also be relevant. In effect: avoid using CFLAGS+=3D > or CXXFLAGS+=3D in a SRCCONF/SRC_ENV_CONF file used in > poudriere. (The problem is more general than that.) > CFLAGS.clang+=3D and the like should work okay. Or be > sure to use a __MAKE_CONF file in poudriere for the > likes of CFLAGS+=3D . (But this last has issues if > system vs. port building needs different options.) >=20 >=20 > Other notes tied to arm64 or pine64+ 2GB specifically: >=20 > Because you happen to be using arm64 you may want to > look at bugzilla 217239 and 217138 (which I've since > judged as likely to have the same underlying cause). > 217138's original context was tied to buildworld -j4 on > a pine64+ 2GB (but I've managed to make a small example > program or two that shows relevant behavior). >=20 > With 2GB of RAM buildworld -j4 can force some processes > to be swapped-out at times [zero RES(ident memory)]. > There can be problems with trashed (zeroed) memory > pages when swapped back in if the memory was allocated > before the parent process forks. (That is my small > example's way of producing the issue.) The parent, child, > and more ancestor processes that swapped-out can see > zeroed memory in the same general address range(s) > as the child does. (Nasty cross-process damage.) >=20 > There is more to it (it is complicated): See the > last half of: >=20 > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015934.html >=20 > for a summary without all the code examples and the > like, including avoiding going through my learn-as-I-went > issues. (Also submitted to freebsd-hackers asking for > information.) I have occasionally types amd64 in my > various materials where it should have been arm64. >=20 > The zeros caused my self-hosted buildworld's to stop > (sh asserting) and I had to restart them twice per > buildworld on the pine64+ 2GB (presumes certain things > were rebuilt). >=20 > I've seen the memory trashing on an rpi3 as well, with > no device in common with the pine64+ 2GB. >=20 > Another issue is that while I've been able to do > builds on the pine64+ 2GB I have found that running > 4 "openssl speed" commands at the same time causes > an eventual sudden/silent shutdown, probably for > insufficient thermal control. This is with 6 heat > sinks and a fan. So the pine64+ 2GB may be marginal > from that point of view. (Yep: powerd was running.) > I've not tried 2 or 3 "openssl speed"s in parallel. > Nor have a tried on a rpi3: was was targeting having > more RAM. >=20 >=20 > Yet other notes: >=20 > With some local adjustments I did get as far as having > an amd64-host to-armv6/v7 cross-build environment. > But I ended up deciding that I'd need to have access to > a more substantial amd64 environment than I had used in > order to satisfy my time preferences and in order to > deal with the resource limitations of the context that > I used for the experiments --ones that I did not want > to change in that context. >=20 > I ended up deleting the packages, jail, and all the > files involved. I'll get back to such someday. Bryan Drewery just added a Comment #19 to Bugzilla 215561: It's most likely the same issue as Bug 212877. There's a patch in there if you want to try it out. See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212877 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Mar 23 05:33:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 626D3D197EA for ; Thu, 23 Mar 2017 05:33:24 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 1F0E319CA; Thu, 23 Mar 2017 05:33:23 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 94-21-205-135.pool.digikabel.hu ([94.21.205.135] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cqvN4-000A2K-LL; Thu, 23 Mar 2017 05:33:14 +0000 Subject: Re: process killed: text file modification To: Rick Macklem , Konstantin Belousov References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> Cc: Dimitry Andric , Ian Lepore , FreeBSD Current From: Gergely Czuczy Message-ID: <92977c2c-1dc7-89d4-059f-0dc41e972beb@harmless.hu> Date: Thu, 23 Mar 2017 06:33:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 05:33:24 -0000 On 2017. 03. 21. 3:40, Rick Macklem wrote: > Gergely Czuczy wrote: > [stuff snipped] >> Actually I want to test it, but you guys are so vehemently discussing >> it, I thought it would be better to do so, once you guys settled your >> analysis on the code. Also, me not having the problem occurring, I don't >> think would mean it's solved, since that would only mean, the codepath >> for my specific usecase works. There might be other things there as >> well, what I don't hit. > I hope by vehemently, you didn't find my comments as nasty. If they did > come out that way, it was not what I intended and I apologize. > >> Let me know which patch should I test, and I will see to it in the next >> couple of days, when I get the time to do it. > I've attached it here again and, yes, I would agree that the results you get > from testing are just another data point and not definitive. > (I'd say this statement is true of all testing of nontrivial code.) > > Thanks in advance for any testing you can do, rick I finally had the time to give it a go, but unfortunately there was something wrong with the built image, it was unable to find the root device during boot. I will try to just copy the kernel over a bit later, and see how it goes. I hope there are no ABI changes between the two revisions (the previously built world, and the patched kernel). > From owner-freebsd-current@freebsd.org Thu Mar 23 06:10:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6693CD1972B for ; Thu, 23 Mar 2017 06:10:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DBC318C1; Thu, 23 Mar 2017 06:10:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2N69uwb081715 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 08:09:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2N69uwb081715 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2N69uTs081714; Thu, 23 Mar 2017 08:09:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 Mar 2017 08:09:55 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170323060955.GX43712@kib.kiev.ua> References: <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> <20170321175527.GN43712@kib.kiev.ua> <20170322072331.GQ43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 06:10:02 -0000 On Thu, Mar 23, 2017 at 12:55:09AM +0000, Rick Macklem wrote: > Wow, this is looking good to me. I had thought that the simple way to make > ncl_putpages() go through the buffer cache was to replace ncl_writerpc() with > VOP_WRITE(). My concern was all the memory<->memory copying that would > go on between the pages being written and the buffers allocated by VOP_WRITE(). > If there is a way to avoid some (if not all) of this memory<->memory copying, then > I think it would be a big improvement.. UIO_NOCOPY means that uio is only updated to indicate the operation as performed, but no real copying occurs. This is exactly what the _putpages() case needs, since the data is already in the pages. When buffers are created for the corresponding file offsets, appropriate pages are put into the buffer's page array and data appears in the buffer with zero copying. This is how generic putpages code works for local filesystems, e.g. UFS. > > As far as the commit goes, you don't need to do anything if you are calling VOP_WRITE(). > (The code below VOP_WRITE() takes care of all of that.) > --> You might want to implement a function like nfs_write(), but with extra arguments. > If you did that, you could indicate when you want the writes to happen synchronously > vs. async/delayed and that would decide when FILESYNC would be specified. > Yes, this is what I want to improve in the patch. As I noted, I added translation of the VM_PAGER_PUT_* flags into IO_* flags, but IO_* flags needs more code. Most important is IO_ASYNC which probably should become similar to the current !IO_SYNC ncl_write(), but without clustering. You mentioned that NFSWRITE_FILESYNC/NFSWRITE_UNSTABLE should be specified, and it seems that this is managed by B_NEEDCOMMIT buffer flag. I see that B_NEEEDCOMMIT is cleared in ncl_write(). > As far as I know, the unpatched nc_putpages() is badly broken for the > UNSTABLE/commit case. For UNSTABLE writes, the client is supposed to > know how to write the data again if the server crashes/reboots before > a Commit RPC is successfully done for the data. (The ncl_clearcommit() > function is the one called when the server indicates it has rebooted > and needs this. It makes no sense whatsoever and breaks the client > to call it in ncl_putpages() when mustcommit is set. All mustcommit > being set indicates is that the write RPC was done UNSTABLE and the > above applies to it. Some servers always do FILESYNC, so it isn't ever > necessary to do a Commit PRC or redo the write RPCs.) > > Summary. If you are calling VOP_WRITE() or a similar call above the > buffer cache, then you don't have to worry about any of this. Ok, thanks. > > > Things that needs to be done is to add missed handling of the IO flags to > > ncl_write(). > > > + if (error == 0 || !nfs_keep_dirty_on_error) > > vnode_pager_undirty_pages(pages, rtvals, count - uio.uio_resid); > If the data isn't copied, will this data still be available to the NFS buffer cache code, > so that it can redo the writes for the UNSTABLE case, if the server reboots before a > Commit RPC has succeeded? As far as buffers are there (e.g. not marked clean), the data is there. Of course, userspace can modify the data in pages if writeable mapping exists, but it is expected. Oh, I remembered one more question I wanted to ask in the previous mail. With the patch, ncl_write() can be called from the delayed contexts like pagedaemon, or after all writeable file descriptors referencing the file are closed. Wouldn't some calls to VOP_OPEN()/VOP_CLOSE() around the VOP_WRITE() needed there ? > > > - if (must_commit) > > - ncl_clearcommit(vp->v_mount); > No matter what else we do, this should go away. As above, it breaks the NFS client > and basically forces all dirty buffer cache blocks to be rewritten when it shouldn't > be necessary. From owner-freebsd-current@freebsd.org Thu Mar 23 06:25:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DF0CD19BBB for ; Thu, 23 Mar 2017 06:25:17 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 D3E5D1145; Thu, 23 Mar 2017 06:25:16 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 94-21-205-135.pool.digikabel.hu ([94.21.205.135] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cqwBN-000AO3-5L; Thu, 23 Mar 2017 06:25:13 +0000 Subject: Re: process killed: text file modification To: Rick Macklem , Konstantin Belousov References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> Cc: Dimitry Andric , Ian Lepore , FreeBSD Current From: Gergely Czuczy Message-ID: <050751d5-8c4d-b257-7c83-3a9bfb38a86d@harmless.hu> Date: Thu, 23 Mar 2017 07:25:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 06:25:17 -0000 On 2017. 03. 21. 3:40, Rick Macklem wrote: > Gergely Czuczy wrote: > [stuff snipped] >> Actually I want to test it, but you guys are so vehemently discussing >> it, I thought it would be better to do so, once you guys settled your >> analysis on the code. Also, me not having the problem occurring, I don't >> think would mean it's solved, since that would only mean, the codepath >> for my specific usecase works. There might be other things there as >> well, what I don't hit. > I hope by vehemently, you didn't find my comments as nasty. If they did > come out that way, it was not what I intended and I apologize. > >> Let me know which patch should I test, and I will see to it in the next >> couple of days, when I get the time to do it. > I've attached it here again and, yes, I would agree that the results you get > from testing are just another data point and not definitive. > (I'd say this statement is true of all testing of nontrivial code.) > > Thanks in advance for any testing you can do, rick > So, I've copied the patched kernel over, and apparently it's working properly. I'm not getting the error anymore. So far I've only did a quick test, should I do something more extensive, like build a couple of ports or something over NFS? From owner-freebsd-current@freebsd.org Wed Mar 22 21:25:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87FF1D1153E for ; Wed, 22 Mar 2017 21:25:40 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E31911AC6 for ; Wed, 22 Mar 2017 21:25:39 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.167.156]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MhiTL-1cUTNj0I8R-00MwSx; Wed, 22 Mar 2017 22:25:36 +0100 Date: Wed, 22 Mar 2017 22:25:24 +0100 From: "O. Hartmann" To: Michael Gmelin Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min Message-ID: <20170322222524.2db39c65@thor.intern.walstatt.dynvpn.de> In-Reply-To: <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:tL656RmJBQelSvl4FP6NhdjpGNU/OcpGtHQNul2fqnEOpR+wC8j mosN+kaidkeEHAkcbzVge5w4ri3T2+SW8D5/3WnHLo5SiWi406JJI59Z3k87Adajobkb98o DI1gMTixb6kaXtNhycpoQfAUmnXoAL4LcnaK3AxYesQjoQLriTrTl+Pthl0IrO8ACU4w4WP JLb9L+1TEqj9eWqqfd/1A== X-UI-Out-Filterresults: notjunk:1;V01:K0:d3lsdyv/gNQ=:FMaAAm+1VbOnm48zmKVs31 41/5sP5FQgFBIqCkFllKp/qoNMTmQln2b6SMyl9AJM3L9mXXyPqCma6ZBtIqOxJxcsvLH0Y5u epmCclP/ngK5szf+Voi1jHyNnDmAJ01FMF5Kx/Z9ir1es7nBbk+Ihnhoz7nz1RC0IlRieHGlj 3jvZCfmdWG47AW6TIcTHE7jm8u1jornH+5BjTNdFrv7Uelcb9tfcqXohpNpnZxt0tugNWhRU6 Fo3ZSzGhme6yDm0iLrgQzrNbXWnA5a5MDE8U49HQB1zsI1fphQb4yz2t0gXc89dd7Z+SkYpIC LWdKk/uOXcakEDY1EAlR/jLEf5RsGyc/FMs/NlB3rOeESQmEzdX/ArkMdCpDZhfEibpMF5yKw Er69XYZ1mEoqjvjJzl33QCIE30nbEPdiLKGieXli+KGqdFRpTJYUJipI6y06lgxZ8iRWd+/ux coAW31CGWk6X/1P5UULZ2dUkRurbBdAYYWXtZA0k7uZjxhWFLE66b1usqvVV6NCqqCFnKA2/M oPr7T9qMaG4DMiZ7wyLyR22di1f4/ga589JMQ+mhwFY/o6elJzAmvZEvyZ0T5xeSeVSko72D8 kvYTcgvQN2trMvI3GKS1OgrV3xKWClul2+c6DIddR9z9N0EZa5Sug5itsH/mt1l4cOITkk/Zp S0Op4CWbZH/EeEN1La5OWBNsLyywlKXPwSHXzuI+b71vNSf+8odvOTNXT0Enbu7CR5BcLCnU3 TFf2Ht8bE7esUS95Z8pAsajYvdvaqDVu+RboRA7Xo1oim7L3LAsq+RP5yqw= X-Mailman-Approved-At: Thu, 23 Mar 2017 10:58:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 22 Mar 2017 21:25:40 -0000 --Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 22 Mar 2017 21:10:51 +0100 Michael Gmelin schrieb: > > On 22 Mar 2017, at 21:02, O. Hartmann wrote: > >=20 > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017= amd64) is > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > updating /usr/ports takes >25 min(!). That is an absolute record now. > >=20 > > I do an almost daily update of world and ports tree and have periodic = scrubbing ZFS > > volumes every 35 days, as it is defined in /etc/defaults. Prts tree has= n't grown much, > > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill i= s about 4 TB > > now) and this is now for ~ 2 years constant.=20 > >=20 > > I've experienced before that while scrubbing the ZFS volume, some opera= tions, even the > > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bi= t longer than > > usual - but never that long like now! > >=20 > > Another box is quite unusable while it is scrubbing and it has been usa= ble times > > before. The change is dramatic ... > > =20 >=20 > What do "zpool list", "gstat" and "zpool status" show? >=20 >=20 >=20 zpool list: NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTRO= OT TANK00 10.9T 5.45T 5.42T - 7% 50% 1.58x ONLINE - Deduplication is off right now, I had one ZFS filesystem with dedup enabled gstat: not shown here, but the drives comprise the volume (4x 3 TB) show 10= 0% busy each, but one drive is always a bit off (by 10% lower) and this drive is walking = through all four drives ada2, ada3, ada4 and ada5. Nothing unusual in that situation. B= ut the throughput is incredible low, for example ada4: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 2 174 174 1307 11.4 0 0 0.0 99.4| ada4 kBps (kilo Bits per second I presume) are peaking at ~ 4800 - 5000. On anot= her bos, this is ~ 20x higher! Most time, kBps r and w stay at ~ 500 -600. zpool status: pool: TANK00 state: ONLINE scan: scrub in progress since Wed Mar 22 19:12:41 2017 167G scanned out of 5.62T at 15.9M/s, 99h46m to go 0 repaired, 2.91% done config: NAME STATE READ WRITE CKSUM TANK00 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/tank00 ONLINE 0 0 0 gpt/tank01 ONLINE 0 0 0 gpt/tank02 ONLINE 0 0 0 gpt/tank03 ONLINE 0 0 0 logs gpt/zil00 ONLINE 0 0 0 cache gpt/l2arc00 ONLINE 0 0 0 errors: No known data errors Here are the incredible low numbers more clear. Usually, the hardware is ca= pable of doing ~ 280 - 300 MBytes/s. It is stuck for hours at 15 - 16 MBytes/s. --Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNLrxAAKCRDS528fyFhY lDgaAf4901djZ+7HsfgS9kDrGcWXKwMO14DRCRFHla8MHLv1eTp7XEkYzTX3W1Yn 5Cc89j2XT+HqAivLkfOTs8KuqD3KAgCde4j6MFK8ypzuZgBZh5ILsuNDEyv/NXcx GTvBUJLU4vlDIRWrytlPdSMxI748DQaLb8xsSurUxTdHDLrGuMg8 =V+Mn -----END PGP SIGNATURE----- --Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3-- From owner-freebsd-current@freebsd.org Thu Mar 23 12:38:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37792D19552 for ; Thu, 23 Mar 2017 12:38:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 ECA4C1B11 for ; Thu, 23 Mar 2017 12:38:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cr20D-000NXU-3q; Thu, 23 Mar 2017 15:38:05 +0300 Date: Thu, 23 Mar 2017 15:38:05 +0300 From: Slawa Olhovchenkov To: "O. Hartmann" Cc: Michael Gmelin , "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min Message-ID: <20170323123805.GH86500@zxy.spb.ru> References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> <20170322222524.2db39c65@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170322222524.2db39c65@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 12:38:09 -0000 On Wed, Mar 22, 2017 at 10:25:24PM +0100, O. Hartmann wrote: > Am Wed, 22 Mar 2017 21:10:51 +0100 > Michael Gmelin schrieb: > > > > On 22 Mar 2017, at 21:02, O. Hartmann wrote: > > > > > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 amd64) is > > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > > updating /usr/ports takes >25 min(!). That is an absolute record now. > > > > > > I do an almost daily update of world and ports tree and have periodic scrubbing ZFS > > > volumes every 35 days, as it is defined in /etc/defaults. Prts tree hasn't grown much, > > > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill is about 4 TB > > > now) and this is now for ~ 2 years constant. > > > > > > I've experienced before that while scrubbing the ZFS volume, some operations, even the > > > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bit longer than > > > usual - but never that long like now! > > > > > > Another box is quite unusable while it is scrubbing and it has been usable times > > > before. The change is dramatic ... > > > > > > > What do "zpool list", "gstat" and "zpool status" show? > > > > > > > zpool list: > > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > TANK00 10.9T 5.45T 5.42T - 7% 50% 1.58x ONLINE - > > Deduplication is off right now, I had one ZFS filesystem with dedup enabled > > gstat: not shown here, but the drives comprise the volume (4x 3 TB) show 100% busy each, > but one drive is always a bit off (by 10% lower) and this drive is walking through all > four drives ada2, ada3, ada4 and ada5. Nothing unusual in that situation. But the > throughput is incredible low, for example ada4: > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 2 174 174 1307 11.4 0 0 0.0 99.4| ada4 > > kBps (kilo Bits per second I presume) are peaking at ~ 4800 - 5000. On another bos, this > is ~ 20x higher! Most time, kBps r and w stay at ~ 500 -600. kilo Bytes. 174 rps is normal for general 7200 RPM disk. Transfer too low by every request is about 1307/174 = ~8 KB. Don't know root cause of this. I am see raid-z of 4 disk, 8*3 = ~24KB per record. May be compession enable and zfs use 128KB record size? For this case this is expected performance. Use 1MB and higher record size. From owner-freebsd-current@freebsd.org Thu Mar 23 15:39:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78AD0D19E6C for ; Thu, 23 Mar 2017 15:39:23 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E09CA1485 for ; Thu, 23 Mar 2017 15:39:22 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.6.237]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYx2x-1ccyDk0Tb9-00VhTS; Thu, 23 Mar 2017 16:39:19 +0100 Date: Thu, 23 Mar 2017 16:39:12 +0100 From: "O. Hartmann" To: Slawa Olhovchenkov Cc: Michael Gmelin , "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min Message-ID: <20170323163702.2b920804@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170323123805.GH86500@zxy.spb.ru> References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> <20170322222524.2db39c65@thor.intern.walstatt.dynvpn.de> <20170323123805.GH86500@zxy.spb.ru> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/f6qZtBew4EzmLIU4EzB0IAI"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:48eWmmrbOo7eatUzuNnZ9dHrJsdNT4wRfHLCZBLiu67dJBzsJES 0m5VRsUNEiYA/RMqz/xaAOIz+0SC0ETXWs5tWgVC/ywwMPZoPyfodRZl9pjEGrUGzz6BHpe 9hp0MFGuzjjGQs9qUqzWB31n0sjrez5z3AQCitmsDlh+396C1Smgq8NByHmJHN7LLE0dwCg R/x4vJdfZOsFnNQ02Plug== X-UI-Out-Filterresults: notjunk:1;V01:K0:IRNMi74NOFc=:RrHtzsf4B2+/5MyWI7B7em /PVr6kVh7ZymFyaGw0ZT9hm96TAi/KG7YTCQzCS9F6sIGPxG+J2+kVjFSAAqunVghCspPbioH ge5zT9ha0AiWtHnXtkXlcDmGn745mKappDYecfHYZScpk8k/eroJ3bJ5JDb5nmapQcqYgTwQV q+2HcIlSaNkv+YIhqCTNGNxqEQhWCxe7TeK2Csjo0QFgB2yb/qlD/nDTeQsVDZFDRbs6CI9Fw iIGXmOMffwLYOXuTkpazrxXaKL+eOoqOEZ4wLbYQSQXFVc3QW2pnPsW4ZovN5BGOPVVbVC+Kb 4iArhNbtXo5ZGY/iTJvFXR/DO/Mj5xy1XHuMkpaiRLxv6QPXH2+AOQtzs2NEcNIBgLFKiVOCr Z5EMqy4O8hRcmYZ13TJrUCNZvqpMXFbI2YWEnkSN9z5uL4IjNgt/L/bT7e34fu64/VBwFOdpt dJtsOAwf3Re1H4Ui7DFoLVxycqqiPat/47whsldOP/3NE++YwegHPmjZdEAiP3ekQPZ4XVQ/6 fE0YLjgp5gAuBvh/Q3+WUNFh/M3GCX7Efz/q7uJx0M7FyA+65Swvx/RqUznI/In5GxdWvdgV9 gjMGLjLwDINvidnqgPdTyLar7rkyv5otWTxv5L0bztZugaxq935z9ra4CCwMljzDTJQBGSNJC qWL5FMazIK3qbLGidjzEG1CGpb/5D7bCrfeUtaAXMVTEIeExcaCXIaomfHNtK3hKRbv6Hf5rp EGqzs3p7Lj3qdAoH/Gw8WeIPcisSU5U07Nm3OZgPhcwltWyAfP1l7WFccEI= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:39:23 -0000 --Sig_/f6qZtBew4EzmLIU4EzB0IAI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Thu, 23 Mar 2017 15:38:05 +0300 Slawa Olhovchenkov schrieb: > On Wed, Mar 22, 2017 at 10:25:24PM +0100, O. Hartmann wrote: >=20 > > Am Wed, 22 Mar 2017 21:10:51 +0100 > > Michael Gmelin schrieb: > > =20 > > > > On 22 Mar 2017, at 21:02, O. Hartmann wrot= e: > > > >=20 > > > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET = 2017 amd64) is > > > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > > > updating /usr/ports takes >25 min(!). That is an absolute record no= w. > > > >=20 > > > > I do an almost daily update of world and ports tree and have perio= dic scrubbing > > > > ZFS volumes every 35 days, as it is defined in /etc/defaults. Prts = tree hasn't > > > > grown much, the content of the ZFS volume hasn't changed much (~ 10= 0 GB, its fill > > > > is about 4 TB now) and this is now for ~ 2 years constant.=20 > > > >=20 > > > > I've experienced before that while scrubbing the ZFS volume, some o= perations, > > > > even the update of /usr/ports which resides on that ZFS RAIDZ volum= e, takes a bit > > > > longer than usual - but never that long like now! > > > >=20 > > > > Another box is quite unusable while it is scrubbing and it has been= usable times > > > > before. The change is dramatic ... > > > > =20 > > >=20 > > > What do "zpool list", "gstat" and "zpool status" show? > > >=20 > > >=20 > > > =20 > > zpool list: > >=20 > > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH A= LTROOT > > TANK00 10.9T 5.45T 5.42T - 7% 50% 1.58x ONLINE - > >=20 > > Deduplication is off right now, I had one ZFS filesystem with dedup ena= bled > >=20 > > gstat: not shown here, but the drives comprise the volume (4x 3 TB) sho= w 100% busy > > each, but one drive is always a bit off (by 10% lower) and this drive i= s walking > > through all four drives ada2, ada3, ada4 and ada5. Nothing unusual in t= hat situation. > > But the throughput is incredible low, for example ada4: > >=20 > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > > 2 174 174 1307 11.4 0 0 0.0 99.4| ada4 > >=20 > > kBps (kilo Bits per second I presume) are peaking at ~ 4800 - 5000. On = another bos, > > this is ~ 20x higher! Most time, kBps r and w stay at ~ 500 -600. =20 >=20 > kilo Bytes. > 174 rps is normal for general 7200 RPM disk. Transfer too low by every > request is about 1307/174 =3D ~8 KB. Don't know root cause of this. I am > see raid-z of 4 disk, 8*3 =3D ~24KB per record. May be compession enable > and zfs use 128KB record size? For this case this is expected > performance. Use 1MB and higher record size. >=20 I've shutdown the box over night and rebooted this morning. After checking = from remote the output of "zpool status", the throughput was at ~229 MBytes/s - a value= I'd expected, peaking again at ~ 300 MBytes/s. I assume my crap home hardware is not prov= iding more, but at this point, everything is as expected. The load, as observed via top= , showed ~75 - 85% idle (top -S). But anyway, on the other home box with ZFS scrubbing act= ive, the drives showed a throughput of ~ 110 MBystes/s and 129 MBytes/s - also value= I'd expected. But the system was really jumpy and the load showed ~ 80% idle (two cores, = 4 threads, 8 GB RAM, the first box mentioned with the larger array has 4 cores/8 threads= and 16 GB). --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/f6qZtBew4EzmLIU4EzB0IAI Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNPsIAAKCRDS528fyFhY lOP6AgCQJEnXjgr6Ki8ofjKCc+xH+AfpazF8DhG47PlplClEcWPAImPiBqefiP7S eYgfU7l6VQt4bvSOiJJUpJjAy6XEAf9Bc1pXhZbL5Apa+8BkFdHWaBRXzyd4QK6z /hoS74tqs6pK3BQYe724pMdk2TjfikxK+5Y2KzV72GjrjrHQfOsu =9btC -----END PGP SIGNATURE----- --Sig_/f6qZtBew4EzmLIU4EzB0IAI-- From owner-freebsd-current@freebsd.org Thu Mar 23 14:38:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D000D1A5A0 for ; Thu, 23 Mar 2017 14:38:49 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11B8E1C95; Thu, 23 Mar 2017 14:38:48 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MSduu-1cjK5j3pmG-00RaTF; Thu, 23 Mar 2017 15:38:40 +0100 Date: Thu, 23 Mar 2017 15:38:33 +0100 From: "O. Hartmann" To: Ian Lepore Cc: "O. Hartmann" , freebsd-current Subject: Re: ntpd dies nightly on a server with jails Message-ID: <20170323153833.75e1b013@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <1489774815.40576.182.camel@freebsd.org> References: <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> <201703152012.v2FKCbvg078762@slippy.cwsent.com> <20170317180507.5c64fb26@thor.intern.walstatt.dynvpn.de> <1489774815.40576.182.camel@freebsd.org> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:WGWa/YxSBZNajLHJ13QgvQXZL9QyTN1YG4gss+tYaxGy7SHiYDf QQ5knTUSgZC8m/qP5nf/bGd6A7CbwcdT/Fuc4Kfn5iO8BPg6caw3XzIIiwdG4ZLOnW9/7y0 8ymIuyHmOSi+cwavo1bHOBCuwPcperz7GYO3Ukba/ta9Cu9e+5V1aadOAE8UuuV5jPk5Emf Io5FQ7vd28rX02E3qg2OQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:CBw1KvvvIEc=:iod+CHlZSXYFn6MuQ3DoKS Ada/gAEeFrYSpTRpTPP5pEfqvYXiBIYncEQIxSa9xxKII6sBC5mNlOqcDv/LxwnwpGVmAbA79 uQRVHB1r/bLU0m08T182kf45W4ecV/8YQJU4YJwO9TCgja8GONLzhOAMlikDoP62QcYjvgWwg zXJ6rgFGLnZ/BBO045XM4JBkFS0qaWYAF82UxnVS+sLSPYMIEIumGdfBCd7UIlFgioCoSIXup tpnQzkMIjQEJmBe1xo+uK22uEDb1kqPjUVn4Zw/0wPOxFEf3mNwBkOQmI67NIiTCxtyIGkiFa 8Lp3u2v0Xqfzrog0C6OIVo+VB5jHYcMoWGG9fL0ozZe1a2VPbiSKqeH0L/s6PQBcjMyivI2+n d3utK8UxzA4yLXU0cZKtuT+YdWR7MYKh9NBeehxWOOjVSnzjmC90d7UqUGqByfcUXd3HMlwuB 73I8aFD0AKic1TBI9twAd70sukCLDOjzMP0AKpg4XV9vNICa5mddoJZMpF64t0WUSu4FxoFbl uPR3ETJAjEy7Ni+bN1hHC7Z7MaPYO6K8Il0BOtU6TKX5r/Afv2lptqoxh+na1Wzq4TBzVyAtU 0RGASfRA/A5gc5ylrlu72NgyY7RsnIntfnXHfwNUX59wPAYHMA2dUPsmOzrG1tNOfm0vgJ6li MD3I/d4vvFQjwPEQ3fcWjm1RiQPeW/ubDnEwlyBHWjB+CRC5CUFiYVRgFbkLv3aDQYJ7UyOdl 2TGZ+uF1WyMoeUE1b8Wiy331lrDLKjf16OP8Dhocz8SRUAwZqPn0y31Fwk5+X4jYeP1XmHEHj O/p+FMK X-Mailman-Approved-At: Thu, 23 Mar 2017 15:43:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:38:49 -0000 On Fri, 17 Mar 2017 12:20:15 -0600 Ian Lepore wrote: > On Fri, 2017-03-17 at 18:05 +0100, O. Hartmann wrote: > > Am Wed, 15 Mar 2017 13:12:37 -0700 > > Cy Schubert schrieb: > > =20 > > >=20 > > > Hi O.Hartmann, > > >=20 > > > I'll try to answer as much as I can in the noon hour I have left. > > >=20 > > > In message <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilie = =20 > > > n.de>,=A0 =20 > > > "O. H > > > artmann" writes: =20 > > > >=20 > > > > Running a host with several jails on recent CURRENT (12.0-CURRENT=20 > > > > #8 r315187: > > > > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily > > > > basis. > > > >=20 > > > > The box is an older two-socket Fujitsu server equipted with two > > > > four-core > > > > Intel(R) Xeon(R) CPU L5420=A0=A0@ 2.50GHz. > > > >=20 > > > > The box has several jails, each jail does NOT run service ntpd. > > > > Each jail has > > > > its dedicated loopback, lo1 throughout lo5 (for the moment) with > > > > dedicated IP > > > > : > > > > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > > > >=20 > > > > The host itself has two main NICs, broadcom based. bcm0 is > > > > dedicated to the > > > > host, bcm1 is shared amongst the jails: each jail has an IP bound > > > > to bcm1 via > > > > whihc the jails communicate with the network. > > > >=20 > > > > I try to capture log informations via syslog, but FreeBSD's ntpd > > > > seems to be > > > > very, very sparse with such informations, coverging to null - I > > > > can't see > > > > anything suiatble in the logs why NTPD dies almost every night > > > > leaving the > > > > system with a wild reset of time. Sometimes it is a gain of 6 > > > > hours, sometime > > > > s > > > > it is only half an hour. I leave the box at 16:00 local time > > > > usually and take > > > > care again at ~ 7 o'clock in the morning local time.=A0=A0 =20 > > > We will need to turn on debugging. Unfortunately debug code is not > > > compiled=A0 > > > into the binary. We have two options. You can either update=A0 > > > src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's > > > the exact=A0 > > > same ntp) with the DEBUG option -- this is probably simpler. Then > > > enable=A0 > > > debug with -d and -D. -D increases verbosity. I just committed a > > > debug=A0 > > > option to both ntp ports to assist here. > > >=20 > > > Next question: Do you see any indication of a core dump? I'd be > > > interested=A0 > > > in looking at it if possible. > > > =20 > > > >=20 > > > >=20 > > > > When the clock is floating that wild, in all cases ntpd isn't > > > > running any mor > > > > e. > > > > I try to restart with options -g and -G to adjust the time > > > > quickly at the > > > > beginning, which works fine.=A0=A0 =20 > > > This is disconcerting. If your clock is floating wildly without > > > ntpd=A0 > > > running there are other issues that might be at play here. At most > > > the=A0 > > > clock might drift a little, maybe a minute or two a day but not by > > > a lot.=A0 > > > Does the drift cause your clocks to run fast or slow? > > > =20 > > > >=20 > > > >=20 > > > > Apart from possible misconfigurations of the jails (I'm quite new > > > > to jails an > > > > d > > > > their pitfalls), I was wondering what causes ntpd to die. i can't > > > > determine > > > > exactly the time of its death, so it might be related to > > > > diurnal/periodic > > > > processes (I use only the most vanilla configurations on > > > > periodic, except for > > > > checking ZFS's scrubbing enabled).=A0=A0 =20 > > > As I'm a little rushed for time, I didn't catch whether the jails=A0 > > > themselves were also running ntpd... just thought I'd ask. I don't > > > see how=A0 > > > zfs scrubbing or any other periodic scripts could cause this. > > > =20 > > > >=20 > > > >=20 > > > > I'ven't had the chance to check whether the hardware is > > > > completely all right, > > > > but from a superficial point of view there is no issue with high > > > > gain of the > > > > internal clock or other hardware issues.=A0=A0 =20 > > > It's probably a good idea to check. I don't think that would cause > > > ntpd any=A0 > > > gas. I've seen RTC battery messages on my gear which haven't caused > > > ntpd=A0 > > > any problem. I have two machines which complain about RTC battery > > > being=A0 > > > dead, where in fact I have replaced the batteries and the messages > > > still=A0 > > > are displayed at boot. I'm not sure if it's possible for a kernel > > > to damage=A0 > > > the RTC. In my case that doesn't cause ntpd any problems. It's > > > probably=A0 > > > good to check anyway. > > > =20 > > > >=20 > > > >=20 > > > > If there are known issues with jails (the problem occurs since I > > > > use those), > > > > advice is appreciated.=A0=A0 =20 > > > Not that I know of. > > >=20 > > > =20 > > Just some strange news: > >=20 > > I left the server the whole day with ntpd disabled and I didn't watch > > a gain of the RTC > > by one second, even stressing the machine. > >=20 > > But soon after restarting ntpd, I realised immediately a 30 minutes > > off! This morning, > > the discrapancy was almost 5 hours - it looked more like a weird > > ajustment to another > > time base than UTC. > >=20 > > Over the weekend I'll leave the server with ntpd disabled and only > > RTC running. I've the > > strange feeling that something is intentionally readjusting the ntpd > > time due to a > > misconfiguration or a rogue ntp server in the X.CC.pool.ntp.org > > =20 >=20 > The rogue server theory is a bad one, unless you have configured just a > single server in your ntp.conf and it is the rogue. =A0Ntpd requires > agreement among the set of configured servers, it will ignore outliers. Past weekend, I had switched off ntpd and ran the server completely with the onboard RTC. On Monday morning when I entered the office, the clock was in synchronisation with the official time. As usual, I update sources and buildworld. After a couple of builds over the week and letting ntpd restart via rc.conf as usual after rebooting, I check= ed over the past two days and i found the server always in a state of dissonant clock. The more curious part is that the clock is almost 6 hours behind UTC. I can= not tell whether the ntpd is still trying to adjust time to a foreign clock whi= ch has another time reference. I checked the TZ and everything seems all right. >=20 > It would help to have some actual data. =A0What does ntpq -p show right > after starting ntpd? =A0Then a few minutes later, then again 10 minutes [RESTART] remote refid st t when poll reach delay offset jit= ter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 0.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 1.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 2.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 3.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 ptbtime1.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.= 000 ptbtime2.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.= 000 [after 1 Minute] remote refid st t when poll reach delay offset jit= ter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 0.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 1.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 2.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 3.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 ptbtime1.ptb.de .PTB. 1 u 34 64 1 16.931 -4.841 0.= 000 ptbtime2.ptb.de .PTB. 1 u 34 64 1 18.273 -5.518 0.= 000 fks.dan.net.uk 117.161.90.132 3 u 31 64 1 24.217 -3.904 0.= 000 213.95.200.109 213.95.151.123 2 u 33 64 1 25.464 -2.449 0.= 000 ns3.customer-re 192.53.103.108 2 u 35 64 1 23.905 -1.187 0.= 000 ns1.blazing.de 213.172.96.14 2 u 36 64 1 17.045 -3.017 0.= 000 ntp2.m-online.n 212.18.1.106 2 u 36 64 1 20.758 -2.693 0.= 000 stratum2-3.NTP. 129.70.130.71 2 u 35 64 1 22.000 -3.800 0.= 000 estoma.de 144.76.96.7 3 u 33 64 1 7.919 -3.182 0.= 000 clint.blazing.d 213.172.96.14 2 u 34 64 1 17.642 -2.932 0.= 000 news01.nierle.c 192.53.103.103 2 u 34 64 1 19.880 -3.750 0.= 000 q.fu110.de 131.234.137.64 2 u 35 64 1 16.649 -6.037 0.= 000 [after ~10 Minutes] remote refid st t when poll reach delay offset jit= ter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 0.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 1.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 2.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 3.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.= 000 #ptbtime1.ptb.de .PTB. 1 u 45 64 177 15.740 0.289 1.= 147 #ptbtime2.ptb.de .PTB. 1 u 38 64 177 17.489 -0.651 1.= 632 #fks.dan.net.uk 117.161.90.132 3 u 46 64 177 21.736 -0.634 9.= 040 -213.95.200.109 213.95.151.123 2 u 41 64 177 23.400 1.216 1.= 353 +ns1.blazing.de 213.172.96.14 2 u 48 64 177 16.848 1.912 0.= 570 *ntp2.m-online.n 212.18.1.106 2 u 48 64 177 20.681 2.409 0.= 927 -stratum2-3.NTP. 129.70.130.71 2 u 44 64 177 20.868 1.482 0.= 719 +clint.blazing.d 213.172.96.14 2 u 42 64 177 16.612 2.374 12.= 795 -news01.nierle.c 192.53.103.103 2 u 40 64 177 20.127 1.504 12.= 851 #q.fu110.de 131.234.137.64 2 u 103 64 176 16.070 -0.769 0.= 663 > after that, etc. =A0What is in the /var/db/ntpd.drift file? =A0Are you > using the standard freebsd ntp.conf file as delivered, or have you > customized it? =A0Any non-default settings in your rc.conf related to > ntp? The line in /etc/rc.conf is: ntpd_flags=3D"-4 -g -G -I 192.168.0.1 -p /var/run/ntpd.pid -f /var/db/ntpd.= drift" The IP at -I is the IP of the primary NIC of the machine, which has two NIC= s. I use a customized /etc/ntp.conf and I did a lot of variations during the approach to figure out the problem. I did the same on host onto the same network, but being of "modern date" (regarding hardware, the server in ques= tion is an 2008 two-socket Core2Duo XEON box with 2x 4 cores) and which does not= host jails. The reference host seems not to show the weird clock gain. the recent /etc/ntp.conf looks this now: tos minclock 3 maxclock 6 server ptbtime1.ptb.de =20 server ptbtime2.ptb.de =20 pool 0.de.pool.ntp.org =20 pool 1.de.pool.ntp.org =20 pool 2.de.pool.ntp.org =20 pool 3.de.pool.ntp.org =20 restrict 192.168.0.0 mask 255.255.255.0 noquery kod nomodify notrap \ nopeer restrict default limited kod nomodify notrap noquery nopeer restrict -6 default limited kod nomodify notrap noquery nopeer restrict source limited kod nomodify notrap noquery restrict 127.0.0.1 restrict 127.127.1.0 restrict -6 ::1 leapfile "/var/db/ntpd.leap-seconds.list" >=20 > -- Ian From owner-freebsd-current@freebsd.org Thu Mar 23 17:37:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF04D1AA15 for ; Thu, 23 Mar 2017 17:37:17 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35540142A for ; Thu, 23 Mar 2017 17:37:16 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.6.237]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lb4vZ-1cTMUU2UPp-00kcW9; Thu, 23 Mar 2017 18:36:59 +0100 Date: Thu, 23 Mar 2017 18:36:45 +0100 From: "O. Hartmann" To: "Chris H" Cc: Subject: Re: Are textmode consoles/terminals still supported? Message-ID: <20170323183645.0bcf46eb@thor.intern.walstatt.dynvpn.de> In-Reply-To: <1b87a24bfc5450f4af5bdbcfcb534e30@ultimatedns.net> References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> <4c0a947f-34b3-2188-269d-8b79286700b2@multiplay.co.uk> <1b87a24bfc5450f4af5bdbcfcb534e30@ultimatedns.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/00xR=zS+4edL5D5eOM.Ys+N"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:16MeTPWTvNGq1FTc75B7w0aUIe00wp1O+sowUlmQKWAXejZeqV6 zr7c+ma3QSS4K708CU56vAqkDit+z7E6P9yi1s3Xgdi4008ZJ/u3U9NiVzrSlbUUoQyl5op Gf5WJQq4F63/TB9rpTVDRfFeywQtrw/rJCjLlRPVGHEDbPbqWvJUntlAmkwQWzUVPKXorw5 yLwLgC4kIb+CjycV7b1+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:MKkcVsF20vQ=:mKKybJjOrG9PFZU55cDujn 4AwK8mknJKcEO6sp4u6P4lZCPfKtsgy5mAZ4qdNnRpc55Dwc9okfVjjNFYfsK4vZc4jogSKZ/ kfUVJ0ugVBT4BJD7TruBOrT9R/HBzgNcCTnRC9TnAu8oNpzZaOBnXcevg7cHlZW+cxCW6SOmi u984YqKDYbNuPvtm5YlJDdd+wuJrHSdQPgX5m4q+33V/OQKCtjkVqHeMV4nq+5E2qzYNvcEVu TH6m0ktUwZBbhuYYaIfrV+v9YuwNZ8/kEGOZNtBEi+TOQ6Gq6PFre11Gs3WvxDjUPRXUmuCVw PCne7zCK2QQWJFEPutnvkEKWnprVqjRv0jDhdVhWhu2GHDBLcrxoE9Xte8zXOjNlbxYc/MPIQ yZneI0LEC0gq+YxwVPcGwEXyQ1govOixwjLfhfAS6DyqCM8dg84RudV3Yq5oOF0C7mYuYRxvZ aKyGwxkGhxAJWlJCnjCCE3xT8kklx5eXM1CCMD9PvQCspTb8uGjIi2Zmn8kMapGM+mbEdsJJY uCVnHOlLXOJsXmcIRqHLNNwiLlOMzuZVR+zWBoOqY6UQ5WafwcwcBgnvOZ0OLJjbs1kUN6sXQ BujSA49JxfZG9FlpYShKWKqWAaM4I1AU858w2l2QxG9p+2ErgbeROGfCZHfu+Q3d3w5qPsjrI HbvPJxpY5K8lNscIS2hw9NwGGqSb3FYNCV5kpTmaXLGPoOuCMPvbJgJ4Gkz6vdIlZmTGt7igr CQX3bqC0/xD0P9eTrwmshsmhfXKNlehf7X/D9tXgGIYIFQtTU28br0Vc5IM= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:37:17 -0000 --Sig_/00xR=zS+4edL5D5eOM.Ys+N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 20 Mar 2017 16:06:43 -0700 "Chris H" schrieb: > On Mon, 20 Mar 2017 22:02:06 +0000 Steven Hartland > wrote >=20 > > Add the following to /boot/loader.conf > >=20 > > Its a tunable but not a sysctl so you can't query it, you just need to= =20 > > set it by adding it to /boot/loader.conf: > > hw.vga.textmode=3D"1" > > =20 > WOW. Thanks for the fast reply! >=20 > I gave your suggestion a try. But it was ignored. :-( > All my other boxes run the nvidia blob, and provide textmode, > and support sc/syscons(4). But I'm not using (u)efi on them. > Maybe that's the trouble? >=20 > Thanks again, Steven! >=20 > --Chris >=20 > > On 20/03/2017 21:58, Chris H wrote: =20 > > > I'm attempting to get a video card that DTRT on FreeBSD. > > > I started with the graphics provided by an AMD A6-7470K, > > > only to discover it's not yet supported. So I forked out > > > for a recent nvidia card, and build/installed a new > > > world/kernel. > > > Everything seemed to be as one would expect, except there > > > was an issue with loader.efi. So I had to move mine aside, > > > and use the one off the install media (tho I understand > > > the (u)efi has since been fixed). Now, I'm attempting to > > > obtain textmode. The text stripped from a tty, and pasted > > > to a new file in a textmode editor -- ee(1) for example; > > > pads the line with spaces to EOL, and prefaces each line > > > following the first line with rubbish (about 1 to 2 > > > characters worth). > > > So "graphics mode" or vt(4) isn't going to get it, for me. > > > Textmode, and syscons(4) has always worked as expected, and > > > I thought I'd try to re-enable it, or get textmode via vt(4). > > > But all attempts fail. > > > excerpt from my KERNCONF > > > > > > device vga > > > options VESA > > > > > > device sc > > > options SC_PIXEL_MODE > > > > > > device vt > > > device vt_vga > > > device vt_efifb > > > > > > However, following the advice on the freebsd wiki, querying > > > the value in sysctl(8) returns: > > > # sysctl hw.vga.textmode > > > sysctl: unknown oid 'hw.vga.textmode' > > > > > > OK how bout vidcontrol(1) > > > # vidcontrol -i adapter > > > vidcontrol: obtaining adapter information: Inappropriate ioctl for de= vice > > > > > > So, it appears from my standpoint that textmode is no longer > > > supported? > > > > > > FWIW: > > > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > > r314700: Sun Mar 5 09:01:30 PST 2017 > > > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 > > > > > > Thank you for anything that might help me obtain textmode again. > > > > > > --Chris > > > > > > > > > _______________________________________________ > > > 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" =20 > >=20 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I use non-UEFI booting machines with vt()-only and the nVidia BLOB (regular= one from ports and even the latest 378.13). The console is not working anymore and p= rovides garbage as long as vt() is in charge. On UEFI only systems, vt() is require= d, sc/syscons doesn't work anymore (I don't care, I'd like to move on). So, with nVidia, = you are lost. The problem with vt() and nVidia is well known and it is well known more th= an a year by now if I recall correctly. Nothing has been done by nVidia so far and as fa= r as I know, the maintainer hasn't solved the problem. I do not know whether nVidia is w= illing to solve the issue. I left an question in their forum, but it seems FreeBSD is= more handled like a "unpleasant necessity". On the other hand, GPU and such rela= ted stuff (GPGPU for instance) is a wasteland in FreeBSD and it seems their world is = still made up from blocky ASCII terminals. Not that I dislike serial terminals, they save= your ass sometimes and for server management, one doesn't really need the additional, non-fault-free complexity graphical UI introduce, but with the capabilities= of handling graphics the proper way much more is usually related to. nVidia is, at the moment, the only GPU provider which supports FreeBSD. If = you'd like to have a workstation with high performance graphical capabilities on FreeBSD,= there is no way around nVidia. With most recent modern hardware, UEFI is standard and t= here the console is gone as long the nVidia kernel module is loaded - you have no ch= ance to get to the console anymore, except you're capable of unloading (remotely?) the = kernel module. As a matter of fact, the system is broken!=20 Regards, Oliver=20 --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/00xR=zS+4edL5D5eOM.Ys+N Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNQHrQAKCRDS528fyFhY lMw7AgCpWDocvU77tswFrRwiijzU9Gew7sVZ2FmOHv3kzyjLICi/GWhqsil3fZ37 so2NMHVQDfrZgeB3jASALVPjaYaxAf4/X5e0kk2trwnNTsnK2suVezlxH9Lu7LgI JP2wxPLZ0spUjuo/cgw5wnsoiYu/iD+EYEm/WntpAiomAhVyCf6j =Ra54 -----END PGP SIGNATURE----- --Sig_/00xR=zS+4edL5D5eOM.Ys+N-- From owner-freebsd-current@freebsd.org Thu Mar 23 18:21:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6EBBD1ABB7; Thu, 23 Mar 2017 18:21:28 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B52191285; Thu, 23 Mar 2017 18:21:28 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8GHeh4tI08mIRaAmN2TzBc1dM5CcKtUms2phclVFT7s=; b=Atp2AqDznXpKRx4G0EI3dH3DMV O/rj0PugibucVHawUyCC/+SmiG3/42Avxe0DV0i/JBf8ydAGTlW+7afSUDdH+vm2wIZMQx06ccgPi Wy5qDya179blD7jUo6M+JwMw54xfJrwMine7wiIdqwZE/om0sU7fuT6Zh1zEXuPZLa8I=; Received: from [74.203.163.58] (port=25718 helo=[10.106.10.51]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cr7MV-0008hC-H4; Thu, 23 Mar 2017 13:21:27 -0500 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 23 Mar 2017 13:20:57 -0500 Subject: Re: crash: umount_nfs: Current From: Larry Rosenman To: Rick Macklem , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Message-ID: Thread-Topic: crash: umount_nfs: Current References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:21:29 -0000 Ok, I think I have a repro scenario. I just repro=E2=80=99d it without this patc= h.=20 I=E2=80=99ll apply it and try again. It takes about 2 days to get enough INACT data that the umount_nfs crashes. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 =20 =20 On 3/22/17, 9:20 PM, "Rick Macklem" wrote: Larry Rosenman wrote: =20 > Err, I=E2=80=99m at r315289=E2=80=A6. I think the attached patch (only very lightly tested by me) will fix th= is crash. If you have an easy way to test it, that would be appreciated, rick =20 =20 From owner-freebsd-current@freebsd.org Thu Mar 23 18:43:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BAFDD1A29B; Thu, 23 Mar 2017 18:43:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19C4D1FE7; Thu, 23 Mar 2017 18:43:14 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GF1B4nuwOpRkI+cJuK7J8upkII1w2qXOhiMhSdv9P34=; b=bk+i8lonlZfb2aT33rgwcn3L7I ZHR4Wf4wczpJDsXs9WyckvGGOZ7LQ2H+v43EIXi17XzQ/0HamJ2oJVr80y2Gq8Ms2nKXGQ5X+E7PD 7BGPrqjHMJWA78VhKh2qz86pU48zZzhXMQNWcz5M6aTj1ZV2qiJ975OBHHU+OsXPxbvo=; Received: from [74.203.163.58] (port=17281 helo=[10.106.10.51]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cr7hZ-0009Jv-EA; Thu, 23 Mar 2017 13:43:13 -0500 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 23 Mar 2017 13:42:43 -0500 Subject: Re: crash: umount_nfs: Current From: Larry Rosenman To: Rick Macklem , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Message-ID: Thread-Topic: crash: umount_nfs: Current References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:43:14 -0000 Patch applied and running =E2=80=93 I=E2=80=99ll try the repro here in a day or 2. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 =20 =20 On 3/23/17, 1:20 PM, "Larry Rosenman" wrote: Ok, I think I have a repro scenario. I just repro=E2=80=99d it without this = patch.=20 =20 I=E2=80=99ll apply it and try again. =20 It takes about 2 days to get enough INACT data that the umount_nfs cras= hes. =20 =20 =20 --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 =20 =20 =20 On 3/22/17, 9:20 PM, "Rick Macklem" wrote: =20 Larry Rosenman wrote: =20 > Err, I=E2=80=99m at r315289=E2=80=A6. I think the attached patch (only very lightly tested by me) will fi= x this crash. If you have an easy way to test it, that would be appreciated, rick =20 =20 =20 From owner-freebsd-current@freebsd.org Thu Mar 23 19:16:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80C62CBA691 for ; Thu, 23 Mar 2017 19:16:23 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AA4A103A for ; Thu, 23 Mar 2017 19:16:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2NJGXNs004207; Thu, 23 Mar 2017 12:16:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "O. Hartmann" Cc: In-Reply-To: <20170323183645.0bcf46eb@thor.intern.walstatt.dynvpn.de> References: <05ff1f84a0f3856823fda4b08266f211@ultimatedns.net> <4c0a947f-34b3-2188-269d-8b79286700b2@multiplay.co.uk> <1b87a24bfc5450f4af5bdbcfcb534e30@ultimatedns.net>, <20170323183645.0bcf46eb@thor.intern.walstatt.dynvpn.de> From: "Chris H" Subject: Re: Are textmode consoles/terminals still supported? Date: Thu, 23 Mar 2017 12:16:39 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <19cf97d5df50ef03d98a21c226a0ba06@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:16:23 -0000 On Thu, 23 Mar 2017 18:36:45 +0100 "O. Hartmann" wrote > Am Mon, 20 Mar 2017 16:06:43 -0700 > "Chris H" schrieb: > > > On Mon, 20 Mar 2017 22:02:06 +0000 Steven Hartland > > wrote > > > > > Add the following to /boot/loader.conf > > > > > > Its a tunable but not a sysctl so you can't query it, you just need to > > > set it by adding it to /boot/loader.conf: > > > hw.vga.textmode="1" > > > > > WOW. Thanks for the fast reply! > > > > I gave your suggestion a try. But it was ignored. :-( > > All my other boxes run the nvidia blob, and provide textmode, > > and support sc/syscons(4). But I'm not using (u)efi on them. > > Maybe that's the trouble? > > > > Thanks again, Steven! > > > > --Chris > > > > > On 20/03/2017 21:58, Chris H wrote: > > > > I'm attempting to get a video card that DTRT on FreeBSD. > > > > I started with the graphics provided by an AMD A6-7470K, > > > > only to discover it's not yet supported. So I forked out > > > > for a recent nvidia card, and build/installed a new > > > > world/kernel. > > > > Everything seemed to be as one would expect, except there > > > > was an issue with loader.efi. So I had to move mine aside, > > > > and use the one off the install media (tho I understand > > > > the (u)efi has since been fixed). Now, I'm attempting to > > > > obtain textmode. The text stripped from a tty, and pasted > > > > to a new file in a textmode editor -- ee(1) for example; > > > > pads the line with spaces to EOL, and prefaces each line > > > > following the first line with rubbish (about 1 to 2 > > > > characters worth). > > > > So "graphics mode" or vt(4) isn't going to get it, for me. > > > > Textmode, and syscons(4) has always worked as expected, and > > > > I thought I'd try to re-enable it, or get textmode via vt(4). > > > > But all attempts fail. > > > > excerpt from my KERNCONF > > > > > > > > device vga > > > > options VESA > > > > > > > > device sc > > > > options SC_PIXEL_MODE > > > > > > > > device vt > > > > device vt_vga > > > > device vt_efifb > > > > > > > > However, following the advice on the freebsd wiki, querying > > > > the value in sysctl(8) returns: > > > > # sysctl hw.vga.textmode > > > > sysctl: unknown oid 'hw.vga.textmode' > > > > > > > > OK how bout vidcontrol(1) > > > > # vidcontrol -i adapter > > > > vidcontrol: obtaining adapter information: Inappropriate ioctl for > > > device > > > > > So, it appears from my standpoint that textmode is no longer > > > > supported? > > > > > > > > FWIW: > > > > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > > > r314700: Sun Mar 5 09:01:30 PST 2017 > > > > root@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6 > > > > > > > > Thank you for anything that might help me obtain textmode again. > > > > > > > > --Chris > > > > > > > > > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I use non-UEFI booting machines with vt()-only and the nVidia BLOB (regular > one from ports and even the latest 378.13). The console is not working > anymore and provides garbage as long as vt() is in charge. On UEFI only > systems, vt() is required, sc/syscons doesn't work anymore (I don't care, I'd > like to move on). So, with nVidia, you are lost. > > The problem with vt() and nVidia is well known and it is well known more than > a year by now if I recall correctly. Nothing has been done by nVidia so far > and as far as I know, the maintainer hasn't solved the problem. I do not know > whether nVidia is willing to solve the issue. I left an question in their > forum, but it seems FreeBSD is more handled like a "unpleasant necessity". On > the other hand, GPU and such related stuff (GPGPU for instance) is a > wasteland in FreeBSD and it seems their world is still made up from blocky > ASCII terminals. Not that I dislike serial terminals, they save your ass > sometimes and for server management, one doesn't really need the additional, > non-fault-free complexity graphical UI introduce, but with the capabilities > of handling graphics the proper way much more is usually related to. > > nVidia is, at the moment, the only GPU provider which supports FreeBSD. If > you'd like to have a workstation with high performance graphical capabilities > on FreeBSD, there is no way around nVidia. With most recent modern hardware, > UEFI is standard and there the console is gone as long the nVidia kernel > module is loaded - you have no chance to get to the console anymore, except > you're capable of unloading (remotely?) the kernel module. As a matter of > fact, the system is broken! > > Regards, > > Oliver A *huge* thanks, Oliver, for taking the time to describe the situation so well -- even if I don't like the answer. ;-) OK that pretty much explains what I'm experiencing. Looks like the only I can get a decent text-based console/terminal; will be to write syscons(4) back into FreeBSD, myself. I thought things were intended to get better, as time goes on. But IMHO it seems like things are simply being removed, which only makes things worse. I know "whiney/trollish" but damnit, I'm frustrated, and judging by the mailing lists, and bugzuilla; others are too. Thanks again, Oliver. I greatly appreciate your taking the time you did! --Chris > > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Ãœbermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). From owner-freebsd-current@freebsd.org Thu Mar 23 21:39:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43671D19D5B for ; Thu, 23 Mar 2017 21:39:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660067.outbound.protection.outlook.com [40.107.66.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFAC31FF0; Thu, 23 Mar 2017 21:39:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 21:39:00 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 21:39:00 +0000 From: Rick Macklem To: Gergely Czuczy , Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "FreeBSD Current" Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIAAClcAgAHrwICAA2WzgIAA/q43 Date: Thu, 23 Mar 2017 21:39:00 +0000 Message-ID: References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> , <050751d5-8c4d-b257-7c83-3a9bfb38a86d@harmless.hu> In-Reply-To: <050751d5-8c4d-b257-7c83-3a9bfb38a86d@harmless.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: harmless.hu; dkim=none (message not signed) header.d=none;harmless.hu; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:lVsV3dhuUWujgTgfHVCSpVt6XQrqdhNxX5VNQwTPiBIpPfTI6sznplBlOQe4959+8iH653JEHlVWlMkBmKLfUFxdgzxWkKUIv5yJDv2OexAaig1zNIdh7tr2EQYyWWMbQP/ukI2JfaO51e2NbqhZ2i7ujqtDHYZ/PrRIpVnEfPGfCX3luVcfm99ih6U4Rf68G2iMMGVRU0glVhQXAimjhDSewdqyZB5OdYasUjeg5s/cJa59i0Cj2S5x0fKht9u2pLqleab0zhEuQE99tACk/VoC+zPl/V8kML2hgpkMzHqOeusd8gG/H3b3gcgqcgAcLvfwPXgbrpwoH/6Od3xx6g== x-ms-office365-filtering-correlation-id: a9b361d4-6c73-4d69-cdbd-08d47235048c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39830400002)(24454002)(377454003)(55674003)(51874003)(93886004)(77096006)(2900100001)(102836003)(9686003)(55016002)(6436002)(6506006)(54906002)(53936002)(54356999)(6246003)(33656002)(39060400002)(5660300001)(76176999)(50986999)(122556002)(4326008)(38730400002)(81166006)(74482002)(2950100002)(8936002)(5890100001)(7696004)(189998001)(8676002)(97736004)(74316002)(305945005)(25786009)(53546009)(229853002)(2906002)(3660700001)(86362001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 21:39:00.0481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 21:39:03 -0000 Try whatever you like. However, if the case that failed before doesn't fail= now, I'd call the test a success. Thanks, rick ps: It looks like Kostik is going to work on converting the NFS vop_putpage= s() to using the buffer cache. However, if this isn't ready for head/current= by mid-April, I will commit this patch to help fix things in the meantime. ________________________________________ From: Gergely Czuczy Sent: Thursday, March 23, 2017 2:25:11 AM To: Rick Macklem; Konstantin Belousov Cc: Dimitry Andric; Ian Lepore; FreeBSD Current Subject: Re: process killed: text file modification On 2017. 03. 21. 3:40, Rick Macklem wrote: > Gergely Czuczy wrote: > [stuff snipped] >> Actually I want to test it, but you guys are so vehemently discussing >> it, I thought it would be better to do so, once you guys settled your >> analysis on the code. Also, me not having the problem occurring, I don't >> think would mean it's solved, since that would only mean, the codepath >> for my specific usecase works. There might be other things there as >> well, what I don't hit. > I hope by vehemently, you didn't find my comments as nasty. If they did > come out that way, it was not what I intended and I apologize. > >> Let me know which patch should I test, and I will see to it in the next >> couple of days, when I get the time to do it. > I've attached it here again and, yes, I would agree that the results you = get > from testing are just another data point and not definitive. > (I'd say this statement is true of all testing of nontrivial code.) > > Thanks in advance for any testing you can do, rick > So, I've copied the patched kernel over, and apparently it's working properly. I'm not getting the error anymore. So far I've only did a quick test, should I do something more extensive, like build a couple of ports or something over NFS? From owner-freebsd-current@freebsd.org Fri Mar 24 07:01:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4D7DD1BA5C for ; Fri, 24 Mar 2017 07:01:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C2061D9B; Fri, 24 Mar 2017 07:01:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2O71fEs011497 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Mar 2017 09:01:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2O71fEs011497 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2O71f8k011496; Fri, 24 Mar 2017 09:01:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Mar 2017 09:01:41 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Gergely Czuczy , Dimitry Andric , Ian Lepore , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170324070141.GB43712@kib.kiev.ua> References: <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> <050751d5-8c4d-b257-7c83-3a9bfb38a86d@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 07:01:51 -0000 On Thu, Mar 23, 2017 at 09:39:00PM +0000, Rick Macklem wrote: > Try whatever you like. However, if the case that failed before doesn't fail now, > I'd call the test a success. > > Thanks, rick > ps: It looks like Kostik is going to work on converting the NFS vop_putpages() to > using the buffer cache. However, if this isn't ready for head/current by mid-April, > I will commit this patch to help fix things in the meantime. I do not see a reason to wait for my work before committing your patch. IMO, instead, it should be committed ASAP and merged into stable/11 for upcoming 11.1. I will do required adjustments if/when _putpages() patch progresses enough. From owner-freebsd-current@freebsd.org Fri Mar 24 08:20:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DBA6D1B0D2 for ; Fri, 24 Mar 2017 08:20:34 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12BD41DD2 for ; Fri, 24 Mar 2017 08:20:34 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id z15so2756812lfd.1 for ; Fri, 24 Mar 2017 01:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=vT55jfCkUbQR5Kwd2nqtMTbmez2k4RfWrR0RebYDtJY=; b=MqPW1+Vzl5HJ4HqeQSWZ/bHGlOBD5TH/M+eBxzs4dwazQbAzTHAvIY+jgSE97o84FA 89+x6pRmjaI3vOp64l63jkWHXUPJdkaCIWSf4VZ3rZp8+JTGAhdu7J9M5jNZUiAUZA8o BX+E7VuRMpiPmwqEzu90MxHFXtXitatrHbgt/RkRfJoxI83cqrnVyrBpqO3bJz2WWaOX SpKDK+nMriBrKPdRQQXw9vp/q8Et0JZi+v+m+UzcxSst4WW/Nv6GGLvmy7ga7o40wy+9 SpKgqCf/ETrudUJ9CKFgvHmAMpudW8N3EvKvvUI1EYr52iL/0keW4MnaJsLmenaIM8SG e3bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=vT55jfCkUbQR5Kwd2nqtMTbmez2k4RfWrR0RebYDtJY=; b=uO1MzucijQ/c5NN5DBEuW4swSlGvA01kVA6ArztcaxReWX2OCPiS6Msedm7UNA0gr0 g8GQYtKBu1yI8OLvHwx5rD1pvIKurMbnuKdFYLweCS76QKqA1LUkOUA5nz6yKi6e7Sys sCAuxLVlFnzAfPYtw8iWWCo49iYZC559WNJ790gSfmLyeCKW28FVBMlCg/5pvpaBf92b gibA9eigZbzBc0BUcQPNNyR7pHiYR9tvoD08ynIsm/mGWfSD0PYo/UKIT/VLtX87ucyI sz+eLl1JruTWOOmRQN5yXR5UgUiebohhRe1DkOUix9jPtjtdsJKcAFauokzbYdvxZ2hk 7Kig== X-Gm-Message-State: AFeK/H0s0kCAw8KB24i1CVgfLF6fnHJ+RB3zXeoMH9WTWdpJE6YUZgFHmadl9sbfWGh/kg== X-Received: by 10.25.44.16 with SMTP id s16mr3629721lfs.6.1490343632254; Fri, 24 Mar 2017 01:20:32 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id c28sm242611lfh.49.2017.03.24.01.20.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 01:20:31 -0700 (PDT) Date: Fri, 24 Mar 2017 11:20:31 +0300 From: Vladimir Zakharov To: freebsd-current@freebsd.org Subject: dchlient does not autostart anymore? Message-ID: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 08:20:34 -0000 Hello! After upgrading from r315544 to r315880 network interface doesn't get IP address using DHCP on boot anymore. $ grep re0 /etc/rc.conf | grep -v "^#" ifconfig_re0="DHCP" "service netif restart" doesn't help either. Only manual dhclient starting. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri Mar 24 08:56:48 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A680D1BC06 for ; Fri, 24 Mar 2017 08:56:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 9722812FC for ; Fri, 24 Mar 2017 08:56:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21490 invoked from network); 24 Mar 2017 08:56:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2017 08:56:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 24 Mar 2017 04:56:40 -0400 (EDT) Received: (qmail 6388 invoked from network); 24 Mar 2017 08:56:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Mar 2017 08:56:40 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AABAFEC8173; Fri, 24 Mar 2017 01:56:39 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: dchlient does not autostart anymore? Message-Id: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> Date: Fri, 24 Mar 2017 01:56:38 -0700 To: zakharov.vv@gmail.com, FreeBSD Current X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 08:56:48 -0000 Vladimir Zakharov zakharov.vv at gmail.com wrote on Fri Mar 24 08:20:34 = UTC 2017: > After upgrading from r315544 to r315880 network interface doesn't get = IP > address using DHCP on boot anymore. >=20 > $ grep re0 /etc/rc.conf | grep -v "^#" > ifconfig_re0=3D"DHCP" >=20 > "service netif restart" doesn't help either. Only manual dhclient > starting. I have just updated two contexts to -r315870 just a bit ago and they both got that behavior as well: A) An amd64 context (FreeBSD client in VirtualBox under macOS) B) An arm64 context (pine64+ 2GB with -mcpu=3Dcortex-a53 ) Later I'll be updating powerpc64, powerpc, and armv6 (with -mcpu=3Dcortex-a7 ) contexts but I'd expect they will all match the behavior. (I started from earlier than -r315544 so your report provides a better lower bound -r315544. I ended earlier and so my report provides a better upper bound -r315870.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Mar 24 09:29:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BF8DCA1974 for ; Fri, 24 Mar 2017 09:29:21 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from mail.mands.hu (mail2.mands.hu [93.189.114.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D330A1617 for ; Fri, 24 Mar 2017 09:29:20 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from MSEXCH13.mands.hu (192.168.4.5) by exchange.mands.hu (192.168.4.6) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 24 Mar 2017 10:28:06 +0100 Received: from MSEXCH13.mands.hu (192.168.4.5) by MSEXCH13.mands.hu (192.168.4.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 10:28:05 +0100 Received: from MSEXCH13.mands.hu ([::1]) by MSEXCH13.mands.hu ([::1]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 10:28:05 +0100 From: =?iso-8859-1?Q?M=26S_-_Krasznai_Andr=E1s?= To: Mark Millard , "zakharov.vv@gmail.com" , FreeBSD Current Subject: RE: dchlient does not autostart anymore? Thread-Topic: dchlient does not autostart anymore? Thread-Index: AQHSpHyMfdFRKCGt/E+6p4gjboBhtKGjtvpA Date: Fri, 24 Mar 2017 09:28:05 +0000 Message-ID: References: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> In-Reply-To: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> Accept-Language: en-US, hu-HU Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.4.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 09:29:21 -0000 Hi, FreeBSD-current, r315895 also experiences the same problem. The problem sta= rted after updating my laptop yesterday morning. I can get an IP address af= ter manually starting dhclient. I have an additional anomaly: the USB mouse does not work (touchpad works) = on a Lenovo T510 laptop. dmesg shows the correct vendor and type for the mo= use. rgds Andr=E1s Krasznai -----Eredeti =FCzenet----- Felad=F3: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@f= reebsd.org] Meghatalmaz=F3 Mark Millard K=FCldve: 2017. m=E1rcius 24. 9:57 C=EDmzett: zakharov.vv@gmail.com; FreeBSD Current T=E1rgy: Re: dchlient does not autostart anymore? Vladimir Zakharov zakharov.vv at gmail.com wrote on Fri Mar 24 08:20:34 UT= C 2017: > After upgrading from r315544 to r315880 network interface doesn't get=20 > IP address using DHCP on boot anymore. >=20 > $ grep re0 /etc/rc.conf | grep -v "^#" > ifconfig_re0=3D"DHCP" >=20 > "service netif restart" doesn't help either. Only manual dhclient=20 > starting. I have just updated two contexts to -r315870 just a bit ago and they both g= ot that behavior as well: A) An amd64 context (FreeBSD client in VirtualBox under macOS) B) An arm64 context (pine64+ 2GB with -mcpu=3Dcortex-a53 ) Later I'll be updating powerpc64, powerpc, and armv6 (with -mcpu=3Dcortex-a7 ) contexts but I'd expect they will all match the behavio= r. (I started from earlier than -r315544 so your report provides a better lowe= r bound -r315544. I ended earlier and so my report provides a better upper = bound -r315870.) =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/= listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Mar 24 10:39:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53E06CA2D6C for ; Fri, 24 Mar 2017 10:39:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCBF1E49 for ; Fri, 24 Mar 2017 10:39:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 54227596; Fri, 24 Mar 2017 13:38:56 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: dchlient does not autostart anymore? References: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> To: =?UTF-8?Q?M&S_-_Krasznai_Andr=c3=a1s?= , Mark Millard , "zakharov.vv@gmail.com" , FreeBSD Current From: Lev Serebryakov Organization: FreeBSD Message-ID: Date: Fri, 24 Mar 2017 13:38:56 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 10:39:05 -0000 On 24.03.2017 12:28, M&S - Krasznai András wrote: devd problems? Now dhclient and moused are started by devd. > Hi, > > FreeBSD-current, r315895 also experiences the same problem. The problem started after updating my laptop yesterday morning. I can get an IP address after manually starting dhclient. > > I have an additional anomaly: the USB mouse does not work (touchpad works) on a Lenovo T510 laptop. dmesg shows the correct vendor and type for the mouse. > > rgds > > András Krasznai > > > > -----Eredeti üzenet----- > Feladó: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] Meghatalmazó Mark Millard > Küldve: 2017. március 24. 9:57 > Címzett: zakharov.vv@gmail.com; FreeBSD Current > Tárgy: Re: dchlient does not autostart anymore? > > Vladimir Zakharov zakharov.vv at gmail.com wrote on Fri Mar 24 08:20:34 UTC 2017: > >> After upgrading from r315544 to r315880 network interface doesn't get >> IP address using DHCP on boot anymore. >> >> $ grep re0 /etc/rc.conf | grep -v "^#" >> ifconfig_re0="DHCP" >> >> "service netif restart" doesn't help either. Only manual dhclient >> starting. > > I have just updated two contexts to -r315870 just a bit ago and they both got that behavior as well: > > A) An amd64 context (FreeBSD client in VirtualBox under macOS) > B) An arm64 context (pine64+ 2GB with -mcpu=cortex-a53 ) > > Later I'll be updating powerpc64, powerpc, and armv6 (with > -mcpu=cortex-a7 ) contexts but I'd expect they will all match the behavior. > > (I started from earlier than -r315544 so your report provides a better lower bound -r315544. I ended earlier and so my report provides a better upper bound -r315870.) > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Fri Mar 24 11:06:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE153D199F1 for ; Fri, 24 Mar 2017 11:06:00 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F29911CF; Fri, 24 Mar 2017 11:06:00 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by freefall.freebsd.org (Postfix) with ESMTP id 653A15395; Fri, 24 Mar 2017 11:05:59 +0000 (UTC) (envelope-from rm@FreeBSD.org) To: FreeBSD Current Cc: =?UTF-8?Q?M&S_-_Krasznai_Andr=c3=a1s?= From: Ruslan Makhmatkhanov Subject: Re: dchlient does not autostart anymore? Message-ID: <35b0f9e5-00a0-74ef-861f-1fe3fc51948e@FreeBSD.org> Date: Fri, 24 Mar 2017 14:04:12 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 11:06:00 -0000 The same for me (usb mouse + dhclient) on r315874. Touchpad is working. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 24 11:14:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B649D19CD1 for ; Fri, 24 Mar 2017 11:14:54 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from mail.mands.hu (mail2.mands.hu [93.189.114.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86CE216CB; Fri, 24 Mar 2017 11:14:52 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from MSEXCH13.mands.hu (192.168.4.5) by exchange.mands.hu (192.168.4.6) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 24 Mar 2017 12:14:50 +0100 Received: from MSEXCH13.mands.hu (192.168.4.5) by MSEXCH13.mands.hu (192.168.4.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 12:14:49 +0100 Received: from MSEXCH13.mands.hu ([::1]) by MSEXCH13.mands.hu ([::1]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 12:14:49 +0100 From: =?utf-8?B?TSZTIC0gS3Jhc3puYWkgQW5kcsOhcw==?= To: Ruslan Makhmatkhanov , FreeBSD Current Subject: RE: dchlient does not autostart anymore? Thread-Topic: dchlient does not autostart anymore? Thread-Index: AQHSpI5efdFRKCGt/E+6p4gjboBhtKGj1Y7A Date: Fri, 24 Mar 2017 11:14:49 +0000 Message-ID: References: <35b0f9e5-00a0-74ef-861f-1fe3fc51948e@FreeBSD.org> In-Reply-To: <35b0f9e5-00a0-74ef-861f-1fe3fc51948e@FreeBSD.org> Accept-Language: en-US, hu-HU Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.4.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 11:14:54 -0000 SXQgc2VlbXMgdGhhdCB1c2IgbW91c2UgcG9ydCBoYXMgYmVlbiBjaGFuZ2VkIGZyb20gL2Rldi9w c20wIHRvIC9kZXYvdW1zMDsgbG9hZGluZyB1bXMua28gIHdpdGgga2xkbG9hZCBhbmQgcmVzdGFy dGluZyB0aGUgbW91c2Ugd2l0aCANCg0KbW91c2VkIC1wIC9kZXYvdW1zMCANCg0KbWFrZXMgdGhl IG1vdXNlIHdvcmsgYWdhaW4gKGJ1dCBub3cgdGhlIHRvdWNocGFkIGlzIG5vdCB3b3JraW5nOyBJ IGNhbiBzdXJ2aXZlIHRoYXQpLg0KDQpyZ2RzDQoNCkFuZHLDoXMgS3Jhc3puYWkNCg0KDQoNCi0t LS0tRXJlZGV0aSDDvHplbmV0LS0tLS0NCkZlbGFkw7M6IFJ1c2xhbiBNYWtobWF0a2hhbm92IFtt YWlsdG86cm1ARnJlZUJTRC5vcmddIA0KS8O8bGR2ZTogMjAxNy4gbcOhcmNpdXMgMjQuIDEyOjA0 DQpDw61temV0dDogRnJlZUJTRCBDdXJyZW50DQpNw6Fzb2xhdG90IGthcDogTSZTIC0gS3Jhc3pu YWkgQW5kcsOhcw0KVMOhcmd5OiBSZTogZGNobGllbnQgZG9lcyBub3QgYXV0b3N0YXJ0IGFueW1v cmU/DQoNClRoZSBzYW1lIGZvciBtZSAodXNiIG1vdXNlICsgZGhjbGllbnQpIG9uIHIzMTU4NzQu IFRvdWNocGFkIGlzIHdvcmtpbmcuDQoNCi0tIA0KUmVnYXJkcywNClJ1c2xhbg0KDQpULk8uUy4g T2YgUmVhbGl0eQ0K From owner-freebsd-current@freebsd.org Fri Mar 24 04:20:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA008D19C6B for ; Fri, 24 Mar 2017 04:20:17 +0000 (UTC) (envelope-from jguojun@sbcglobal.net) Received: from nm48.bullet.mail.ne1.yahoo.com (nm48.bullet.mail.ne1.yahoo.com [98.138.120.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC2991D46 for ; Fri, 24 Mar 2017 04:20:17 +0000 (UTC) (envelope-from jguojun@sbcglobal.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1490329081; bh=ii5lEgRoz8WIxsCE31psZ2XC+CNI4AZ1qe5LHOYMvB8=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=bNI9s3kJi8X5DWDuTDuX4zX5XXdAufeMEeCIQ/DflDaRrGcAH5mX27m6AMPGNkeg11wi4cc4ARnFrTUXMTv5vk/Vup9UvbezPFVWB8ZdZRV6WQn+FV8+fGEFd31GZjhlxI/JudiiaK+p735SKPDPu9gBTrUWOBbXbwXSVJbzWLdiezxHEy8qicp6I+8Sd9hvwq/Ibziep9gQo/RKiQuD+X8Jr4uLoN9sba/AJ1XDseukilk92hSUctMpBiazgMu5cu+fyWH5l3FEyz7aimYEnPiYYMXOf/2ASgDL9t5O2OL9pPc1ztH2datmLcSow9zD9UazrAjhN/euPX8QNMekCA== Received: from [127.0.0.1] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 04:18:01 -0000 Received: from [98.138.100.117] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 04:15:15 -0000 Received: from [66.196.81.174] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 04:15:15 -0000 Received: from [98.139.212.236] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2017 04:15:15 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 24 Mar 2017 04:15:15 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 477648.5950.bm@omp1045.mail.bf1.yahoo.com X-YMail-OSG: srE2y6UVM1lecPOT2fluuadBKq1F8bRYvsuffQwydlCc5Vnlz7cVfqpvCJUKQjO .xpGh32DkC1oOW9Jt7aNY5pWuOSXv32iK4hkU5KcTh9kGOmqIuy6_m1xVU172a_gJ7cCjIoE07cr Yaax7sxOiT4vMp06Rl8074q2Y2jZo5vgvsLiyA2U_jseA4MqeVU.E7ZiywtTgAKaU0FvwrOo4sN8 8BEilaLsg2qYLB4bWO6OuzELVhGgJ7NzvRuwHUCivostIH9R17TES.8JWAzbro17DSxFFJrcgC85 HwyVp7MlTz2K_OpLHbs46eTkz1rsDMKqul8GMhHKYZ30EV6pIrc0VkkoQxYwNN8iFw73qfnX9Gt. mIW_67sIDSQwUzu4Tu6YCU.kJrCWHsT79HZ348gWehxYEJFEt3MZpobZsEyc68m1TOnxHcvYpwyC vKiRHm9VNrVgFT1QndMOksIudVAvmbqaao5DUUZCnyFXvbyhyTmrWkv_F2bRhzvi5Kl3b1_qZdop 4ortSgFtRuqpI1YWA4gMO0ryfGpqviu9ZuaAM_586PovAiIGFO9AE Received: from jws400070.mail.bf2.yahoo.com by sendmailws160.mail.bf1.yahoo.com; Fri, 24 Mar 2017 04:15:14 +0000; 1490328914.883 Date: Fri, 24 Mar 2017 04:15:10 +0000 (UTC) From: Jin Guojun Reply-To: Jin Guojun To: "freebsd-current@freebsd.org" Message-ID: <131319340.1954512.1490328910894@mail.yahoo.com> Subject: alloc/free abort/kill in 12 snapshot MIME-Version: 1.0 References: <131319340.1954512.1490328910894.ref@mail.yahoo.com> X-Mailman-Approved-At: Fri, 24 Mar 2017 11:18:56 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 04:20:18 -0000 A X11 based program works fine on 11 and all previous FreeBSD release and L= inux.When build on FreeBSD-12.0-CURRENT-amd64-20170316-r315413, it gets wei= rd crashes on either alloc and free.Both cases seem related to _pthread_mut= ex_init_calloc_cb ().Is this a known issue?=20 Is possible to determine why _pthread_mutex_init_calloc_cb () not happy? -Jin 1) calloc#0=C2=A0 0x000000080134322a in thr_kill () from /lib/libc.so.7 #1=C2=A0 0x00000008013431f4 in raise () from /lib/libc.so.7 #2=C2=A0 0x0000000801343169 in abort () from /lib/libc.so.7 #3=C2=A0 0x000000080133ae1f in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #4=C2=A0 0x0000000801333b99 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #5=C2=A0 0x0000000801333851 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #6=C2=A0 0x0000000801315e0d in _malloc_thread_cleanup () from /lib/libc.so.= 7 #7=C2=A0 0x000000080133e35a in malloc () from /lib/libc.so.7 #8=C2=A0 0x000000080133e8b1 in calloc () from /lib/libc.so.7 #9=C2=A0 0x0000000800b9ad41 in _XkbReadGetMapReply () =C2=A0=C2=A0 from /usr/local/lib/libX11.so.6 #10 0x0000000800b9ba1a in XkbGetUpdatedMap () from /usr/local/lib/libX11.so= .6 #11 0x0000000800b9babb in XkbGetMap () from /usr/local/lib/libX11.so.6 #12 0x0000000800b9837b in XkbKeycodeToKeysym () from /usr/local/lib/libX11.= so.6 #13 0x0000000800b98ac3 in XkbLookupKeySym () from /usr/local/lib/libX11.so.= 6 #14 0x0000000800b994d4 in XLookupString () from /usr/local/lib/libX11.so.6 #15 0x0000000000406a12 in update_pic (movie=3D0, movie_frams_sec=3D0,=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case KeyPress:=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char=C2=A0=C2=A0=C2=A0 string[25= 6]; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KeySym=C2=A0 keysym; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XComposeStatus=C2=A0 stat; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x_bool=C2=A0 shifted_key; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=C2=A0 hand= led_key =3D keysym, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 length =3D XLookupString(&event, string, sizeof(string) - 1= , &keysym, &stat); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0}This happens when some key pressed (likely a CTRL key). Thi= s function is doing input, so issue should not be in the caller. 2) freeWhen exit the application, it crah on free:#0=C2=A0 0x00000008013432= 2a in thr_kill () from /lib/libc.so.7 #1=C2=A0 0x00000008013431f4 in raise () from /lib/libc.so.7 #2=C2=A0 0x0000000801343169 in abort () from /lib/libc.so.7 #3=C2=A0 0x0000000801333198 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #4=C2=A0 0x00000008013321ab in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #5=C2=A0 0x00000008013316fd in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #6=C2=A0 0x000000080132350d in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #7=C2=A0 0x000000080133ee10 in free () from /lib/libc.so.7 #8=C2=A0 0x000000000045d67b in ccs_free (p=3D0x803200000) at zalloc.c:294 From owner-freebsd-current@freebsd.org Fri Mar 24 04:23:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64B43D19DC7 for ; Fri, 24 Mar 2017 04:23:29 +0000 (UTC) (envelope-from jguojun@sbcglobal.net) Received: from nm49-vm6.bullet.mail.bf1.yahoo.com (nm49-vm6.bullet.mail.bf1.yahoo.com [216.109.115.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C3991FE8 for ; Fri, 24 Mar 2017 04:23:28 +0000 (UTC) (envelope-from jguojun@sbcglobal.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1490329236; bh=BmnlARKyrBugG6I8xDW6b/CEDDSpym3i/XBtlpAzvbs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=emjuCP1QOmR48wZv/J+ZlFiXyODZAzwbktPqUSiJEp8LyYtTCdsZfURmIgsxZuVyiXrLZUMrkjFDU0E/mirPobkHZG2dKYsxKXSfJPEt/7Om2TqAoAtn6+aTqqRePhwSRCq7JwmRjwV1jhE1ekuxXRJgq3Ewj288+6P8m7IoDVds33iklFM4OwaI0LbAcgovzn2PTmHv8vWkmbViGiArZ9WR/TFEE1SK6VqsrrMIwZxel33yDKYlXPoKbiIy8YJvawjJyTVmJp7CD605vBxvxkagXdiBOcLk28LCNIT7YKwnUE33jRqou3sYPC6uHO8ndaa5V5ZqQ/nbCK5dMTUbGw== Received: from [98.139.170.182] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2017 04:20:36 -0000 Received: from [98.139.212.247] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2017 04:20:36 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 24 Mar 2017 04:20:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 370422.33036.bm@omp1056.mail.bf1.yahoo.com X-YMail-OSG: xtp7KcgVM1leLmZyCgTCTsUVE7.UCKg2B2M7oVbb8QPY4GPVqbYPBNIVhVZEyvB Fjt0gIYvgM2M_k_o1Wo8Z8hjBFMRG.bVnFCN0uJ5PKkLMwmzVhKXxc_zEdSRBIkWwHovXJlTDYlw x3lLkGcCEEvM7X25pnsWNbnh5iBa6WFt3caSeB1cxdt_rvRCYbwEIVdb5pkydx1NvNJZo2fTEFZ5 b_Ab9mPy7yjYS9O0v.agNXRUBLDS4Qkpgd6w6qTiXrq4991dmaki2puXG39IQaAKC1XL3gQw6dtU 60nmpO0fYphkwEvxO56mJBJCDms4qqcrl9Al8fU8du5TJGtch2YefpHymeKlVBf4zBR7AGB8VcJe OAD5WBGyK_uC5az57nvWUZ2We_lZa43vmqylWUf.Ge_9eS1r1ZXHu0GTOU.HL71SdersB0yS_VKk PkJaA07amlYyehNLtmDiJkYIgZ9eh1RkylVaR3NDDr3gsqWaiRNJ1yJNdFlI9uZs1iU56PHy1jZE 97lc.wjA2QhS.2D3GFPbIo81w3j7S503j_rDARMQh Received: from jws400012.mail.bf2.yahoo.com by sendmailws167.mail.bf1.yahoo.com; Fri, 24 Mar 2017 04:20:36 +0000; 1490329236.012 Date: Fri, 24 Mar 2017 04:20:35 +0000 (UTC) From: Jin Guojun Reply-To: Jin Guojun To: "freebsd-current@freebsd.org" Message-ID: <1030515329.2833582.1490329235779@mail.yahoo.com> In-Reply-To: <131319340.1954512.1490328910894@mail.yahoo.com> References: <131319340.1954512.1490328910894.ref@mail.yahoo.com> <131319340.1954512.1490328910894@mail.yahoo.com> Subject: Re: alloc/free abort/kill in 12 snapshot MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 24 Mar 2017 11:25:53 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 04:23:29 -0000 Forgot to post the console message when application crashed: Most times : jemalloc_arena.c:353: Failed assertion: "p[i] =3D=3D= 0" Some times =C2=A0: jemalloc_arena.c:1648: Failed assertion: "pageind + npage= s <=3D chunk_npages" On Thursday, March 23, 2017 9:15 PM, Jin Guojun = wrote: =20 A X11 based program works fine on 11 and all previous FreeBSD release and = Linux.When build on FreeBSD-12.0-CURRENT-amd64-20170316-r315413, it gets we= ird crashes on either alloc and free.Both cases seem related to _pthread_mu= tex_init_calloc_cb ().Is this a known issue?=20 Is possible to determine why _pthread_mutex_init_calloc_cb () not happy? -Jin 1) calloc#0=C2=A0 0x000000080134322a in thr_kill () from /lib/libc.so.7 #1=C2=A0 0x00000008013431f4 in raise () from /lib/libc.so.7 #2=C2=A0 0x0000000801343169 in abort () from /lib/libc.so.7 #3=C2=A0 0x000000080133ae1f in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #4=C2=A0 0x0000000801333b99 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #5=C2=A0 0x0000000801333851 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #6=C2=A0 0x0000000801315e0d in _malloc_thread_cleanup () from /lib/libc.so.= 7 #7=C2=A0 0x000000080133e35a in malloc () from /lib/libc.so.7 #8=C2=A0 0x000000080133e8b1 in calloc () from /lib/libc.so.7 #9=C2=A0 0x0000000800b9ad41 in _XkbReadGetMapReply () =C2=A0=C2=A0 from /usr/local/lib/libX11.so.6 #10 0x0000000800b9ba1a in XkbGetUpdatedMap () from /usr/local/lib/libX11.so= .6 #11 0x0000000800b9babb in XkbGetMap () from /usr/local/lib/libX11.so.6 #12 0x0000000800b9837b in XkbKeycodeToKeysym () from /usr/local/lib/libX11.= so.6 #13 0x0000000800b98ac3 in XkbLookupKeySym () from /usr/local/lib/libX11.so.= 6 #14 0x0000000800b994d4 in XLookupString () from /usr/local/lib/libX11.so.6 #15 0x0000000000406a12 in update_pic (movie=3D0, movie_frams_sec=3D0,=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case KeyPress:=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char=C2=A0=C2=A0=C2=A0 string[25= 6]; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KeySym=C2=A0 keysym; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XComposeStatus=C2=A0 stat; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x_bool=C2=A0 shifted_key; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=C2=A0 hand= led_key =3D keysym, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 length =3D XLookupString(&event, string, sizeof(string) - 1= , &keysym, &stat); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0}This happens when some key pressed (likely a CTRL key). Thi= s function is doing input, so issue should not be in the caller. 2) freeWhen exit the application, it crah on free:#0=C2=A0 0x00000008013432= 2a in thr_kill () from /lib/libc.so.7 #1=C2=A0 0x00000008013431f4 in raise () from /lib/libc.so.7 #2=C2=A0 0x0000000801343169 in abort () from /lib/libc.so.7 #3=C2=A0 0x0000000801333198 in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #4=C2=A0 0x00000008013321ab in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #5=C2=A0 0x00000008013316fd in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #6=C2=A0 0x000000080132350d in _pthread_mutex_init_calloc_cb () from /lib/l= ibc.so.7 #7=C2=A0 0x000000080133ee10 in free () from /lib/libc.so.7 #8=C2=A0 0x000000000045d67b in ccs_free (p=3D0x803200000) at zalloc.c:294 =20 From owner-freebsd-current@freebsd.org Fri Mar 24 13:20:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA64AD19000 for ; Fri, 24 Mar 2017 13:20:38 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) (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 6772D11B3 for ; Fri, 24 Mar 2017 13:20:37 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.lissoft.com.ua ([109.237.91.29] helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.89 (FreeBSD)) (envelope-from ) id 1crOb8-0002p6-VL for freebsd-current@freebsd.org; Fri, 24 Mar 2017 14:45:43 +0200 Subject: Re: dchlient does not autostart anymore? To: freebsd-current@freebsd.org References: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> From: Alexandr Krivulya Message-ID: Date: Fri, 24 Mar 2017 14:45:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 109.237.91.29 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-SA-Exim-Scanned: No (on graal.it-profi.org.ua); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 13:20:38 -0000 +1 Need to manualy kldload ums.ko and start dhclient. 24.03.2017 12:38, Lev Serebryakov пишет: > On 24.03.2017 12:28, M&S - Krasznai András wrote: > > devd problems? Now dhclient and moused are started by devd. > >> Hi, >> >> FreeBSD-current, r315895 also experiences the same problem. The problem started after updating my laptop yesterday morning. I can get an IP address after manually starting dhclient. >> >> I have an additional anomaly: the USB mouse does not work (touchpad works) on a Lenovo T510 laptop. dmesg shows the correct vendor and type for the mouse. >> >> rgds >> >> András Krasznai >> >> >> >> -----Eredeti üzenet----- >> Feladó: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] Meghatalmazó Mark Millard >> Küldve: 2017. március 24. 9:57 >> Címzett: zakharov.vv@gmail.com; FreeBSD Current >> Tárgy: Re: dchlient does not autostart anymore? >> >> Vladimir Zakharov zakharov.vv at gmail.com wrote on Fri Mar 24 08:20:34 UTC 2017: >> >>> After upgrading from r315544 to r315880 network interface doesn't get >>> IP address using DHCP on boot anymore. >>> >>> $ grep re0 /etc/rc.conf | grep -v "^#" >>> ifconfig_re0="DHCP" >>> >>> "service netif restart" doesn't help either. Only manual dhclient >>> starting. >> I have just updated two contexts to -r315870 just a bit ago and they both got that behavior as well: >> >> A) An amd64 context (FreeBSD client in VirtualBox under macOS) >> B) An arm64 context (pine64+ 2GB with -mcpu=cortex-a53 ) >> >> Later I'll be updating powerpc64, powerpc, and armv6 (with >> -mcpu=cortex-a7 ) contexts but I'd expect they will all match the behavior. >> >> (I started from earlier than -r315544 so your report provides a better lower bound -r315544. I ended earlier and so my report provides a better upper bound -r315870.) >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > -- From owner-freebsd-current@freebsd.org Fri Mar 24 13:37:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2586DD14493 for ; Fri, 24 Mar 2017 13:37:55 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED20A1B1A; Fri, 24 Mar 2017 13:37:54 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by freefall.freebsd.org (Postfix) with ESMTP id CC6AA69BB; Fri, 24 Mar 2017 13:37:53 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: dchlient does not autostart anymore? To: =?UTF-8?Q?M&S_-_Krasznai_Andr=c3=a1s?= , FreeBSD Current References: <35b0f9e5-00a0-74ef-861f-1fe3fc51948e@FreeBSD.org> From: Ruslan Makhmatkhanov Message-ID: Date: Fri, 24 Mar 2017 16:36:07 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 13:37:55 -0000 M&S - Krasznai András wrote on 03/24/2017 14:14: > It seems that usb mouse port has been changed from /dev/psm0 to /dev/ums0; loading ums.ko with kldload and restarting the mouse with > > moused -p /dev/ums0 > > makes the mouse work again (but now the touchpad is not working; I can survive that). > > rgds > > András Krasznai I did kldload ums; service devd restart; dhclient wlan0 to solve both the problems. Btw, both mouse and touchpad are working. Thank you for the temporary solution! -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 24 13:38:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CC01D144A5 for ; Fri, 24 Mar 2017 13:38:00 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE30D1B40 for ; Fri, 24 Mar 2017 13:37:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFtf4-1cvFQ308fe-00ErFY for ; Fri, 24 Mar 2017 14:37:57 +0100 Date: Fri, 24 Mar 2017 14:37:38 +0100 From: "O. Hartmann" To: freebsd-current Subject: r315900: /usr/bin/ssh: Undefined symbol "msetlocale" Message-ID: <20170324143738.0d676402@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gk2h1xTPbvyZx2k9V/yIB2nY15csUHz6/QDzr7imKTtpZ+eql96 YGYlNylJvFxYKF0ToR2PoL/cjFVDkgUWMgA8gbj+Pg8DNpYXUhqJ3VKGDiBXUKTeOy3umCs CRQXrbLHYDI0gZsL0Sa9kJZ9UlILfTOYZC9cfHPoVOe9YWJY6oQn7gTQ9vdV3HGuGFlqbKI A1GZl4BkhQrdKSIvXHgng== X-UI-Out-Filterresults: notjunk:1;V01:K0:82e01At2tHk=:/eyrAe3DKt16pycSw9U4KL +dbaV35SpUzSi93qVsxoPNuAdxfY237azrN0IwaxG8iLUgqxOSP2+kOaaNg6KtJ4epYdgXu6B gc1bpOOO/xl36E1VPTmwRJM+M/QGq5Ewv0wk//xQPUig2CBdqoOw3dPCjjX8oHAVWTwyQP6iF IA5ODj9ktPVTYryI8y7KrgChD28/k9TysHasMw/5TkirZYyiN8UcnvRT5LeWUGg4pQSWs1S9m QpehFxmL1aI/Ys0r+YLcLxzLN/8L+4Zq002VHTT9j0C6Jbn5nqngoZ9HFEhNL7XAXOJOGBmCB H3xtdysSACyccmwQFI5ZF4TQq82pa+Idc/Q7RldjFjJz/5gu71mrOqjsj5kUT7R1Oc0WXuxFm Ut3O3ppL6PE3OL4+0GWses5rs5hR4VifocPwr4r+nNx6zs647V7XQLqlA4MUosw96t1wrjOlW Pj57zZdGGpFsz0qzgn3/QdJRmPuX7pO0L8qP094Gtn5u/FbmGQ1myM7kX0GwmJlY0S1FLTD3C jK/X/d1/MdQvCoWaqe4F6mx3Lu5kADVN34LrKT/1W/I8qd1qDm8mJbgENw3EMzSR3jcZX2npx UKJMPPRlsv2pKFZE5c1sNcNZSSwJ8qCcm3FOGDOoVVlBaRFFz1FP4aY9T0m/tGCIdk8mabox7 SUOfV/UPAjuz4hXJLdWSBayUzIbVGPJ+/hwFNdR6YhN758s6glztTTc8MZmSmmg5Jr0CEtTsE j89tHiCv9hpoDclhnblsdPzOjk+sGOBuY3Go9Vx8+ccT0sruwNnTeODv1lUTUJd9oN6AHtC4b sGP6a8x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 13:38:00 -0000 Having just updated CURRENT to CURRENT 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r315900: Fri Mar 24 14:17:22 CET 2017 amd64, I can not connect to remote systems via ssh anymore: /usr/bin/ssh: Undefined symbol "msetlocale" Google suggests for this kind of error a miscompilation of the binary. I had a crash, again (SSDs and CURRENT have a serious problem!), had to improvise with the USB flash ISO image of CURRENT found on FreeBSD.org from 23.03.2017, ~ 18 o'clock, but have rebuilt and installed world and kernel from a clean /usr/obj two times. Still being bugged by this mysterious error. Can somebody help, please? Thanks in advance, Oliver From owner-freebsd-current@freebsd.org Fri Mar 24 13:52:48 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 327E4D14D00 for ; Fri, 24 Mar 2017 13:52:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6CCB0E for ; Fri, 24 Mar 2017 13:52:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1BBDAD14CFF; Fri, 24 Mar 2017 13:52:48 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B5FAD14CFE for ; Fri, 24 Mar 2017 13:52:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 C0AC8B0D for ; Fri, 24 Mar 2017 13:52:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v2ODqkqK015740 for ; Fri, 24 Mar 2017 13:52:46 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v2ODqkd5015739 for current@freebsd.org; Fri, 24 Mar 2017 06:52:46 -0700 (PDT) (envelope-from david) Date: Fri, 24 Mar 2017 06:52:46 -0700 From: David Wolfskill To: current@freebsd.org Subject: Re: dchlient does not autostart anymore? Message-ID: <20170324135246.GJ1242@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gfpq6yKqvKwri7QU" Content-Disposition: inline In-Reply-To: <25AAEBD2-B4E2-4DD1-86DA-AE94AA4A6B7D@dsl-only.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 13:52:48 -0000 --gfpq6yKqvKwri7QU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 24, 2017 at 01:56:38AM -0700, Mark Millard wrote: > Vladimir Zakharov zakharov.vv at gmail.com wrote on Fri Mar 24 08:20:34 = UTC 2017: >=20 > > After upgrading from r315544 to r315880 network interface doesn't get IP > > address using DHCP on boot anymore. > >=20 > > $ grep re0 /etc/rc.conf | grep -v "^#" > > ifconfig_re0=3D"DHCP" > >=20 > > "service netif restart" doesn't help either. Only manual dhclient > > starting. >=20 > I have just updated two contexts to -r315870 just a bit ago > and they both got that behavior as well: >=20 > A) An amd64 context (FreeBSD client in VirtualBox under macOS) > B) An arm64 context (pine64+ 2GB with -mcpu=3Dcortex-a53 ) >=20 > Later I'll be updating powerpc64, powerpc, and armv6 (with > -mcpu=3Dcortex-a7 ) contexts but I'd expect they will all match > the behavior. >=20 > (I started from earlier than -r315544 so your report provides > a better lower bound -r315544. I ended earlier and so my > report provides a better upper bound -r315870.) > .... Well, I just updated my (amd64) laptop from: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #293 r3158= 53M/315854:1200027: Thu Mar 23 06:41:30 PDT 2017 root@g1-252.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 to: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #294 r3158= 96M/315899:1200027: Fri Mar 24 06:36:28 PDT 2017 root@g1-252.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 =2E.. and had no issues (with dhclient, mouse, or anything else). Peace, david --=20 David H. Wolfskill david@catwhisker.org Who would have thought that a "hotelier" would be so ... unwelcoming? Sad. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --gfpq6yKqvKwri7QU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJY1SSuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XUowH/RJy7bVOfZy/VxUkVPGHcb4r Bp4nbhBSaGh3nJr30K+YR5+C+1q6EpYyADuRnG8tbCqGtljqrevdWb3yItSMUSS5 NGLFPaRASbiUVuEPKEdCL5+NS+wrC2NR4dbtMRYk/eWDiSPYlnKnEoGPe9GTRzWq mXgnjk2KTadSCIvJOqz/jgJjrPYx4UcE+pemj64LjmqHkzku3MINh5+0G/Yo7945 OLolE10UQqMqgEinXTt7i4h881j0A0RD97Ur93hmuzSZacHeaHwf549KHuzy37jX lvirqF6tA63QjGLjCZhvsVVBHKx5lOrCHxuQqbBepg4BZSuoReKZ4jA5UOvbLqY= =v2nx -----END PGP SIGNATURE----- --gfpq6yKqvKwri7QU-- From owner-freebsd-current@freebsd.org Fri Mar 24 14:28:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34ECED1BAD5 for ; Fri, 24 Mar 2017 14:28:33 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2EF16DF for ; Fri, 24 Mar 2017 14:28:32 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id d188so4901785vka.0 for ; Fri, 24 Mar 2017 07:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cj9qAz9eO+HExxavg7f+rrxKY0GZciaTLugk0oAUaLU=; b=u5SSSGPziDFte6wgQPOmX23nVUeiHANh6imtL+hBVss3MeztBAZVLxj4LnTnN7t8U7 J3Nm11ZT5k02YFwxXJ3Z/hL2i1chLTebfL8Y8pYpgh5CONHJ2u1WMAIDjUaQEnqel5jp rARVjvHUh30tKxRYTin4hUxKo/+qR/s+7sjMVwJa0Ezl7LxJWWEPqbzCQGqviI2aeP5e 09TQPH4AqO/gfwhi/SKNl6yx7xl0ig+beo6n13FHU7wtxBIRS6NVEspH7HE6CE+sXrv+ DlCDAflX3F4U+KySN30UA/is9zRDjHDOBEouezTr4geobqao7weLVav8DpzffHsY5sYq KLIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cj9qAz9eO+HExxavg7f+rrxKY0GZciaTLugk0oAUaLU=; b=VzbaMVfkW4wmHeMqBFM82aBrHkR+H8Q+2+/hQtegGOt5YfULxsn0i0oKCo6ynA3rY3 /457wBTDa19yD4nAqKHKfK8y9xVufHdc8n8w4K0rPDazKcnRBcXpyHdRpHUfBidVFFXK OdLL021n9xzy6M9q/uyUiX+R3uYmlNY9E9r5hhOyQvYnk11T3CUl6x2LsRKaCpkN2QmP xjSVyI38v2jWLU2XLno7uwKzsLeAfMx2XpHrIUNdCRTgyN4ybg26uFg5dXYAHiYd+T43 EaTiKWKuOx6nSu87rkqVzntI5JC988XMi1Sy32/4ohVZ85sG26aeE79lweQ+2BPgAbEK sbBw== X-Gm-Message-State: AFeK/H3nj+b/ChokTi9S6If+YnGfnyETBtdidzLcuf3kEWjMOWsqkWzjquTIm5DU7tAiIcL3LoouDMivMQ0loA== X-Received: by 10.31.77.196 with SMTP id a187mr3279543vkb.99.1490365711913; Fri, 24 Mar 2017 07:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.65 with HTTP; Fri, 24 Mar 2017 07:28:31 -0700 (PDT) In-Reply-To: <20170324143738.0d676402@freyja.zeit4.iv.bundesimmobilien.de> References: <20170324143738.0d676402@freyja.zeit4.iv.bundesimmobilien.de> From: Andreas Nilsson Date: Fri, 24 Mar 2017 15:28:31 +0100 Message-ID: Subject: Re: r315900: /usr/bin/ssh: Undefined symbol "msetlocale" To: "O. Hartmann" Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 14:28:33 -0000 On Fri, Mar 24, 2017 at 2:37 PM, O. Hartmann wrote: > Having just updated CURRENT to CURRENT 12.0-CURRENT FreeBSD 12.0-CURRENT #1 > r315900: Fri Mar 24 14:17:22 CET 2017 amd64, I can not connect to remote > systems via ssh anymore: > > /usr/bin/ssh: Undefined symbol "msetlocale" > > Google suggests for this kind of error a miscompilation of the binary. > > I had a crash, again (SSDs and CURRENT have a serious problem!), had to > improvise with the USB flash ISO image of CURRENT found on FreeBSD.org from > 23.03.2017, ~ 18 o'clock, but have rebuilt and installed world and kernel > from a > clean /usr/obj two times. Still being bugged by this mysterious error. > > Can somebody help, please? > > Thanks in advance, > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I haven't upgraded myself yet, but I fetched the sources. Could you check ldd /usr/bin/ssh ? If you have libprivatessh in there, could you do nm -D /usr/lib/libprivatessh.so | grep msetlocale and see if you get any output ( I think you should get one line ) Otherwise it would seem that either libprivatessh is not built correctly or that it is not installed correctly. But these are just my guesses. Best regards Andreas From owner-freebsd-current@freebsd.org Fri Mar 24 15:20:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E18E3D19DEA for ; Fri, 24 Mar 2017 15:20:43 +0000 (UTC) (envelope-from kp@krion.cc) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D3BEA73 for ; Fri, 24 Mar 2017 15:20:43 +0000 (UTC) (envelope-from kp@krion.cc) Received: by mail-yw0-x235.google.com with SMTP id i203so4071061ywc.3 for ; Fri, 24 Mar 2017 08:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krion-cc.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mINMb1ULwjDfYtXZsoW/EguDr8UcrxbrVafHWh+V8Fc=; b=c2ZejVsaR9wV+8pv2FpCzH/xohG2iaO123iZFbbxmM9z5KIHU9kaYr/d4hpzg2yoQQ kHaunt/zdVqFFLx3coOdBosPhYbi78ZIb1u8CQu+SZ/fSkfyrbIPZXHwXKYtbaupQGM3 vM8r/GT1qeoZpCZEghbuCQbZBFjn+XGc7FnQ621rBxdBtQk75ssa5vQtYPr10P90DMkp F5YALY4zUHb8MrL+uQE6YnPNaqTEim+OejiRSu6VIuh6xVF01W8958bEz3t9aTBhv5mD 3hh2Sx/QZmli7c3ni4do+yl4Dhw8UuGP73swUPvLU5GVe5UaS4MhCYuPwuPjijVtbaPJ 30dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mINMb1ULwjDfYtXZsoW/EguDr8UcrxbrVafHWh+V8Fc=; b=ds23wodaKRCps+B1M90z75l23izeRxVMaNePVLz9sZFdfq5YBwG3xLQ0VInd2oDRwC SyopqSNjn6UOtNldJlZEn0F16i0tXM7aGwz2rs87Zpin1WburYdPO4uYeTklMsEZDMmG exX2fPtWjufbUP4ajp5MnfHKgHGqAfPKtQGfZRV+2Q0gcPUPoX/IK0ohfAuJWKULqwtz LR4SyQkyVDgW4UrezryvcjaTRrVcFMmHSa/TdjzC8noS4kGLq87B4z7CS5IUZlYJXkCg vgPtqyI6ZgACqi+sasXBvyAF6oLokgRL3uHOtbWrukDvvnXtCcEq33U3BGA/X4QLgGPc SYSg== X-Gm-Message-State: AFeK/H3WgRqMRnJ3qxvT8cIdEoKeYPoNokQIRLBDma4lfKlI26jDZlMpmwENs2Sab1R1yQ== X-Received: by 10.37.161.136 with SMTP id a8mr6230772ybi.115.1490368842738; Fri, 24 Mar 2017 08:20:42 -0700 (PDT) Received: from vein (krion.cc. [148.251.53.37]) by smtp.gmail.com with ESMTPSA id t80sm953292ywg.67.2017.03.24.08.20.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 08:20:41 -0700 (PDT) Date: Fri, 24 Mar 2017 16:20:45 +0100 From: Kirill Ponomarev To: Vladimir Zakharov Cc: freebsd-current@freebsd.org Subject: Re: dchlient does not autostart anymore? Message-ID: <20170324152045.yi7fgt5aeijkfrl7@vein> References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ar5hderlcffntlxd" Content-Disposition: inline In-Reply-To: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 15:20:44 -0000 --ar5hderlcffntlxd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/24, Vladimir Zakharov wrote: > Hello! >=20 > After upgrading from r315544 to r315880 network interface doesn't get IP > address using DHCP on boot anymore. >=20 > $ grep re0 /etc/rc.conf | grep -v "^#" > ifconfig_re0=3D"DHCP" >=20 > "service netif restart" doesn't help either. Only manual dhclient > starting. Same issues here with today CURRENT, r315896. K. --ar5hderlcffntlxd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJCHRFhEAQujKni1pDyI9/LMCykUFAljVOU0ACgkQDyI9/LMC ykWPPQf/cfYhYkl41Nm14dJLaBpDNXl2lOCRAra6kYOI3cFtTATVWMlY2nlKjvBM h3bgVb7WQ7CVDpMIr0leig9nUbPbTtMH4n2cWzRiZx84i2FZv30FuXNS5h3RqMCD N1oQtiKQ22gsG12zxEeuxtERvA35J0Dt/149YwKgM4Lhfp5uOTMlwp7YblwXh0xR XMTRfcTbXq1vbRLg+oS/VcXurdcBRTRV9aEOPWfNJPfAssjpXkuYyKgAEIV7CVcQ 4FVixw/hiuWCjzBzrZ4WL0OkkWhXUF0EZ4UgP95nkQnOml6b4c81f3DGongpAS7b gDdTqV1ZV58Gd+V0Sm0NoxYfeCUubA== =WTDl -----END PGP SIGNATURE----- --ar5hderlcffntlxd-- From owner-freebsd-current@freebsd.org Fri Mar 24 15:22:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 570E3D1B184; Fri, 24 Mar 2017 15:22:11 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34738D4E; Fri, 24 Mar 2017 15:22:11 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PnpCz4Z5S6U0wDFkZ41A/Okm/kHyMVZbdICtqN48TGM=; b=M4lfK1iNUaMK9scDv0H0up2Mms sRe+jMvWKEMGJXgs3XxVNd+y4oD1QO0bNFp2zI/AhyKN1AtFK1RtKjIpOS6lMst2SYIebZJ5Aryei OnWH8SK8NJX1l+Kbu1Nx0zMrLgAYGPfMyxOcyxDtx43Kj9OFCZ0hws+BBexjSMd36jPs=; Received: from [74.203.163.58] (port=2175 helo=[10.106.10.51]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1crR2Y-000Jz3-05; Fri, 24 Mar 2017 10:22:10 -0500 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Fri, 24 Mar 2017 10:21:39 -0500 Subject: Re: crash: umount_nfs: Current From: Larry Rosenman To: Rick Macklem , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Message-ID: <6FB99978-BCFC-4E84-9F1C-E312D4BFC747@lerctr.org> Thread-Topic: crash: umount_nfs: Current References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> <1AEC680C-BFE4-4B07-816E-3DEF1B6D266C@lerctr.org> In-Reply-To: <1AEC680C-BFE4-4B07-816E-3DEF1B6D266C@lerctr.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 15:22:11 -0000 I tried my test (umount =E2=80=93t nfs =E2=80=93a && mount =E2=80=93t nfs =E2=80=93a) and no crash.= (with ~84G inact cached NFS data). I suspect it helped. =20 --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281=20 From owner-freebsd-current@freebsd.org Fri Mar 24 15:47:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9D55D1B9F2 for ; Fri, 24 Mar 2017 15:47:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4D71E8B; Fri, 24 Mar 2017 15:47:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: dchlient does not autostart anymore? To: Kirill Ponomarev , Vladimir Zakharov Cc: freebsd-current@freebsd.org References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> <20170324152045.yi7fgt5aeijkfrl7@vein> From: Jung-uk Kim Message-ID: <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> Date: Fri, 24 Mar 2017 11:47:27 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170324152045.yi7fgt5aeijkfrl7@vein> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rFHnHEUw4S4bQUrXvR9E1wC1AXUBCXbK1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 15:47:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rFHnHEUw4S4bQUrXvR9E1wC1AXUBCXbK1 Content-Type: multipart/mixed; boundary="iMWUd6FaCsKBlo9uaMU9asE0gPkShgq1K"; protected-headers="v1" From: Jung-uk Kim To: Kirill Ponomarev , Vladimir Zakharov Cc: freebsd-current@freebsd.org Message-ID: <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> Subject: Re: dchlient does not autostart anymore? References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> <20170324152045.yi7fgt5aeijkfrl7@vein> In-Reply-To: <20170324152045.yi7fgt5aeijkfrl7@vein> --iMWUd6FaCsKBlo9uaMU9asE0gPkShgq1K Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 03/24/2017 11:20, Kirill Ponomarev wrote: > On 03/24, Vladimir Zakharov wrote: >> Hello! >> >> After upgrading from r315544 to r315880 network interface doesn't get = IP >> address using DHCP on boot anymore. >> >> $ grep re0 /etc/rc.conf | grep -v "^#" >> ifconfig_re0=3D"DHCP" >> >> "service netif restart" doesn't help either. Only manual dhclient >> starting. >=20 > Same issues here with today CURRENT, r315896. FYI, r315901 fixed the issue for me. Jung-uk Kim --iMWUd6FaCsKBlo9uaMU9asE0gPkShgq1K-- --rFHnHEUw4S4bQUrXvR9E1wC1AXUBCXbK1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAljVP5YACgkQfJ+WJvzb 8UY8vAf/SkpcUX+z8JFQnsgF//6sq+aIH+2+0iwJYmgoaZx7XBQx07U10Tz/oYX4 7m1YL6PaYcjVkloyzVQxv6LWNQXisiaNK44Pbxkmgnz7rkfem3Bk+fZyrg+tEsBM aq0jnfWACalglF06p000/JUnpIbqRCrgZmshQO9KCj6b74YUd8bDsz2/zdZHvR5w YsJX7QPLB/7gwKYUIr8TgHnh0Izz5A4/VVE219ulvtTkIoSyKDYXzZx3ggVoEawN lex4qyjr+SRm4W0GWbyI6bMfW57Wzs48kOTdHw8drh3xhWq+t3lgTmOZdQjoELx9 HLAZaqUFhyWzIvYa51rVtyJKQnz6fw== =0PbU -----END PGP SIGNATURE----- --rFHnHEUw4S4bQUrXvR9E1wC1AXUBCXbK1-- From owner-freebsd-current@freebsd.org Fri Mar 24 15:11:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE21BD1984B for ; Fri, 24 Mar 2017 15:11:12 +0000 (UTC) (envelope-from kp@krion.cc) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B448910F for ; Fri, 24 Mar 2017 15:11:12 +0000 (UTC) (envelope-from kp@krion.cc) Received: by mail-yw0-x22a.google.com with SMTP id p77so3913632ywg.1 for ; Fri, 24 Mar 2017 08:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krion-cc.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=e+mx0dcf1L6v5gKyi/Ot3LpKuccSGfniHa5jkNvcwBU=; b=svauNqLFKejeggWzhm0qOlBxcZbkbugAEliI3yeTcKohyb2FyK3bcIlNPH5S6wtGMl WNUoSrqjYR5gYdUUSmoF02LqvVhRk5pPbt+R8+p4kvjtf5yTzrwDJGmKci8X6GVkLLMK 0S307Q+DFPC4y/nHDn7aH9SbfyLzriPVDxGVtHNipJJ/YJVNPqinbYMsDc9Kqc5sGqjT yQ8Hn6TSqkWzstjOpPjeFDgdNDQuUGWax6xcfPzSRWcnTlSmrG8Uy2kY4HZP8b06+3/i GAoKEdrIoGjxIMq0oddi3yxhkGaKDkuE0R9XKgNaN40+cpTb9XwEsAulFevS8moWo9JC HgIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=e+mx0dcf1L6v5gKyi/Ot3LpKuccSGfniHa5jkNvcwBU=; b=gArstlpIN/ptVs3n89kLt96oV1F8uO/G9Wgn2WEhHhnbd3rQVaZH+h61lDkYC5IYIT hFPMpjCz6TI2p4oCYI8TT/a/a2nqIMu5+fsDvpi0Mn8I0yD7HrI6zylE36TIsIfUDHTj At2Hkyu5X84PnZlYaVDC4NZVOIotSYWxY0YNekL5YGeTnuqhLMhZ/qwBOhbYA0louf0t eQ5ETo5w9SpWP+3G0/PyseIFKQpQ1Cb1Yr4X6ZyEHhRTOfRtVPnV4DfGVopWuyjpWusE jez39XvWSVxqPUVjQXCREBXA1BbPA2H03x8h1vigxVd4XwTGeXvA/WFYZqKkyghFaqoz 18wA== X-Gm-Message-State: AFeK/H0ZbF/f7ABxHY99ZQB+0oDBDEuqD9z2OIdj+/YnD06SRO6ZZyILunoZK8dusjCgTA== X-Received: by 10.129.130.196 with SMTP id s187mr6350148ywf.57.1490368271321; Fri, 24 Mar 2017 08:11:11 -0700 (PDT) Received: from vein (krion.cc. [148.251.53.37]) by smtp.gmail.com with ESMTPSA id i17sm962289ywg.4.2017.03.24.08.11.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 08:11:09 -0700 (PDT) Date: Fri, 24 Mar 2017 16:11:12 +0100 From: Kirill Ponomarev To: Vladimir Zakharov Cc: freebsd-current@freebsd.org Subject: Re: dchlient does not autostart anymore? Message-ID: <20170324151112.2eciy5c4iub4xfmd@vein> References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ifvriddsprmt6vrm" Content-Disposition: inline In-Reply-To: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> X-Mailman-Approved-At: Fri, 24 Mar 2017 16:02:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 15:11:13 -0000 --ifvriddsprmt6vrm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/24, Vladimir Zakharov wrote: > Hello! >=20 > After upgrading from r315544 to r315880 network interface doesn't get IP > address using DHCP on boot anymore. >=20 > $ grep re0 /etc/rc.conf | grep -v "^#" > ifconfig_re0=3D"DHCP" >=20 > "service netif restart" doesn't help either. Only manual dhclient > starting. Same issues here with today CURRENT, r315896. K.=20 --ifvriddsprmt6vrm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJCHRFhEAQujKni1pDyI9/LMCykUFAljVNxAACgkQDyI9/LMC ykXXqwf/YMmh0ZcmnawPJ3mdgzTXcfansQZWzjBBQUWOXc4tckKrMNqOCn5V9LNK o3Aup2ApFZZjFEDgwPrMJsA1CxL5J6aVAoq+m45HATS85upMb1SaLJyvBRo+5TCi znmo4B2g3QLXluV2DMGBQ2BDkBSCeR5B3jaoQzgBmKZLuNi8hXGOFvY9P39noO+a yfNLlsouy1fj0USKwzdUhQ82WTQdHve4MRpwMp/8AddlR3IuzzvTRbcv27mqiHj5 zTVNcVFu4GGsfK6/UplaEnAZBS+V9Qexk6RAjdJW/3Uy/kL6gVZn94pq9hv6Wqof 12GAj8TAqIVb6ju2B0fYntnENkdegw== =qqEq -----END PGP SIGNATURE----- --ifvriddsprmt6vrm-- From owner-freebsd-current@freebsd.org Fri Mar 24 16:53:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AB86D1B10E for ; Fri, 24 Mar 2017 16:53:05 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F718D39; Fri, 24 Mar 2017 16:53:05 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id r36so892542lfi.0; Fri, 24 Mar 2017 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tPZwH8rFBfjUVnlgEcQ3cg+Fhm1Sl0ITPfjKSMZoKpU=; b=AYlwLrCfhRQdTaM03s+c4slDmRR5C6/cfRNsui1ED16ut5FkwaMI9oZeWxVopSALeR 9DxiGnO04OCs5PklgNhr+c0bBVpOO+e1aGiwImPIn0lLJneSqCs84oV4PPAFkPXLEVG6 KhloUyunOFmfYNvKT1RQbzo0a8gUhO7o6P229vs7cWQL/RtDiO6aA1TUCB87SxCLLTjO uj/e46fe251bn2S357Gu920XZE1OK79pTxke/QOBMfj5RIBHM2ldKR1pwmFB5QMH9xL9 90CHOsVe3PdRwvGpEAX8XgTv/AfC6TtQc/Hj887eUlrpnTeBm2TmDoVp62e69S2NGTeu pgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tPZwH8rFBfjUVnlgEcQ3cg+Fhm1Sl0ITPfjKSMZoKpU=; b=CYk0z01DeS+olXMLKU5kVnS+ZsRMpTfHOEpieiuo6jw6nR6AfI6lwbLxp3tfOotJAM 66tmOVASt9BfOZtJyIyLw4EDQ4bfEsDjtASVUDBdasej2iw1ns9dsxZZ3BduoMYlYkFi Ryd5g7iBK1XVIPODihaaO39HbHSTfu2j801h1dMCsa9EgnyCRVx6fN92iaWIPGU8uS1y YNQaLbJ+U+mE8u9uteqVQKKbEnAi1GsOhmMdwttAdwPMgw5f+XZ47cOM9TGM8N9FDiQO f3NA50uA/cdZrwvahLxfK0o4HNX6ZiTrqOl0PHFM8OHy3Q6FNwjBtqTeygrA3FzbNvPE wvcw== X-Gm-Message-State: AFeK/H3m7FihegvdYHBTm6iY83vYo8z/Kf5GP+zLh3lQdh7vlTqrydslLyQi6fr7QBg3/g== X-Received: by 10.25.155.132 with SMTP id d126mr5217230lfe.110.1490374382586; Fri, 24 Mar 2017 09:53:02 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id o100sm457635lfi.18.2017.03.24.09.53.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 09:53:02 -0700 (PDT) Date: Fri, 24 Mar 2017 19:53:01 +0300 From: Vladimir Zakharov To: Jung-uk Kim Cc: Kirill Ponomarev , freebsd-current@freebsd.org Subject: Re: dchlient does not autostart anymore? Message-ID: <20170324165301.l2mbhv3db2qjmpmx@vzakharov> References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> <20170324152045.yi7fgt5aeijkfrl7@vein> <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 16:53:05 -0000 On Fri, Mar 24, 2017, Jung-uk Kim wrote: > On 03/24/2017 11:20, Kirill Ponomarev wrote: > > On 03/24, Vladimir Zakharov wrote: > >> Hello! > >> > >> After upgrading from r315544 to r315880 network interface doesn't get IP > >> address using DHCP on boot anymore. > >> > >> $ grep re0 /etc/rc.conf | grep -v "^#" > >> ifconfig_re0="DHCP" > >> > >> "service netif restart" doesn't help either. Only manual dhclient > >> starting. > > > > Same issues here with today CURRENT, r315896. > > FYI, r315901 fixed the issue for me. For me too. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri Mar 24 16:45:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3D32D1BEF4 for ; Fri, 24 Mar 2017 16:45:16 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 733369CA for ; Fri, 24 Mar 2017 16:45:15 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.175.41]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MJmcS-1cqLsK3IBg-00187Y; Fri, 24 Mar 2017 17:45:12 +0100 Date: Fri, 24 Mar 2017 17:45:11 +0100 From: "O. Hartmann" To: Andreas Nilsson Cc: "O. Hartmann" , freebsd-current Subject: Re: r315900: /usr/bin/ssh: Undefined symbol "msetlocale" Message-ID: <20170324174511.715f51c5@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20170324143738.0d676402@freyja.zeit4.iv.bundesimmobilien.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/6s0YyF6enlE+L7gWMFRqenY"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:A+Czx7B6pRt25+6fl796HYlXEbcv3hF2ln2mUUklMkYNXzKimlm xln7UuTC751VLQSoCZkYafkxlc6YszbHWlbMgvXjBq968ucdewKG4yB8v91uHIIKge2v7Cd pSbUTSQys5OTnxX8zcezKOPiRVnEF+Sp0ExthJ/I5R50PL06I7mt051Q4XcR0yStkVBAzN/ 6IROZYWicI63KQtVrBXAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:DsL8XMhpo3Y=:vU6YiiwQN+wUQqNk7uuQXs p+UG0mLmyBYDs0TRy/5Lejs5lJKA1meG1vhFByoCYVwa8sn20HH4rJWo6qLe2osZ0U8NInj+g rznL5jYv6wcdA8dQ0Zpwm5BYOYwf8dYRc97MzNkIjO65A7cbCQusPjty2EJImrhvVw8rtOM2Y EJlE2Ij0IZckgX2S2eU59DdBycct3ACT8RUU3XktMBZrpgVeSXzg91kkhyQGBw7GK3/uqnYRm A/8N0QRr2DuwuaOSjM9tCVZqmpKJbsweheteYiGU14O8fDqAr+U7jIk4QnyvPjsd4aCk7wQAB WpAmk/WSHNnwNA2rDxXP3lAqlMkBV2d2BPHkSGgOdq0QAD/rUqc8DRjVizo4sWbllqiFmPwL4 ByvM0S6eY5pzx1iiJ/IxkXizjznhDk14mEas86OnIFZFepOkkIlAYNwyum7pwVQkUZzXonn37 MCquXX7uGCWetEFabiYuuqvpCVJ42ez4yGdmG+cHW2fj/9XrbY1Dy7LuRWgi/Mu8c4fxMOwCc eHB/ru/vCmIYqi7fAGdhlC2F5O9OzMcgX3188kTrAfPTnamFKE8P8hwHqXnDiKWgfcOCgzxoC SZe21RcM8AU4EY8o9jOv+Qjpm1S05ANGDWbyhTIN57enISYI2mtpfIK1DPzUr68SM6jEZU9t+ wDoNH8UyA/YPn+hYCYd6Q1GB/pVa0wLiu7CXxYN80YzRDVChsIFIW6qpBhrXovBIffoqCnAoa m2yJRiABP3aZT0zMriV9a19eelyd/GhCfkDKZAc05qf5skG71vqu9rmBg78= X-Mailman-Approved-At: Fri, 24 Mar 2017 16:54:57 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 16:45:17 -0000 --Sig_/6s0YyF6enlE+L7gWMFRqenY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Fri, 24 Mar 2017 15:28:31 +0100 Andreas Nilsson schrieb: > On Fri, Mar 24, 2017 at 2:37 PM, O. Hartmann wro= te: >=20 > > Having just updated CURRENT to CURRENT 12.0-CURRENT FreeBSD 12.0-CURREN= T #1 > > r315900: Fri Mar 24 14:17:22 CET 2017 amd64, I can not connect to remote > > systems via ssh anymore: > > > > /usr/bin/ssh: Undefined symbol "msetlocale" > > > > Google suggests for this kind of error a miscompilation of the binary. > > > > I had a crash, again (SSDs and CURRENT have a serious problem!), had to > > improvise with the USB flash ISO image of CURRENT found on FreeBSD.org = from > > 23.03.2017, ~ 18 o'clock, but have rebuilt and installed world and kern= el > > from a > > clean /usr/obj two times. Still being bugged by this mysterious error. > > > > Can somebody help, please? > > > > Thanks in advance, > > Oliver > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > =20 >=20 >=20 > I haven't upgraded myself yet, but I fetched the sources. >=20 > Could you check ldd /usr/bin/ssh ? > If you have libprivatessh in there, could you do nm -D > /usr/lib/libprivatessh.so | grep msetlocale and see if you get any output= ( > I think you should get one line ) >=20 > Otherwise it would seem that either libprivatessh is not built correctly = or > that it is not installed correctly. But these are just my guesses. >=20 > Best regards > Andreas > _______________________________________________ I'm in the office on Monday and I'll check this. I have just updated and built world on servers in my lab and homeoffice and= I do not face this strange error on the servers there, it's r315905 here, if this matters= ... Kind regards, oh --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/6s0YyF6enlE+L7gWMFRqenY Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNVNFwAKCRDS528fyFhY lAKMAf4xjvWvDeIH+BuYK2H9XJnbQQdtXvyfBAdFH5nlNF1Yawty0AjT/vVj5yJl 5ccNGv8KIducFbKIIOYkbSaVMQL8AgCLGjWE3fwMPTiwv6YB788ArH3RGHB+jm7W lZJCwsytA9lGEHmbF7zdUSJcv3JRFsczBXwfB9pI/ajCzAs54Bv9 =Yigm -----END PGP SIGNATURE----- --Sig_/6s0YyF6enlE+L7gWMFRqenY-- From owner-freebsd-current@freebsd.org Fri Mar 24 17:07:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1ACBAD1B5BF for ; Fri, 24 Mar 2017 17:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE93315F0 for ; Fri, 24 Mar 2017 17:07:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id w124so14470910itb.1 for ; Fri, 24 Mar 2017 10:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OmZB4ATQmdPNa63M0FQy4DFZL+Nw7o2CeR//0LqF8uU=; b=XbX4pWO67usMh4+ZvwP1lsMSvqF2FFRnZRoNjd2ND6WFht8JxKuFtIdMAkpJ2DZjeU CJpsDAZPAFgoqLKH4kxw3BfqJnLFwv5KswlcDtiv+I6RbJ1MDjHX6XYkr68yCrWb0V+1 ZjuYaUzrgmxlO7Q62YxcaTOECiA80vO2pY3ChZsVAnekmO18mYv+Kvmq3zomHy3bkd8m ymwS7AKbPvcR5fRjL7X0DuV952ovwoviTTaPX542cw2lj5d2E/uOkCyILaOFbrSOwr/u iKxCIYQiqDuHXA4geKBT1aibKZsu08ulDlWHZzPNSFOaprZWDt/0OdUXU2HgCVLkUBOo +mhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OmZB4ATQmdPNa63M0FQy4DFZL+Nw7o2CeR//0LqF8uU=; b=MVCedr10ocApCx6M+0U01VsUB7nUBO/20DNnLYxA4w12VcsJDUglQn+zeYKZz3pxjf A52g1XNEsLgZvkwqnmJEut/R65NAbXd7tNwbo3+hqMHb9yGqso4/YKGZHPb1KCJ0o8zQ tYZ/2m7B0klI+IDJkTk/vuMz2S+lDyEHeMxfpxi+BuB6ymaNOVnW1wgUNydQUxU/CHTU 1LDsSzoxYuOmvi+pfpAkvTWgBVzRtfmsMqkPBzsEib2SDe9mxJQpX5X+NL7zlM4a80a2 6ze3qwacvIg2oNdDZsaGJIy5iNZcMg7s/kI23d0DgjRhGWLYxxa+3ky9qBPEf40He3Jg rJUw== X-Gm-Message-State: AFeK/H06Xuot1bbeZae1wh07tSX11H7IsMnwOqgvGc3ic8iHf+xU4JDrNqH9a5Ih/HyP586IjAOZCQ3+1Qc5fw== X-Received: by 10.107.174.220 with SMTP id n89mr9977543ioo.166.1490375226944; Fri, 24 Mar 2017 10:07:06 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Fri, 24 Mar 2017 10:07:06 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::375c] In-Reply-To: <20170324165301.l2mbhv3db2qjmpmx@vzakharov> References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> <20170324152045.yi7fgt5aeijkfrl7@vein> <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> <20170324165301.l2mbhv3db2qjmpmx@vzakharov> From: Warner Losh Date: Fri, 24 Mar 2017 11:07:06 -0600 X-Google-Sender-Auth: ky4yZPtu4gozfOjrSz_HPOhy3OU Message-ID: Subject: Re: dchlient does not autostart anymore? To: Vladimir Zakharov Cc: Jung-uk Kim , Kirill Ponomarev , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 17:07:08 -0000 On Fri, Mar 24, 2017 at 10:53 AM, Vladimir Zakharov wrote: > On Fri, Mar 24, 2017, Jung-uk Kim wrote: >> On 03/24/2017 11:20, Kirill Ponomarev wrote: >> > On 03/24, Vladimir Zakharov wrote: >> >> Hello! >> >> >> >> After upgrading from r315544 to r315880 network interface doesn't get IP >> >> address using DHCP on boot anymore. >> >> >> >> $ grep re0 /etc/rc.conf | grep -v "^#" >> >> ifconfig_re0="DHCP" >> >> >> >> "service netif restart" doesn't help either. Only manual dhclient >> >> starting. >> > >> > Same issues here with today CURRENT, r315896. >> >> FYI, r315901 fixed the issue for me. > > For me too. Thanks. Yea, sorry about the brief breakage... I didn't notice until after I'd committed Ian's much improved version there'd been a problem. Stupid mistake on my part committing out of the wrong tree for the change that caused problems. Warner From owner-freebsd-current@freebsd.org Fri Mar 24 17:42:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC81D1B5AF for ; Fri, 24 Mar 2017 17:42:20 +0000 (UTC) (envelope-from darren780@yahoo.com) Received: from nm15-vm3.bullet.mail.ne1.yahoo.com (nm15-vm3.bullet.mail.ne1.yahoo.com [98.138.91.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D499FFB4 for ; Fri, 24 Mar 2017 17:42:19 +0000 (UTC) (envelope-from darren780@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1490377527; bh=eOQ/40qf3oISNJyvcCoW6/LmhwzVzm0Ke++qYMkuRCU=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=qAOOVbQZj1zZRgcTIJuk96n9yn92yKEQdpJn1wXrfDWirz1uChpiiAIovjn+e6/aWO/s8iZGMJrBN7uXnkmaq0SSPLZHLiahStQc2NXEizfJshlXXIOvoDtjcPBMx/BG6NE20nrCTUutQdDUuzyQGCSrzkb5Vu7/J+86rkypomE+TgPKMBoQIEJpzGiO7O57ormDKLmlDHI+J/4rT6Jkohz5YMymcuUSPp5a5PUYILVwsBIjYaQh7dWZVT6E+/pdMJR/zvVN4aGwEERSWUfLO3x1ekKCHIVSLR0BmbeXBYw/kErkpmWB1yoxIHUyh2vbsZkeyx20zY0Z5bQ9tcMxnQ== Received: from [98.138.100.112] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 17:45:27 -0000 Received: from [98.138.89.249] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 17:40:37 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 24 Mar 2017 17:40:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 37104.88615.bm@omp1041.mail.ne1.yahoo.com X-YMail-OSG: kuDtY2oVM1m_Dn_mrZXuUuDy90X1JR874BVnT1hwPq8r.JQsOmmgJMoNaURShJC 80iEhY7Z7sII7mu.texoqkmg_hp0cSCqstnom.KWo9tD00qbjPhVlFjvu_WlMzMyhj4ytGfnfpad y6vLDFtSDS9WlWwIrxogztO982PVjPBx5RyztQSd_LalP.3zc80jz3i6W8l4jXZOKg.4P6In0s8C tGjug8dl5s6XTj4IJUuPdgslDMd0AFiBb4ngcneo05MNL6GB6tzUsgArYHkM.v4rlyzwwNgC_M1a dve.UFSkBO0gjEXyMoMSp_p5cixpPlQ79dhf6XRSixBeO7hVT5bSQEA_qOT3KcPZujCSVZ70migF 35kdAgGPNcpneGlKHSj.gdEgN3LklqW2xdP1CiHOLLDCbu_GgWimComMv6sPXtr7fRh0FXm3SVmW fTW813AM1c1V0EYkdWZmp7N2cxiSpEATWxyHoHSGppHckf1B5Yn4Um7lJsRZ_P.LoAOcexdbDqOs Sb0PUFvBKOtUHXvFLm0g- Received: from jws200059.mail.ne1.yahoo.com by sendmailws118.mail.ne1.yahoo.com; Fri, 24 Mar 2017 17:40:36 +0000; 1490377236.570 Date: Fri, 24 Mar 2017 17:40:15 +0000 (UTC) From: Darren Reply-To: Darren To: "freebsd-current@freebsd.org" Message-ID: <1824572972.3096988.1490377215756@mail.yahoo.com> Subject: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited MIME-Version: 1.0 References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 17:42:20 -0000 I am getting this panic every hour to every couple of hours. FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:= 56:45 EDT 2017=C2=A0=C2=A0=C2=A0=C2=A0 darren@asrock:/usr/obj/usr/src/sys/G= ENERIC=C2=A0 amd64 I manually typed out the following, apologize for any typos.=20 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f087= 3c with sleeping prohibited cpuid =3D 0 time =3D 1490372797 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33= 690 vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 soclose() at soclose+0xda/frame 0xfffffe0072e338b0 _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_d= one_async+037/frame 0xfffffe0072e33930 bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xf= ffffe0072e33b60 ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic [ thread pid 12 tid 100038 ] Stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kdb_enter+0x3b: movq=C2=A0=C2=A0= =C2=A0 $0,kdb_why db> From owner-freebsd-current@freebsd.org Fri Mar 24 17:55:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03EDAD1B087 for ; Fri, 24 Mar 2017 17:55:53 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB9FE174 for ; Fri, 24 Mar 2017 17:55:52 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1crTR9-0004hc-TG; Fri, 24 Mar 2017 18:55:44 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1crTR9-0005vU-QS; Fri, 24 Mar 2017 18:55:43 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Fri, 24 Mar 2017 17:55:43 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "Darren" CC: "freebsd-current@freebsd.org" Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited Date: Fri, 24 Mar 2017 10:55:43 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <1824572972.3096988.1490377215756@mail.yahoo.com> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 17:55:53 -0000 On Fri, 24 Mar 2017 17:40:15 +0000 (UTC), Darren wrot= e: > I am getting this panic every hour to every couple of hours. >=20 > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 1= 4:56:45 EDT 2017=C2=A0=C2=A0=C2=A0=C2=A0 darren@asrock:/usr/obj/usr/src/sys= /GENERIC=C2=A0 amd64 > I manually typed out the following, apologize for any typos.=20 >=20 >=20 > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0= 873c with sleeping prohibited > cpuid =3D 0 > time =3D 1490372797 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e= 33690 > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages= _done_async+037/frame 0xfffffe0072e33930 > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0= xfffffe0072e33b60 > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic > [ thread pid 12 tid 100038 ] > Stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kdb_enter+0x3b: movq=C2=A0=C2=A0= =C2=A0 $0,kdb_why > db> >=20 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Will there ever be an auto-save to .txt upon break to debugger or lock reversal or similar in code? or is beyond the capability of the OS once the occurance has taken place, I wonder.=20= From owner-freebsd-current@freebsd.org Fri Mar 24 20:10:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 163EFD1C9C1; Fri, 24 Mar 2017 20:10:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660068.outbound.protection.outlook.com [40.107.66.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB1A81957; Fri, 24 Mar 2017 20:10:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Fri, 24 Mar 2017 20:10:03 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.021; Fri, 24 Mar 2017 20:10:03 +0000 From: Rick Macklem To: Larry Rosenman , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Subject: Re: crash: umount_nfs: Current Thread-Topic: crash: umount_nfs: Current Thread-Index: AQHSnf9DKC+Zb1AjDkCvB/ns2F6CGqGYEmLZgAAQyoCACZXXAIACb+VdgABQFVM= Date: Fri, 24 Mar 2017 20:10:03 +0000 Message-ID: References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> <1AEC680C-BFE4-4B07-816E-3DEF1B6D266C@lerctr.org>, <6FB99978-BCFC-4E84-9F1C-E312D4BFC747@lerctr.org> In-Reply-To: <6FB99978-BCFC-4E84-9F1C-E312D4BFC747@lerctr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lerctr.org; dkim=none (message not signed) header.d=none;lerctr.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:b+9KmJpTaTpznW4NKPVhSsADyDXMrJjz8o+3jXf9+f/pXJNAKYEuGu6GmWp6WP9hmxEuxeOZr0y7PMjcH0pzIKJDoPpE0VL9rtlCFqVk7hXwLzGBOBUfUz3wbZWR5lyooj4gOBeHt3guGvG+Cn9lyGG+OmPNRi+XZnNctw67WGlsW5jrCq5KYbpNyp0psc+Yyw0YmaNmwr96oAH2RYIlDXDgkykI9zBYiG7sPjuaMSDgvK4+tnuVf48EyAr0IU6aARByElr+bN7V0o/NEE+GfqDBNskvjHo3xD+ymwNW68ATvg34GIoZrmZdVonfc2N93sdFXX10JJ3RrzHbigd3jg== x-ms-office365-filtering-correlation-id: 61543fb6-ec03-467a-2022-08d472f1c211 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(75325880899374)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(252514010)(43784003)(377454003)(8936002)(81166006)(8676002)(93886004)(102836003)(33656002)(86362001)(122556002)(7696004)(54356999)(189998001)(74316002)(76176999)(50986999)(2900100001)(6506006)(6436002)(38730400002)(53936002)(77096006)(6246003)(305945005)(3280700002)(966004)(229853002)(74482002)(2501003)(2906002)(5660300001)(55016002)(3660700001)(53546009)(2950100002)(6306002)(25786009)(4326008)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 20:10:03.2067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 20:10:07 -0000 Ok, thanks for testing it. Unless I hear of problems with the patch, I'll c= ommit it to head in mid-April. Thanks again for reporting this and doing the testing, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Larry Rosenman Sent: Friday, March 24, 2017 11:21:39 AM To: Rick Macklem; freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: crash: umount_nfs: Current I tried my test (umount =96t nfs =96a && mount =96t nfs =96a) and no crash.= (with ~84G inact cached NFS data). I suspect it helped. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Mar 24 20:14:48 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B817AD1CBFD for ; Fri, 24 Mar 2017 20:14:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670078.outbound.protection.outlook.com [40.107.67.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CE0C127; Fri, 24 Mar 2017 20:14:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Fri, 24 Mar 2017 20:14:46 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0977.021; Fri, 24 Mar 2017 20:14:45 +0000 From: Rick Macklem To: Konstantin Belousov CC: Gergely Czuczy , Dimitry Andric , Ian Lepore , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIAAClcAgAHrwICAA2WzgIAA/q43gACd2YCAAN05xg== Date: Fri, 24 Mar 2017 20:14:45 +0000 Message-ID: References: <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> <050751d5-8c4d-b257-7c83-3a9bfb38a86d@harmless.hu> , <20170324070141.GB43712@kib.kiev.ua> In-Reply-To: <20170324070141.GB43712@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:LcrzKH4Qed8COqghjazhhGvogJ46NYK4yO/F6op5w8SA3XFxmxtAMdtpsvmh5ZbrSDZHjZirTaW8O4TMkNfclSnTegsPp+YyaaIFhqnRa7lA7TgsHo+SOt3IGBLmmU2CCwONm4fiwMRnkf19D9lgWWH8VG6VXzY0tSimXcZ1gJaLK5Tcs5vxGA88Ci0taTGWjNUsp+3/SrsFTo0sH1m56EX7sMQsgv5+i3sjOlFozEEgoQXV0IZkqW30AlElPY7CXonfql5rI7dP/slUMwo2lX5ACrv/2iK7gCKwZv6ofzh10euAyYGS3CtbFSVs3emaeLRIjYLWCv5TgUi6/w+ZJg== x-ms-office365-filtering-correlation-id: ba5a914e-b24d-463b-ae7c-08d472f26a74 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(55674003)(377454003)(40764003)(24454002)(74316002)(81166006)(76176999)(5660300001)(305945005)(54356999)(7696004)(8676002)(229853002)(122556002)(6916009)(50986999)(2900100001)(2950100002)(33656002)(4326008)(38730400002)(8936002)(1411001)(39060400002)(6246003)(2906002)(189998001)(110136004)(6506006)(55016002)(6306002)(6436002)(77096006)(86362001)(54906002)(9686003)(3660700001)(53936002)(74482002)(102836003)(93886004)(25786009)(53546009)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 20:14:45.8785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 24 Mar 2017 20:14:48 -0000 I can't do commits until I get home in mid-April. That's why it will be waiting until then. It should make it into stable/11 in plenty of time for 11.1. Thanks for your help with this, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov Sent: Friday, March 24, 2017 3:01:41 AM To: Rick Macklem Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current Subject: Re: process killed: text file modification On Thu, Mar 23, 2017 at 09:39:00PM +0000, Rick Macklem wrote: > Try whatever you like. However, if the case that failed before doesn't fa= il now, > I'd call the test a success. > > Thanks, rick > ps: It looks like Kostik is going to work on converting the NFS vop_putpa= ges() to > using the buffer cache. However, if this isn't ready for head/curre= nt by mid-April, > I will commit this patch to help fix things in the meantime. I do not see a reason to wait for my work before committing your patch. IMO, instead, it should be committed ASAP and merged into stable/11 for upcoming 11.1. I will do required adjustments if/when _putpages() patch progresses enough. _______________________________________________ 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 Sat Mar 25 01:03:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74397D1B409 for ; Sat, 25 Mar 2017 01:03:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 042201A45; Sat, 25 Mar 2017 01:03:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2P13EpW055921 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Mar 2017 03:03:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2P13EpW055921 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2P13Epm055920; Sat, 25 Mar 2017 03:03:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Mar 2017 03:03:14 +0200 From: Konstantin Belousov To: Darren Cc: "freebsd-current@freebsd.org" , glebius@freebsd.org Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited Message-ID: <20170325010314.GG43712@kib.kiev.ua> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1824572972.3096988.1490377215756@mail.yahoo.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 01:03:21 -0000 On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: > I am getting this panic every hour to every couple of hours. > > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:56:45 EDT 2017šššš darren@asrock:/usr/obj/usr/src/sys/GENERICš amd64 > I manually typed out the following, apologize for any typos. > > > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited > cpuid = 0 > time = 1490372797 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33690 > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_done_async+037/frame 0xfffffe0072e33930 > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xfffffe0072e33b60 > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 12 tid 100038 ] > Stopped atššššš kdb_enter+0x3b: movqššš $0,kdb_why > db> Indeed, the context where sendfile_iodone() is executed, cannot call fdrop(). From owner-freebsd-current@freebsd.org Sat Mar 25 03:31:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A745FD1B4EF for ; Sat, 25 Mar 2017 03:31:49 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 904F3861 for ; Sat, 25 Mar 2017 03:31:48 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v2P3Vg0j096258 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Mar 2017 20:31:42 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v2P3Vg5X096257; Fri, 24 Mar 2017 20:31:42 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 24 Mar 2017 20:31:42 -0700 From: Gleb Smirnoff To: Darren Cc: Konstantin Belousov , "freebsd-current@freebsd.org" Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited Message-ID: <20170325033142.GA23308@FreeBSD.org> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> <20170325010314.GG43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ibvzjYYg+QDzMCy1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170325010314.GG43712@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 03:31:49 -0000 --ibvzjYYg+QDzMCy1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Darren, On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: K> > I am getting this panic every hour to every couple of hours. K> > K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:56:45 EDT 2017     darren@asrock:/usr/obj/usr/src/sys/GENERIC  amd64 K> > I manually typed out the following, apologize for any typos. K> > K> > K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited K> > cpuid = 0 K> > time = 1490372797 K> > KDB: stack backtrace: K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33690 K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_done_async+037/frame 0xfffffe0072e33930 K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xfffffe0072e33b60 K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 K> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- K> > KDB: enter: panic K> > [ thread pid 12 tid 100038 ] K> > Stopped at      kdb_enter+0x3b: movq    $0,kdb_why K> > db> K> K> Indeed, the context where sendfile_iodone() is executed, cannot call fdrop(). Can you please test the attached patch? -- Totus tuus, Glebius. --ibvzjYYg+QDzMCy1 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sendfile_sleep.diff" Index: sys/kern/kern_sendfile.c =================================================================== --- sys/kern/kern_sendfile.c (revision 315926) +++ sys/kern/kern_sendfile.c (working copy) @@ -296,8 +296,9 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun CURVNET_RESTORE(); } - /* XXXGL: curthread */ - fdrop(sfio->sock_fp, curthread); + ACCEPT_LOCK(); + SOCK_LOCK(so); + sorele(so); free(sfio, M_TEMP); } @@ -860,7 +861,9 @@ prepend_header: } else { sfio->sock_fp = sock_fp; sfio->npages = npages; - fhold(sock_fp); + SOCK_LOCK(so); + soref(so); + SOCK_UNLOCK(so); error = (*so->so_proto->pr_usrreqs->pru_send) (so, PRUS_NOTREADY, m, NULL, NULL, td); sendfile_iodone(sfio, NULL, 0, 0); --ibvzjYYg+QDzMCy1-- From owner-freebsd-current@freebsd.org Sat Mar 25 09:45:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 635EFD1B60F for ; Sat, 25 Mar 2017 09:45:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9A521CEA; Sat, 25 Mar 2017 09:45:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2P9jTYK078913 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Mar 2017 11:45:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2P9jTYK078913 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2P9jTn0078912; Sat, 25 Mar 2017 11:45:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Mar 2017 11:45:29 +0200 From: Konstantin Belousov To: Gleb Smirnoff Cc: Darren , "freebsd-current@freebsd.org" Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited Message-ID: <20170325094529.GH43712@kib.kiev.ua> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> <20170325010314.GG43712@kib.kiev.ua> <20170325033142.GA23308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170325033142.GA23308@FreeBSD.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 09:45:40 -0000 On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote: > Darren, > > On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: > K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: > K> > I am getting this panic every hour to every couple of hours. > K> > > K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:56:45 EDT 2017šššš darren@asrock:/usr/obj/usr/src/sys/GENERICš amd64 > K> > I manually typed out the following, apologize for any typos. > K> > > K> > > K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited > K> > cpuid = 0 > K> > time = 1490372797 > K> > KDB: stack backtrace: > K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33690 > K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 > K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 > K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 > K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 > K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 > K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 > K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 > K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_done_async+037/frame 0xfffffe0072e33930 > K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 > K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 > K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 > K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 > K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 > K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xfffffe0072e33b60 > K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 > K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 > K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 > K> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > K> > KDB: enter: panic > K> > [ thread pid 12 tid 100038 ] > K> > Stopped atššššš kdb_enter+0x3b: movqššš $0,kdb_why > K> > db> > K> > K> Indeed, the context where sendfile_iodone() is executed, cannot call fdrop(). > > Can you please test the attached patch? > > -- > Totus tuus, Glebius. > Index: sys/kern/kern_sendfile.c > =================================================================== > --- sys/kern/kern_sendfile.c (revision 315926) > +++ sys/kern/kern_sendfile.c (working copy) > @@ -296,8 +296,9 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun > CURVNET_RESTORE(); > } > > - /* XXXGL: curthread */ > - fdrop(sfio->sock_fp, curthread); > + ACCEPT_LOCK(); > + SOCK_LOCK(so); > + sorele(so); > free(sfio, M_TEMP); > } > > @@ -860,7 +861,9 @@ prepend_header: > } else { > sfio->sock_fp = sock_fp; > sfio->npages = npages; > - fhold(sock_fp); > + SOCK_LOCK(so); > + soref(so); > + SOCK_UNLOCK(so); > error = (*so->so_proto->pr_usrreqs->pru_send) > (so, PRUS_NOTREADY, m, NULL, NULL, td); > sendfile_iodone(sfio, NULL, 0, 0); With this patch, what prevents a close of the sfio->sock_fp file, which is needed to get the pointer to socket ? From owner-freebsd-current@freebsd.org Sat Mar 25 13:00:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB4B0D1BCD8 for ; Sat, 25 Mar 2017 13:00:26 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B7D5B1EEC for ; Sat, 25 Mar 2017 13:00:26 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id B465FD1BCD7; Sat, 25 Mar 2017 13:00:26 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4148D1BCD6 for ; Sat, 25 Mar 2017 13:00:26 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE3A1EEB for ; Sat, 25 Mar 2017 13:00:26 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1crlIt-000896-79 for current@freebsd.org; Sat, 25 Mar 2017 14:00:23 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1crlIt-00051B-3l for current@freebsd.org; Sat, 25 Mar 2017 14:00:23 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Sat, 25 Mar 2017 13:00:22 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: lock order reversal another, repeatable... Date: Sat, 25 Mar 2017 06:00:22 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 13:00:26 -0000 Mar 24 14:25:16 kernel: lock order reversal: Mar 24 14:25:16 kernel: 1st 0xc09cf6dc ufs (ufs) @ /usr/src/sys/kern/vfs_m= ount.c:1277 Mar 24 14:25:16 kernel: 2nd 0xc0100a30 devfs (devfs) @ /usr/src/sys/ufs/ff= s/ffs_softdep.c:1908 Mar 24 14:25:16 kernel: stack backtrace: Mar 24 14:25:16 kernel: #0 0xb5c22421 at witness_debugger+0x81 Mar 24 14:25:16 kernel: #1 0xb5c22342 at witness_checkorder+0xd12 Mar 24 14:25:16 kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 Mar 24 14:25:16 kernel: #3 0xb5c784ad at vop_stdlock+0x4d Mar 24 14:25:16 kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 Mar 24 14:25:16 kernel: #5 0xb5c9c137 at _vn_lock+0xb7 Mar 24 14:25:16 kernel: #6 0xb5e9d648 at softdep_flushworklist+0x68 Mar 24 14:25:16 kernel: #7 0xb5ebc892 at ffs_sync+0x2b2 Mar 24 14:25:16 kernel: #8 0xb5c82955 at dounmount+0x6c5 Mar 24 14:25:16 kernel: #9 0xb5c82185 at sys_unmount+0x315 Mar 24 14:25:16 kernel: #10 0xb6155fa5 at syscall+0x3b5 Mar 24 14:25:16 kernel: #11 0xb6140ede at Xint0x80_syscall+0x2e umounting a sata filesystem, the above. Useful? aside: twice recently dropped to debugger upon shutdown. kb> [ or whatever ] any useful commands here? I thought 'st' but have not read about a procedure... That occured upon umount of a 2nd sata disk's filesystem(s). On a second note, From owner-freebsd-current@freebsd.org Sat Mar 25 18:03:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F53BD1D4AC; Sat, 25 Mar 2017 18:03:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 45E8210E1; Sat, 25 Mar 2017 18:03:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA09165; Sat, 25 Mar 2017 20:03:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1crq1r-000EY8-Dg; Sat, 25 Mar 2017 20:03:07 +0200 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org From: Andriy Gapon Subject: Opteron 6100-series "Magny-Cours" Message-ID: Date: Sat, 25 Mar 2017 20:02:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 18:03:17 -0000 Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat Mar 25 18:55:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C154DD1D5A8 for ; Sat, 25 Mar 2017 18:55:54 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from mail.mands.hu (mail2.mands.hu [93.189.114.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5136C1BDE; Sat, 25 Mar 2017 18:55:53 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from MSEXCH13.mands.hu (192.168.4.5) by exchange.mands.hu (192.168.4.6) with Microsoft SMTP Server (TLS) id 8.3.485.1; Sat, 25 Mar 2017 19:55:45 +0100 Received: from MSEXCH13.mands.hu (192.168.4.5) by MSEXCH13.mands.hu (192.168.4.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 25 Mar 2017 19:55:44 +0100 Received: from MSEXCH13.mands.hu ([::1]) by MSEXCH13.mands.hu ([::1]) with mapi id 15.00.1263.000; Sat, 25 Mar 2017 19:55:44 +0100 From: =?iso-8859-2?Q?M=26S_-_Krasznai_Andr=E1s?= To: Warner Losh , Vladimir Zakharov CC: Jung-uk Kim , Kirill Ponomarev , "FreeBSD Current" Subject: RE: dchlient does not autostart anymore? Thread-Topic: dchlient does not autostart anymore? Thread-Index: AQHSpHeSfdFRKCGt/E+6p4gjboBhtKGkCreAgAAHdoCAABJSgIAAA+8AgAG+ZzA= Date: Sat, 25 Mar 2017 18:55:44 +0000 Message-ID: <1eddf72b2a984992a09a17bb684824cc@MSEXCH13.mands.hu> References: <20170324082031.agbmfaqa6hxhoqoy@vzakharov> <20170324152045.yi7fgt5aeijkfrl7@vein> <9bf02d14-c1fe-7647-2467-b7679165240c@FreeBSD.org> <20170324165301.l2mbhv3db2qjmpmx@vzakharov> In-Reply-To: Accept-Language: en-US, hu-HU Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.4.23] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 18:55:54 -0000 Hi I am on r315901 and still have the problem. =20 I am using an aggregate interface lagg0 created from my Ethernet adapter an= d my WiFi; I use this configuration since a few months without any change a= nd without problems. dhclient still does not start automatically for lagg0 = since Thursday morning update. Of course I can start dhclient manually after logging in, and get IP addres= s. best regards Andr=E1s Krasznai - ----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freeb= sd.org] On Behalf Of Warner Losh Sent: Friday, March 24, 2017 6:07 PM To: Vladimir Zakharov Cc: Jung-uk Kim; Kirill Ponomarev; FreeBSD Current Subject: Re: dchlient does not autostart anymore? On Fri, Mar 24, 2017 at 10:53 AM, Vladimir Zakharov = wrote: > On Fri, Mar 24, 2017, Jung-uk Kim wrote: >> On 03/24/2017 11:20, Kirill Ponomarev wrote: >> > On 03/24, Vladimir Zakharov wrote: >> >> Hello! >> >> >> >> After upgrading from r315544 to r315880 network interface doesn't=20 >> >> get IP address using DHCP on boot anymore. >> >> >> >> $ grep re0 /etc/rc.conf | grep -v "^#" >> >> ifconfig_re0=3D"DHCP" >> >> >> >> "service netif restart" doesn't help either. Only manual dhclient=20 >> >> starting. >> > >> > Same issues here with today CURRENT, r315896. >> >> FYI, r315901 fixed the issue for me. > > For me too. Thanks. Yea, sorry about the brief breakage... I didn't notice until after I'd comm= itted Ian's much improved version there'd been a problem. Stupid mistake on= my part committing out of the wrong tree for the change that caused proble= ms. Warner _______________________________________________ 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 Sat Mar 25 20:24:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 004B8D1DCF2 for ; Sat, 25 Mar 2017 20:24:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E04361751 for ; Sat, 25 Mar 2017 20:24:14 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id DF971D1DCEE; Sat, 25 Mar 2017 20:24:14 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF338D1DCED for ; Sat, 25 Mar 2017 20:24:14 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 861EA1750 for ; Sat, 25 Mar 2017 20:24:14 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1crsEI-0003TY-AN for current@freebsd.org; Sat, 25 Mar 2017 21:24:06 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1crsEI-0005jL-81 for current@freebsd.org; Sat, 25 Mar 2017 21:24:06 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Sat, 25 Mar 2017 20:24:06 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: bt full - included... kgdb 'script' output vmcore.8 Date: Sat, 25 Mar 2017 13:24:06 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 20:24:15 -0000 I asked the var to bt full it laid the symbols down I asked it current, list, the cymbals. not newly newbie, clown And xclip pasted, below, the rhyme the symbollish list stuff And I send it off to list-wise men to make Xorg not so gruff. ........................................... ........................................... Script started on Sat Mar 25 13:11:34 2017 Command: kgdb7121 /boot/test/kernel /var/crash/VMCORE.8 GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/test/kernel...Reading symbols from /usr/lib/debu= g//boot/test/kernel.debug...done. done. Unread portion of the kernel message buffer: Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `bufdaemon' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop...=20 Syncing disks, vnodes remaining... 5 1 0 0 done All buffers synced. lock order reversal: 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 2nd 0xbfb90150 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762 stack backtrace: #0 0xb5c22421 at witness_debugger+0x81 #1 0xb5c22342 at witness_checkorder+0xd12 #2 0xb5b9b5d4 at __lockmgr_args+0xa64 #3 0xb5c784ad at vop_stdlock+0x4d #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 #5 0xb5c9c137 at _vn_lock+0xb7 #6 0xb5c8b00a at vputx+0x16a #7 0xb5c8286c at dounmount+0x5dc #8 0xb5c8c8e8 at vfs_unmountall+0x68 #9 0xb5c68333 at bufshutdown+0x3f3 #10 0xb5bbfca7 at kern_reboot+0x1b7 #11 0xb5bbfa88 at sys_reboot+0x3e8 #12 0xb6155fa5 at syscall+0x3b5 #13 0xb6140ede at Xint0x80_syscall+0x2e lock order reversal: 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 2nd 0xbfa28034 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1404 stack backtrace: #0 0xb5c22421 at witness_debugger+0x81 #1 0xb5c22342 at witness_checkorder+0xd12 #2 0xb5b9b5d4 at __lockmgr_args+0xa64 #3 0xb5c784ad at vop_stdlock+0x4d #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 #5 0xb5c9c137 at _vn_lock+0xb7 #6 0xb5eb9617 at ffs_flushfiles+0x157 #7 0xb5e9d9aa at softdep_flushfiles+0x17a #8 0xb5ebc04c at ffs_unmount+0x7c #9 0xb5c8299b at dounmount+0x70b #10 0xb5c8c8e8 at vfs_unmountall+0x68 #11 0xb5c68333 at bufshutdown+0x3f3 #12 0xb5bbfca7 at kern_reboot+0x1b7 #13 0xb5bbfa88 at sys_reboot+0x3e8 #14 0xb6155fa5 at syscall+0x3b5 #15 0xb6140ede at Xint0x80_syscall+0x2e lock order reversal: 1st 0xbf69ab4c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 2nd 0xb6b6f8b0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:3104 stack backtrace: #0 0xb5c22421 at witness_debugger+0x81 #1 0xb5c22342 at witness_checkorder+0xd12 #2 0xb5bc976a at _sx_slock+0x5a #3 0xb5b743f1 at mountcheckdirs+0x41 #4 0xb5c828ea at dounmount+0x65a #5 0xb5c8c93b at vfs_unmountall+0xbb #6 0xb5c68333 at bufshutdown+0x3f3 #7 0xb5bbfca7 at kern_reboot+0x1b7 #8 0xb5bbfa88 at sys_reboot+0x3e8 #9 0xb6155fa5 at syscall+0x3b5 #10 0xb6140ede at Xint0x80_syscall+0x2e Uptime: 3h49m18s GEOM_SCHED: Modevent 2. uhub11: detached uhub9: detached uhub10: detached ums0: detached <5>ue0: link state changed to DOWN <5>Accounting disabled panic: vm_fault: fault on nofault entry, addr: deadc000 cpuid =3D 2 KDB: stack backtrace: db_trace_self_wrapper(b632dee0,b65ec9b0,0,b63057cc,20c,...) at db_trace_sel= f_wrapper+0x2a/frame 0xeaa10428 kdb_backtrace(b653d063,2,b6378ae5,eaa104e4,fb,...) at kdb_backtrace+0x2d/fr= ame 0xeaa10490 vpanic(b6378ae5,eaa104e4,eaa104e4,eaa105c0,b5edffb1,...) at vpanic+0x115/fr= ame 0xeaa104c4 panic(b6378ae5,deadc000,1,eaa1052c,eaa1051c,...) at panic+0x1b/frame 0xeaa1= 04d8 vm_fault_hold(b8172000,deadc000,1,0,0,...) at vm_fault_hold+0x2051/frame 0x= eaa105c0 vm_fault(b8172000,deadc000,1,0,c2d0bfa8,...) at vm_fault+0x88/frame 0xeaa10= 5e8 trap_pfault(deadc348,b6ae70ec,b6600504,bdda8d00,b6ae70f0,...) at trap_pfaul= t+0x116/frame 0xeaa10630 trap(eaa10778) at trap+0x2d6/frame 0xeaa1076c calltrap() at calltrap+0x6/frame 0xeaa1076c --- trap 0xc, eip =3D 0xb5bbaf19, esp =3D 0xeaa107b8, ebp =3D 0xeaa10828 --- __rw_wlock_hard(c2d42ab4,deadc0de,be269000,b63585e2,139,...) at __rw_wlock_= hard+0xe9/frame 0xeaa10828 _rw_wlock_cookie(c2d42ab4,b63585e2,139,136,0,...) at _rw_wlock_cookie+0xd8/= frame 0xeaa10858 ip_output(c3acf400,0,0,0,0,...) at ip_output+0x4aa/frame 0xeaa10934 check_dyn_rules(1,1,b632a786,eaa109c8,b5bce8a2,...) at check_dyn_rules+0x6a= 8/frame 0xeaa10994 ipfw_dyn_tick(0,0,b632a786,2b1,eaa10a00,...) at ipfw_dyn_tick+0x55/frame 0x= eaa109c8 softclock_call_cc(0,0,b632a786,360,0,...) at softclock_call_cc+0x17c/frame = 0xeaa10a68 softclock(b6b6fa80,9,0,560,be2d4048,...) at softclock+0x40/frame 0xeaa10a88 intr_event_execute_handlers(b6aa7e10,be2d4000,b6320f1d,560,b6320b58,...) at= intr_event_execute_handlers+0x8e/frame 0xeaa10ab0 ithread_loop(be2d7000,eaa10b28,b6320b58,406,0,...) at ithread_loop+0x90/fra= me 0xeaa10aec fork_exit(b5b8a3c0,be2d7000,eaa10b28) at fork_exit+0x7e/frame 0xeaa10b14 fork_trampoline() at fork_trampoline+0x8/frame 0xeaa10b14 --- trap 0, eip =3D 0, esp =3D 0xeaa10b60, ebp =3D 0 --- KDB: enter: panic Reading symbols from /boot/test/geom_journal.ko...Reading symbols from /usr= /lib/debug//boot/test/geom_journal.ko.debug...done. done. Reading symbols from /boot/test/geom_label.ko...Reading symbols from /usr/l= ib/debug//boot/test/geom_label.ko.debug...done. done. Reading symbols from /boot/modules/nvidia-modeset.ko...(no debugging symbol= s found)...done. Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols found)= ...done. Reading symbols from /boot/test/ehci.ko...Reading symbols from /usr/lib/deb= ug//boot/test/ehci.ko.debug...done. done. Reading symbols from /boot/test/geom_sched.ko...Reading symbols from /usr/l= ib/debug//boot/test/geom_sched.ko.debug...done. done. Reading symbols from /boot/test/gsched_rr.ko...Reading symbols from /usr/li= b/debug//boot/test/gsched_rr.ko.debug...done. done. Reading symbols from /boot/test/pf.ko...Reading symbols from /usr/lib/debug= //boot/test/pf.ko.debug...done. done. Reading symbols from /boot/test/snd_csa.ko...Reading symbols from /usr/lib/= debug//boot/test/snd_csa.ko.debug...done. done. __curthread () at ./machine/pcpu.h:225 225 __asm("movl %%fs:%1,%0" : "=3Dr" (td) (kgdb) bt full #0 __curthread () at ./machine/pcpu.h:225 td =3D #1 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:318 error =3D coredump =3D #2 0xb555a40e in db_dump (dummy=3D-1245695404,=20 dummy2=3D,=20 dummy3=3D-1, dummy4=3D0xeaa101d4 "") at /usr/src/sys/ddb/db_command.c:5= 46 error =3D #3 0xb555a1fa in db_command (last_cmdp=3D, cmd_table=3D, dopager=3D) at /usr/src/sys/ddb/db_command.c:453 modif =3D "\000\263\261\266\000\000\000\000\004\312^\266\000\060A\2= 76\f\002\241\352]\240\212\211\270Fe\266\377\377\377\377\377\377\377\377,\00= 2\241\352\061\317U\265\177o8\266@\317U\265\030\002\241\352\020\000\000\000\= 070\002\241\352\070\002\241\352,\002\241\352@\201\266\265\000\000\000\000\3= 77\377\377\377\270Fe\266L\002\241\352\321\300U\265\270Fe\266\034@e\266x\000= \000\000\000\000\000\000\210\002\241\352D\004\241\352" have_addr =3D t =3D result =3D cmd =3D 0xb6565df0 addr =3D count =3D #4 0xb5559f50 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 No locals. #5 0xb555cdfa in db_trap (type=3D, code=3D) = at /usr/src/sys/ddb/db_main.c:248 jb =3D {{_jb =3D {-358546364, -358546836, -358546752, 0, -358546808= , -1252668039, -1235852540, -358546768,=20 -1245614478, -1235301696, -358546752, -1246330736}}} watchpt =3D bkpt =3D prev_jb =3D 0x0 why =3D #6 0xb5c03997 in kdb_trap (type=3D, code=3D,= tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 be =3D intr =3D handled =3D #7 0xb615530f in trap (frame=3D) at /usr/src/sys/i386/i386/= trap.c:683 td =3D 0xbe269000 addr =3D ucode =3D i =3D p =3D 0xbe267354 type =3D eva =3D ---Type to continue, or q to quit--- regs =3D dr6 =3D #8 No locals. #9 0xb5c03254 in kdb_enter (why=3D0xb6328738 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:444 No locals. #10 0xb5bc03f2 in vpanic (fmt=3D, ap=3D) at /= usr/src/sys/kern/kern_shutdown.c:772 buf =3D "vm_fault: fault on nofault entry, addr: deadc000", '\000' = td =3D 0xbe269000 newpanic =3D bootopt =3D #11 0xb5bc042b in panic (fmt=3D0xb6378ae5 "vm_fault: fault on nofault entry= , addr: %lx") at /usr/src/sys/kern/kern_shutdown.c:710 ap =3D 0x80 #12 0xb5edffb1 in vm_fault_hold (map=3D, vaddr=3D, fault_type=3D,=20 fault_flags=3D, m_hold=3D) at /usr/src/sy= s/vm/vm_fault.c:531 hardfault =3D nera =3D faultcount =3D wired =3D prot =3D result =3D 0 next_object =3D alloc_req =3D era =3D behavior =3D fs =3D e_start =3D e_end =3D vp =3D locked =3D error =3D ahead =3D behind =3D rv =3D cluster_offset =3D is_first_object_locked =3D retry_prot =3D retry_object =3D #13 0xb5eddf28 in vm_fault (map=3D0xb8172000, vaddr=3D, faul= t_type=3D,=20 fault_flags=3D) at /usr/src/sys/vm/vm_fault.c:474 td =3D 0xbe269000 result =3D ---Type to continue, or q to quit--- #14 0xb61558c6 in trap_pfault (frame=3D0xeaa10778, usermode=3D, eva=3D) at /usr/src/sys/i386/i386/trap.c:868 rv =3D td =3D 0xbe269000 p =3D va =3D 128 map =3D #15 0xb6154d06 in trap (frame=3D) at /usr/src/sys/i386/i386/= trap.c:512 td =3D 0xbe269000 addr =3D ucode =3D i =3D p =3D 0xbe267354 type =3D 12 eva =3D regs =3D dr6 =3D #16 No locals. #17 __rw_wlock_hard (c=3D, v=3D, tid=3D, file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_rwlock.c:892 spintries =3D sleep_cnt =3D ts =3D owner =3D 0xdeadc0c0 i =3D x =3D #18 0xb5bbada8 in _rw_wlock_cookie (c=3D, file=3D, line=3D) at /usr/src/sys/kern/kern_rwlock.c:285 tid =3D 3190198272 v =3D 0 #19 0xb5d5303a in ip_output (m=3D, opt=3D, ro= =3D, flags=3D,=20 imo=3D, inp=3D) at /usr/src/sys/netinet/i= p_output.c:313 error =3D hlen =3D ip =3D ip_len =3D fibnum =3D rte =3D have_ia_ref =3D ifp =3D ia =3D isbroadcast =3D ---Type to continue, or q to quit--- gw =3D #20 0xb5e32028 in check_dyn_rules (chain=3D0xb6b75068 , rt=3D= ,=20 check_ka=3D, timer=3D) at /usr/src/sys/ne= tpfil/ipfw/ip_fw_dynamic.c:1522 parents =3D 0 expired_limits =3D 0 expired =3D 0 new_buckets =3D q_prev =3D q =3D expltailp =3D exptailp =3D q_next =3D i =3D exp_lhead =3D max_buckets =3D dyn_count =3D exp_head =3D m =3D m0 =3D mnext =3D 0xc01b8000 #21 0xb5e32a45 in ipfw_dyn_tick (vnetx=3D0x0) at /usr/src/sys/netpfil/ipfw/= ip_fw_dynamic.c:1224 check_ka =3D chain =3D #22 0xb5bd81bc in softclock_call_cc (c=3D, cc=3D, direct=3D) at /usr/src/sys/kern/kern_timeout.c:729 maxdt =3D 2146786227 lastfunc =3D 0xb5609ad0 c_lock =3D lock_status =3D c_arg =3D c_iflags =3D c_func =3D class =3D ts2 =3D new_func =3D new_arg =3D new_cpu =3D new_cc =3D flags =3D #23 0xb5bd86c0 in softclock (arg=3D) at /usr/src/sys/kern/ke= rn_timeout.c:867 c =3D 0x0 #24 0xb5b89e6e in intr_event_execute_handlers (p=3D0xb6aa7e10 , ie=3D) at /usr/src/sys/kern/kern_intr.c:1262 ---Type to continue, or q to quit--- ih =3D ihn =3D 0x0 #25 0xb5b8a450 in ithread_execute_handlers (ie=3D, p=3D) at /usr/src/sys/kern/kern_intr.c:1275 No locals. #26 ithread_loop (arg=3D) at /usr/src/sys/kern/kern_intr.c:1= 356 td =3D 0xbe269000 ie =3D wake =3D #27 0xb5b8767e in fork_exit (callout=3D0xb5b8a3c0 , arg=3D, frame=3D) at /usr/src/sys/kern/kern_fork.c:1038 td =3D 0xbe269000 p =3D 0xbe267354 dtd =3D #28 No locals. (kgdb) exit Undefined command: "exit". Try "help". (kgdb) quit Command exit status: 0 ...........................................................................= ...... Script done on Sat Mar 25 13:11:55 2017 1200020 12.0 current r313487 feb 13 2017 i386 [ not GENERIC but debugging re-adde= d ]=20 ...........................................................................= ... sorry for formatting, still working on 'fold' in the pipe, if applicable ........................................... thanks. ........................................... From owner-freebsd-current@freebsd.org Sat Mar 25 21:26:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BDA8D1D220; Sat, 25 Mar 2017 21:26:20 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1AD2BA5; Sat, 25 Mar 2017 21:26:19 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id 79so4089803pgf.0; Sat, 25 Mar 2017 14:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaWE4EDpA28ZtQETY/qlBsBW1LW9Arhz+Ird3rqoolI=; b=ZCPsNJKjw3EUoGF43c++gakpkv70h5WnIrTyW3Hm4VoDyIsXG9eO5AuM4rv8ZBzXOe wRT/bfx7zBtsJRUG4Po3Si6H+prj0QSkHRDJ6gDvegnnUjNkxN949r71SX4saFdE+Fay eREE8ulhWYKGsvG/bqGkXR4pUhX15oQFN78qlSWCc3b/mEqf2EftD8A25dzIk3hEaHLP 9qCzSk5NklxpC6J4muUqD9H+/gewL0wkw+tgsd9iV+HnaSYq+/2plBJYQQhDk7OvbXDz GSSRZ2DerEXubUkZI1qLhHtgyltJQ8rBkfm2jRn40MMyvtBURxggBy8IBqsR+LZfYY46 et+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaWE4EDpA28ZtQETY/qlBsBW1LW9Arhz+Ird3rqoolI=; b=l3tsTtWW5xGiW1kAcKTB1xy1pcmg9GjVBSIsMPEh9FRoCBP64bpGvhuueHhNtVh9Rv xCycRYSSZAQMeHdoj/tJXxVBriKp45YoAvVVW5m9TFHBdP5Z533fmZpXAfLdhXjsvD26 l0wkFOLj0E/8z3PJBymL7k++KhB5aS/+jIcM1LYHk8eTqL1/xmEYAs9SFg5LUqIy0L0a O8cA9g2vPlMWdJ2PtYuIdTdQzUQxxAD6M9IrKnKHo+a+mTabVUbIxePRVQX1zsRYYhnr awmfo53h2GIbw5bjSdPkgDFBiH68I0Icx34050+pClTvfcBLWHEQZLF1Esknw5dIFFNl 7pbw== X-Gm-Message-State: AFeK/H0x6DbPvM0ortne1Qq1CKJS57P/pqUzzRj3m9xXIvFvTdk397pGmA+veNG4oNkgkQ== X-Received: by 10.98.16.137 with SMTP id 9mr17006659pfq.104.1490477179514; Sat, 25 Mar 2017 14:26:19 -0700 (PDT) Received: from [10.0.0.6] ([47.138.113.242]) by smtp.gmail.com with ESMTPSA id g5sm12267684pfe.12.2017.03.25.14.26.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2017 14:26:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Opteron 6100-series "Magny-Cours" From: "Jack L." X-Mailer: iPhone Mail (14E5277a) In-Reply-To: Date: Sat, 25 Mar 2017 14:26:17 -0700 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C0CE842-C900-4914-B362-8DD88C1BDB2E@gmail.com> References: To: Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 21:26:20 -0000 I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i= might put them back on with FreeBSD but not anytime soon Sent from far away... > On Mar 25, 2017, at 11:02 AM, Andriy Gapon wrote: >=20 >=20 > Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors wit= h FreeBSD? >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= From owner-freebsd-current@freebsd.org Sat Mar 25 21:46:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C193D1D95B for ; Sat, 25 Mar 2017 21:46:15 +0000 (UTC) (envelope-from darren780@yahoo.com) Received: from nm27.bullet.mail.ne1.yahoo.com (nm27.bullet.mail.ne1.yahoo.com [98.138.90.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8AC1862 for ; Sat, 25 Mar 2017 21:46:14 +0000 (UTC) (envelope-from darren780@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1490478254; bh=Yc89jlucYZlJE1CUy8+6dF48Upc5/0yxeZ5Ug0wVTHg=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=VXdMDRAtcC6VVIwrhRaZmEOFY2/JoKpyldhE2Nd6DAV/Z0fYTP8FgRpahP7YgaUSv9F8EiS/t3ihXlmtaPCucm4Fud5Lp/NegZuOM+wD8s8DLPvYhuJejZMI1uePmoozhFckn/Aepp3uad3rJx65Pkp1v/0aZpEHUdcfDiuVqiN/oVs56uUROpMpyFOP0iie8HQFWxPmAslJDUQOXhDUgdsEXoeDeNyUHOype1dzLrmAhqUl6Pb2RG5LyqaNtJkuz0wJH6SkYCxrniD5pnHqWIRkYc2Rcf9ChQy9K+8b+SvZRXbj2IN0bE7PkhwVXQyK8McLHqejGodxi05kv6nepA== Received: from [98.138.226.176] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 21:44:14 -0000 Received: from [98.138.89.164] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 21:44:14 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 21:44:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 276310.99728.bm@omp1020.mail.ne1.yahoo.com X-YMail-OSG: YYqMf4MVM1k4ihA5iqVo009Cv4sCkKgsjjzu_lYdu1TaJSh3OBxDWRE1S_d9MSf 8zzycJ.JAFhW0NaCnrxp2XIkeMS0mwhFBT5snKM29JoLHoOUfuwW.EiM8wfMXrBryXci0UdWtimg ljvkGKVCV_Bf_B4nb6EbXzWl8MqKcvzQm6jfc4VcJQcSYAuAGUaE61rzl5o5J9dRMZ9sypNid7xj t7R_YnzPzAGPiBIwcNoge4u9EQnNUAW34iSnfsYzYU1l4EL4CSBhrf_llth50MPKjPlpw_qeV4rf ZTxFl7025.2hpMSG_DLhkKXFlggwTcdkkYD5z943ECdHVBM136.wrSzFQxnBh8MyWaGq1daLUr7H Ap5F3z.gNJaN.Dyy.SHcU3pIjAYFq4U4HBkwvHAIRNfrH4SjOPQuzLh8HK12_hqJwybmdcXSGa3O Uh2w69zIp0.bE73ymURl9vaDfUbYPBdfBnTAhZEnXsOUDAJPg2z5TlMWcxl4HMHLVUGW6Q8ZuGfj _GWWN66UY_W27S2NMsA-- Received: from jws200045.mail.ne1.yahoo.com by sendmailws117.mail.ne1.yahoo.com; Sat, 25 Mar 2017 21:44:13 +0000; 1490478253.872 Date: Sat, 25 Mar 2017 21:44:13 +0000 (UTC) From: Darren Reply-To: Darren To: "freebsd-current@freebsd.org" Message-ID: <1262380892.3757534.1490478253615@mail.yahoo.com> In-Reply-To: <20170325033142.GA23308@FreeBSD.org> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> <20170325010314.GG43712@kib.kiev.ua> <20170325033142.GA23308@FreeBSD.org> Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 21:46:15 -0000 So far I have not had a re-occurrence of the crash.=C2=A0 It has only been = a couple hours so far, will update if it happens or not over the next coupl= e days. Thanks! -Darren =20 =20 =C2=A0 Darren, On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: K> > I am getting this panic every hour to every couple of hours. K> >=20 K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 2= 3 14:56:45 EDT 2017=C2=A0=C2=A0=C2=A0=C2=A0 darren@asrock:/usr/obj/usr/src/= sys/GENERIC=C2=A0 amd64 K> > I manually typed out the following, apologize for any typos.=20 K> >=20 K> >=20 K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff8000= 6f0873c with sleeping prohibited K> > cpuid =3D 0 K> > time =3D 1490372797 K> > KDB: stack backtrace: K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00= 72e33690 K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpa= ges_done_async+037/frame 0xfffffe0072e33930 K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/fram= e 0xfffffe0072e33b60 K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 K> > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- K> > KDB: enter: panic K> > [ thread pid 12 tid 100038 ] K> > Stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kdb_enter+0x3b: movq=C2=A0=C2= =A0=C2=A0 $0,kdb_why K> > db> K>=20 K> Indeed, the context where sendfile_iodone() is executed, cannot call fdr= op(). Can you please test the attached patch? --=20 Totus tuus, Glebius. =20 From owner-freebsd-current@freebsd.org Sat Mar 25 22:28:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54217D1D4A8 for ; Sat, 25 Mar 2017 22:28:09 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B4C3D2F; Sat, 25 Mar 2017 22:28:09 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v2PMLGh6044514; Sat, 25 Mar 2017 15:21:16 -0700 (PDT) (envelope-from null@pozo.com) From: Manfred Antar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current Message-Id: Date: Sat, 25 Mar 2017 15:21:15 -0700 Cc: avg@freebsd.org To: FreeBSD Current X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-92.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_22,J_CHICKENPOX_65,J_CHICKENPOX_66,RP_MATCHES_RCVD,TW_AV,TW_BJ, TW_GD, TW_JC, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v2PMLGh6044514 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 22:28:09 -0000 Recent change to genassym.c breaks building a current kernel: -------------------------------------------------------------- >>> stage 3.1: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=3D40000 COMPILER_TYPE=3Dcla= ng COMPILER_FREEBSD_VERSION=3D1200006 MAKEOBJDIRPREFIX=3D/usr/obj MACHINE= _ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/sr= c/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sha= re/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac= CC=3D"/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroo= t=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX=3D"/usr/local/= bin/ccache c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr= /src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP=3D"cpp -target x86_64-unknown= -freebsd12.0 --sysroot=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bi= n" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcop= y" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" INSTALL=3D"sh /usr/src/tools= /install.sh" PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/= tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr= /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /= usr/src/share/mk KERNEL=3Dkernel all -DNO_MODULES_OBJ machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/us= r/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-a= liasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KE= RNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-poi= nter -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -= mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchro= nous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall= -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototype= s -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf= __=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -= Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -= Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointe= r-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member = -mno-aes -mno-avx -std=3Diso9899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/pozo *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src cd /usr/obj/usr/src/sys/pozo ; make device_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h also bus_if.h is missing: (pozo)5023}make /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.= -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTIO= N_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-fram= e-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=3Dkernel -mno-re= d-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffre= estanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnes= ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli= ne -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__= -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno= -error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-eq= uality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-= negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std= =3Diso9899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found so: make bus_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h then the build works: MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh pozo --- vers.o --- /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -= I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPT= ION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-f= rame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-floa= t -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector= -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wm= issing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer= -sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnosti= cs-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-er= ror-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -= Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-o= f-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 vers.c ctfconvert -L VERSION -g vers.o --- kernel.full --- linking kernel.full ctfmerge -L VERSION -g -o kernel.full ... text data bss dec hex filename 8657083 805570 3350664 12813317 0xc38405 kernel.full --- kernel.debug --- objcopy --only-keep-debug kernel.full kernel.debug --- kernel --- objcopy --strip-debug --add-gnu-debuglink=3Dkernel.debug kernel.full kernel somehow this needs to happen before genassym.c is compiled this is a kernel without any modules Manfred --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Sat Mar 25 23:03:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE2A0D1D2CD for ; Sat, 25 Mar 2017 23:03:39 +0000 (UTC) (envelope-from darren780@yahoo.com) Received: from nm1-vm2.bullet.mail.ne1.yahoo.com (nm1-vm2.bullet.mail.ne1.yahoo.com [98.138.91.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF46A0 for ; Sat, 25 Mar 2017 23:03:39 +0000 (UTC) (envelope-from darren780@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1490483013; bh=aWHLhHbRB7pDniqOcBSFeklxu9J3vVDiFwebOJu7Co4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=LWLl05cqrhAhTrmoihm3P3u1Kl733+PqXQoUNxTH2s+3rclMXucDr+HtLkX8GKDaUFsJqmHAKL63SYP+/FO+OBtz/6a6swaMjdFSgr5IcrTjhzVutr4cAOw430atcvvEP1UT404XjxtEezeUHGXfWtmSOQ+6P6KKNLRhVZSbGcxDtjGruoncpnRc1eKJhtOr+UmZFdr7Eg+BAPcEDIrJMl0qZRFfPG9Udvp86gsZ0SvXBBectcyg7wrIw8ugcmbFUblTGJSIXv4i4wlOYcaVTuQFQ1QIi+BdR7REh1uB6ACGrVBP9Td5TcDYJ2VcFyPM2+zrpaZ5sF2Mx26DY96VFQ== Received: from [98.138.100.116] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 23:03:33 -0000 Received: from [98.138.89.194] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 23:03:33 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 25 Mar 2017 23:03:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 998139.73089.bm@omp1052.mail.ne1.yahoo.com X-YMail-OSG: 9YBVSD4VM1lOBfFSGTHJ7nb5flO8UsvgyMu8l46nO9BJBRVsA1kACobWMyDi_Gu Ly.hIFwDBf4t_vlxLE1LMftx5f5WtoiKckU9oOTO17gGjzTruGtPYHJaJlz.0GgcGjVoG9ePIBPH fTMe.FWg49FPNf.tSB99FQ_idbm9YpPUj.G1ywgNuvvaQXHiqGM5BGXAoxzsd7Gp8QeLa1advPs2 V1Ena88huj1C.VLzLY8UZugHxczF0_onR9RvmHiKZJdlpKY90J7Z6cLnelXYtjUzjzRjsUGo366_ N8OmidIuaOUkvMokQXMIJJ.NCVPCbPwiL82vWxLW5BYm2rdFR_LkfyLzcCo8IXF.pFQWjNi2qG.v eLBsBjhKA.UlieTpD.4cbhC8ArOnI4Cc7U3hrndT0ye1cxdlPkyDBhRAasJhkCUMvUHorqe_v_6Z 3gA7.5_Uo8Tg_KwZbhCKAHDkv8UaVi4sRy_FclsSQoM_0pROoSYs8_FoxgIDcVdi.YmUH8kY9N.3 A0.dHIBCgZtGblUoMndI- Received: from jws200134.mail.ne1.yahoo.com by sendmailws158.mail.ne1.yahoo.com; Sat, 25 Mar 2017 23:03:32 +0000; 1490483012.624 Date: Sat, 25 Mar 2017 23:02:08 +0000 (UTC) From: Darren Reply-To: Darren To: "freebsd-current@freebsd.org" Message-ID: <1377533179.3728276.1490482928436@mail.yahoo.com> In-Reply-To: <20170325094529.GH43712@kib.kiev.ua> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> <20170325010314.GG43712@kib.kiev.ua> <20170325033142.GA23308@FreeBSD.org> <20170325094529.GH43712@kib.kiev.ua> Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 25 Mar 2017 23:03:39 -0000 This is the new panic.=C2=A0 Just happened 6 times. Maybe as a result of fs= ck running.Again may not be exact due to me copying it by hand.=20 Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address=C2=A0=C2=A0=C2=A0 =3D 0x20 fault code=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0=C2=A0 =3D supervisor read data, page not present instruction pointer=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =3D 0x20:0xffffffff80a4c= fdb stack pointer=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D 0x28:0xfffffe007c6828e0 frame pointer=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2= =A0 =3D 0x28:0xfffffe007c682910 code segment=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 =3D b= ase 0x0, limit 0xfffff, type 0x1b =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D inter= rupt enabled, resume, IOPL =3D 0 current process=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D= 12 (irq256: ahci0 [ thread pid 12 tid 100038 ] Stopped at =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sendfile_iodone+0x9b:=C2= =A0=C2=A0=C2=A0 movq=C2=A0=C2=A0=C2=A0 0x20(%rbx).%rax db> From: Konstantin Belousov To: Gleb Smirnoff =20 Cc: Darren ; "freebsd-current@freebsd.org" Sent: Saturday, March 25, 2017 5:45 AM Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on = wchan 0xfffff80006f0873c with sleeping prohibited =20 On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote: >=C2=A0 Darren, >=20 > On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: > K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: > K> > I am getting this panic every hour to every couple of hours. > K> >=20 > K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar= 23 14:56:45 EDT 2017=C2=A0=C2=A0=C2=A0=C2=A0 darren@asrock:/usr/obj/usr/sr= c/sys/GENERIC=C2=A0 amd64 > K> > I manually typed out the following, apologize for any typos.=20 > K> >=20 > K> >=20 > K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80= 006f0873c with sleeping prohibited > K> > cpuid =3D 0 > K> > time =3D 1490372797 > K> > KDB: stack backtrace: > K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe= 0072e33690 > K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 > K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 > K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 > K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 > K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 > K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 > K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 > K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_get= pages_done_async+037/frame 0xfffffe0072e33930 > K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 > K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 > K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a8= 0 > K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33a= f0 > K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 > K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/fr= ame 0xfffffe0072e33b60 > K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 > K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 > K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 > K> > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > K> > KDB: enter: panic > K> > [ thread pid 12 tid 100038 ] > K> > Stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kdb_enter+0x3b: movq=C2=A0= =C2=A0=C2=A0 $0,kdb_why > K> > db> > K>=20 > K> Indeed, the context where sendfile_iodone() is executed, cannot call f= drop(). >=20 > Can you please test the attached patch? >=20 > --=20 > Totus tuus, Glebius. > Index: sys/kern/kern_sendfile.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_sendfile.c=C2=A0=C2=A0=C2=A0 (revision 315926) > +++ sys/kern/kern_sendfile.c=C2=A0=C2=A0=C2=A0 (working copy) > @@ -296,8 +296,9 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 CURVNET_RESTORE(); >=C2=A0 =C2=A0=C2=A0=C2=A0 } >=C2=A0=20 > -=C2=A0=C2=A0=C2=A0 /* XXXGL: curthread */ > -=C2=A0=C2=A0=C2=A0 fdrop(sfio->sock_fp, curthread); > +=C2=A0=C2=A0=C2=A0 ACCEPT_LOCK(); > +=C2=A0=C2=A0=C2=A0 SOCK_LOCK(so); > +=C2=A0=C2=A0=C2=A0 sorele(so); >=C2=A0 =C2=A0=C2=A0=C2=A0 free(sfio, M_TEMP); >=C2=A0 } >=C2=A0=20 > @@ -860,7 +861,9 @@ prepend_header: >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } else { >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sfio->sock= _fp =3D sock_fp; >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sfio->npag= es =3D npages; > -=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 fhold(sock_fp); > +=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 SOCK_LOCK(so); > +=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 soref(so); > +=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 SOCK_UNLOCK(so)= ; >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 error =3D = (*so->so_proto->pr_usrreqs->pru_send) >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 =C2= =A0 (so, PRUS_NOTREADY, m, NULL, NULL, td); >=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sendfile_i= odone(sfio, NULL, 0, 0); With this patch, what prevents a close of the sfio->sock_fp file, which is needed to get the pointer to socket ? =20