"cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
In a context with: # cpuset -g pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 pid -1 domain policy: first-touch mask: 0, 1 I get: # cpuset -l0 -n prefer:0 COMMAND cpuset: setdomain: Invalid argument # cpuset -l0 -n prefer:2 COMMAND cpuset: setdomain: Invalid argument But one prefer:? value does allow the COMMAND to run: # cpuset -l0 -n prefer:1 COMMAND This seem odd to me. Am I missing something? For reference: I'm using a ThreadRipper 1950X with a head -r351227 based context for this activity. The above happens to have been run in a Windows 10 Pro HyperV session, instead of in a native-boot of the same media. (A native-boot would have had 32 CPUs.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with gcc9 not working
On 2019-09-09 23:08, Warner Losh wrote: > >> Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc >> buildworld earlier this week. (It doesn't play well with binary pkg's >> built with Clang, so I ended up replacing it with a Clang-built world >> instead, but it compiled.) >> >> Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while >> you're running the much more recent GCC9. I think GCC6.4.0 is more or >> less expected to build world today, but I don't think many people are >> building with GCC9. I would love for amd64-xtoolchain to move to a >> newer version, but I don't know what is blocking that — it seems like >> it should be straightforward. >> > I did a gcc8 build about a year or so ago, though I had to turn off Werror > to complete the build... Thanks. I kept running into build errors with gcc 8 and 9 (even with WERROR= in src.conf), but building with gcc 6 from the amd64-gcc port worked. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Source tree has many empty directories?
On Tue, Sep 10, 2019, 1:43 PM Ian Lepore wrote: > On Tue, 2019-09-10 at 21:41 +0200, Dimitry Andric wrote: > > On 10 Sep 2019, at 20:14, Ian Lepore wrote: > > > > > > On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote: > > > > However, please do *NOT* remove the sys/*/compile directories. > > > > > > > > Warner > > > > > > Uhhh... that's interesting. I just nuked one of those on my system > > > yesterday, because it had been hanging around since 2013 and I had no > > > idea what was -- I just assumed the build machinery created it because > > > I had accidentally done a make in a wrong directory once. > > > > > > So what are those directories about? I'm not used to seeing mystery > > > directories appear inside a source tree. > > > > There's not much mystery to be found. Subversion does not warn you when > you > > remove the last files from a directory, and it also does not > automatically > > remove such empty directories, like Git. Hence, those directories tend > to > > stick around, because every simply forgets about them. > > > > With regards to those empty directories under contrib/llvm, those were > actually > > imported from upstream. But since the llvm project will switch to Git > soon, > > this problem will automagically disappear. :-) > > > > -Dimitry > > > > I was referring specifically to the sys/*/compile directories Warner > mentioned. > They are for old school builds. Config(8) doesn't create them, so we have them in the tree. Because svn does this, we deleted the keep me files after the cut over. Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Source tree has many empty directories?
On Tue, 2019-09-10 at 21:41 +0200, Dimitry Andric wrote: > On 10 Sep 2019, at 20:14, Ian Lepore wrote: > > > > On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote: > > > However, please do *NOT* remove the sys/*/compile directories. > > > > > > Warner > > > > Uhhh... that's interesting. I just nuked one of those on my system > > yesterday, because it had been hanging around since 2013 and I had no > > idea what was -- I just assumed the build machinery created it because > > I had accidentally done a make in a wrong directory once. > > > > So what are those directories about? I'm not used to seeing mystery > > directories appear inside a source tree. > > There's not much mystery to be found. Subversion does not warn you when you > remove the last files from a directory, and it also does not automatically > remove such empty directories, like Git. Hence, those directories tend to > stick around, because every simply forgets about them. > > With regards to those empty directories under contrib/llvm, those were > actually > imported from upstream. But since the llvm project will switch to Git soon, > this problem will automagically disappear. :-) > > -Dimitry > I was referring specifically to the sys/*/compile directories Warner mentioned. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Source tree has many empty directories?
On 10 Sep 2019, at 20:14, Ian Lepore wrote: > > On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote: >> However, please do *NOT* remove the sys/*/compile directories. >> >> Warner > > Uhhh... that's interesting. I just nuked one of those on my system > yesterday, because it had been hanging around since 2013 and I had no > idea what was -- I just assumed the build machinery created it because > I had accidentally done a make in a wrong directory once. > > So what are those directories about? I'm not used to seeing mystery > directories appear inside a source tree. There's not much mystery to be found. Subversion does not warn you when you remove the last files from a directory, and it also does not automatically remove such empty directories, like Git. Hence, those directories tend to stick around, because every simply forgets about them. With regards to those empty directories under contrib/llvm, those were actually imported from upstream. But since the llvm project will switch to Git soon, this problem will automagically disappear. :-) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Source tree has many empty directories?
On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote: > However, please do *NOT* remove the sys/*/compile directories. > > Warner Uhhh... that's interesting. I just nuked one of those on my system yesterday, because it had been hanging around since 2013 and I had no idea what was -- I just assumed the build machinery created it because I had accidentally done a make in a wrong directory once. So what are those directories about? I'm not used to seeing mystery directories appear inside a source tree. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Source tree has many empty directories?
On Tue, Sep 10, 2019 at 10:58 AM Warner Losh wrote: > > On Tue, Sep 10, 2019 at 10:33 AM Hans Petter Selasky > wrote: > >> Hi Developers, >> >> My -head source tree might be dirty over the years, but there appears to >> be some empty directories. Can these just be removed? >> > > I've removed the ones I know are safe to remove, trying to mirror the > commits they were originally made empty. I can do the rest if nobody else > objects if people would like... > The rest being: /contrib/llvm/include/llvm/BinaryFormat/WasmRelocs ./contrib/llvm/include/llvm/MC/MCAnalysis ./contrib/llvm/include/llvm/TextAPI/MachO ./contrib/llvm/lib/Target/Nios2/MCTargetDesc ./contrib/llvm/lib/Target/Nios2/TargetInfo ./contrib/llvm/lib/Target/Nios2/InstPrinter ./contrib/llvm/lib/ExecutionEngine/JIT ./contrib/llvm/lib/MC/MCAnalysis ./contrib/llvm/lib/TextAPI/MachO ./contrib/llvm/tools/lldb/source/Plugins/LanguageRuntime/Go ./contrib/llvm/tools/lldb/source/Plugins/LanguageRuntime/Java ./contrib/llvm/tools/lldb/source/Plugins/OperatingSystem/Go ./contrib/llvm/tools/lldb/source/Plugins/ExpressionParser/Go ./contrib/llvm/tools/lldb/source/Plugins/Language/Go ./contrib/llvm/tools/lldb/source/Plugins/Language/Java ./contrib/llvm/tools/lldb/source/Plugins/Language/OCaml ./contrib/llvm/tools/llvm-mca/include/HardwareUnits ./contrib/llvm/tools/llvm-mca/include/Stages ./contrib/llvm/tools/llvm-mca/lib/HardwareUnits ./contrib/llvm/tools/llvm-mca/lib/Stages ./contrib/wpa/patches ./contrib/wpa/src/hlr_auc_gw ./contrib/wpa/wpa_supplicant/tests ./contrib/compiler-rt/lib/builtins/armv6m ./contrib/compiler-rt/lib/sancov ./contrib/libxo/m4 ./contrib/ipfilter/net ./contrib/ipfilter/ipsd/Celler However, please do *NOT* remove the sys/*/compile directories. Warner > Warner > > >> --HPS >> >> find . -type d -empty >> ./sys/fs/nandfs >> ./sys/mips/gxemul >> ./sys/gnu/dts/include/dt-bindings/genpd >> ./sys/modules/drm/r128 >> ./sys/modules/drm/sis >> ./sys/modules/drm/via >> ./sys/modules/drm/drm >> ./sys/modules/drm/mach64 >> ./sys/modules/drm/mga >> ./sys/modules/drm/tdfx >> ./sys/modules/drm/savage >> ./sys/modules/if_tun >> ./sys/modules/nandfs >> ./sys/modules/nand >> ./sys/modules/nandsim >> ./sys/modules/drm2/drm2 >> ./sys/modules/drm2/radeonkmsfw/ARUBA_me >> ./sys/modules/drm2/radeonkmsfw/VERDE_ce >> ./sys/modules/drm2/radeonkmsfw/TURKS_pfp >> ./sys/modules/drm2/radeonkmsfw/HAINAN_mc >> ./sys/modules/drm2/radeonkmsfw/CAYMAN_pfp >> ./sys/modules/drm2/radeonkmsfw/HAINAN_me >> ./sys/modules/drm2/radeonkmsfw/BARTS_pfp >> ./sys/modules/drm2/radeonkmsfw/CAICOS_mc >> ./sys/modules/drm2/radeonkmsfw/CAICOS_me >> ./sys/modules/drm2/radeonkmsfw/CEDAR_pfp >> ./sys/modules/drm2/radeonkmsfw/RV710_pfp >> ./sys/modules/drm2/radeonkmsfw/RV630_pfp >> ./sys/modules/drm2/radeonkmsfw/R600_rlc >> ./sys/modules/drm2/radeonkmsfw/TAHITI_ce >> ./sys/modules/drm2/radeonkmsfw/RV670_pfp >> ./sys/modules/drm2/radeonkmsfw/BARTS_mc >> ./sys/modules/drm2/radeonkmsfw/ARUBA_rlc >> ./sys/modules/drm2/radeonkmsfw/RV635_pfp >> ./sys/modules/drm2/radeonkmsfw/BARTS_me >> ./sys/modules/drm2/radeonkmsfw/CYPRESS_pfp >> ./sys/modules/drm2/radeonkmsfw/PALM_pfp >> ./sys/modules/drm2/radeonkmsfw/HAINAN_rlc >> ./sys/modules/drm2/radeonkmsfw/RV710_me >> ./sys/modules/drm2/radeonkmsfw/OLAND_pfp >> ./sys/modules/drm2/radeonkmsfw/RV730_me >> ./sys/modules/drm2/radeonkmsfw/OLAND_ce >> ./sys/modules/drm2/radeonkmsfw/R200_cp >> ./sys/modules/drm2/radeonkmsfw/RV770_me >> ./sys/modules/drm2/radeonkmsfw/REDWOOD_pfp >> ./sys/modules/drm2/radeonkmsfw/SUMO2_pfp >> ./sys/modules/drm2/radeonkmsfw/JUNIPER_rlc >> ./sys/modules/drm2/radeonkmsfw/PITCAIRN_pfp >> ./sys/modules/drm2/radeonkmsfw/PITCAIRN_ce >> ./sys/modules/drm2/radeonkmsfw/SUMO_rlc >> ./sys/modules/drm2/radeonkmsfw/REDWOOD_me >> ./sys/modules/drm2/radeonkmsfw/TAHITI_pfp >> ./sys/modules/drm2/radeonkmsfw/CEDAR_me >> ./sys/modules/drm2/radeonkmsfw/SUMO_uvd >> ./sys/modules/drm2/radeonkmsfw/VERDE_rlc >> ./sys/modules/drm2/radeonkmsfw/HAINAN_ce >> ./sys/modules/drm2/radeonkmsfw/CAICOS_pfp >> ./sys/modules/drm2/radeonkmsfw/R300_cp >> ./sys/modules/drm2/radeonkmsfw/BTC_rlc >> ./sys/modules/drm2/radeonkmsfw/CAYMAN_rlc >> ./sys/modules/drm2/radeonkmsfw/CEDAR_rlc >> ./sys/modules/drm2/radeonkmsfw/RV610_pfp >> ./sys/modules/drm2/radeonkmsfw/VERDE_mc >> ./sys/modules/drm2/radeonkmsfw/VERDE_me >> ./sys/modules/drm2/radeonkmsfw/RV730_pfp >> ./sys/modules/drm2/radeonkmsfw/CYPRESS_rlc >> ./sys/modules/drm2/radeonkmsfw/R700_rlc >> ./sys/modules/drm2/radeonkmsfw/RS780_pfp >> ./sys/modules/drm2/radeonkmsfw/RV770_pfp >> ./sys/modules/drm2/radeonkmsfw/R600_pfp >> ./sys/modules/drm2/radeonkmsfw/RV710_uvd >> ./sys/modules/drm2/radeonkmsfw/JUNIPER_me >> ./sys/modules/drm2/radeonkmsfw/OLAND_rlc >> ./sys/modules/drm2/radeonkmsfw/ARUBA_pfp >> ./sys/modules/drm2/radeonkmsfw/TAHITI_mc >> ./sys/modules/drm2/radeonkmsfw/TAHITI_me >> ./sys/modules/drm2/radeonkmsfw/HAINAN_pfp >> ./sys/modules/drm2/radeonkmsfw/REDWOOD_rlc >> ./sys/modules/drm2/radeonkmsfw/RS780_me >>
Re: Source tree has many empty directories?
On Tue, Sep 10, 2019 at 10:33 AM Hans Petter Selasky wrote: > Hi Developers, > > My -head source tree might be dirty over the years, but there appears to > be some empty directories. Can these just be removed? > I've removed the ones I know are safe to remove, trying to mirror the commits they were originally made empty. I can do the rest if nobody else objects if people would like... Warner > --HPS > > find . -type d -empty > ./sys/fs/nandfs > ./sys/mips/gxemul > ./sys/gnu/dts/include/dt-bindings/genpd > ./sys/modules/drm/r128 > ./sys/modules/drm/sis > ./sys/modules/drm/via > ./sys/modules/drm/drm > ./sys/modules/drm/mach64 > ./sys/modules/drm/mga > ./sys/modules/drm/tdfx > ./sys/modules/drm/savage > ./sys/modules/if_tun > ./sys/modules/nandfs > ./sys/modules/nand > ./sys/modules/nandsim > ./sys/modules/drm2/drm2 > ./sys/modules/drm2/radeonkmsfw/ARUBA_me > ./sys/modules/drm2/radeonkmsfw/VERDE_ce > ./sys/modules/drm2/radeonkmsfw/TURKS_pfp > ./sys/modules/drm2/radeonkmsfw/HAINAN_mc > ./sys/modules/drm2/radeonkmsfw/CAYMAN_pfp > ./sys/modules/drm2/radeonkmsfw/HAINAN_me > ./sys/modules/drm2/radeonkmsfw/BARTS_pfp > ./sys/modules/drm2/radeonkmsfw/CAICOS_mc > ./sys/modules/drm2/radeonkmsfw/CAICOS_me > ./sys/modules/drm2/radeonkmsfw/CEDAR_pfp > ./sys/modules/drm2/radeonkmsfw/RV710_pfp > ./sys/modules/drm2/radeonkmsfw/RV630_pfp > ./sys/modules/drm2/radeonkmsfw/R600_rlc > ./sys/modules/drm2/radeonkmsfw/TAHITI_ce > ./sys/modules/drm2/radeonkmsfw/RV670_pfp > ./sys/modules/drm2/radeonkmsfw/BARTS_mc > ./sys/modules/drm2/radeonkmsfw/ARUBA_rlc > ./sys/modules/drm2/radeonkmsfw/RV635_pfp > ./sys/modules/drm2/radeonkmsfw/BARTS_me > ./sys/modules/drm2/radeonkmsfw/CYPRESS_pfp > ./sys/modules/drm2/radeonkmsfw/PALM_pfp > ./sys/modules/drm2/radeonkmsfw/HAINAN_rlc > ./sys/modules/drm2/radeonkmsfw/RV710_me > ./sys/modules/drm2/radeonkmsfw/OLAND_pfp > ./sys/modules/drm2/radeonkmsfw/RV730_me > ./sys/modules/drm2/radeonkmsfw/OLAND_ce > ./sys/modules/drm2/radeonkmsfw/R200_cp > ./sys/modules/drm2/radeonkmsfw/RV770_me > ./sys/modules/drm2/radeonkmsfw/REDWOOD_pfp > ./sys/modules/drm2/radeonkmsfw/SUMO2_pfp > ./sys/modules/drm2/radeonkmsfw/JUNIPER_rlc > ./sys/modules/drm2/radeonkmsfw/PITCAIRN_pfp > ./sys/modules/drm2/radeonkmsfw/PITCAIRN_ce > ./sys/modules/drm2/radeonkmsfw/SUMO_rlc > ./sys/modules/drm2/radeonkmsfw/REDWOOD_me > ./sys/modules/drm2/radeonkmsfw/TAHITI_pfp > ./sys/modules/drm2/radeonkmsfw/CEDAR_me > ./sys/modules/drm2/radeonkmsfw/SUMO_uvd > ./sys/modules/drm2/radeonkmsfw/VERDE_rlc > ./sys/modules/drm2/radeonkmsfw/HAINAN_ce > ./sys/modules/drm2/radeonkmsfw/CAICOS_pfp > ./sys/modules/drm2/radeonkmsfw/R300_cp > ./sys/modules/drm2/radeonkmsfw/BTC_rlc > ./sys/modules/drm2/radeonkmsfw/CAYMAN_rlc > ./sys/modules/drm2/radeonkmsfw/CEDAR_rlc > ./sys/modules/drm2/radeonkmsfw/RV610_pfp > ./sys/modules/drm2/radeonkmsfw/VERDE_mc > ./sys/modules/drm2/radeonkmsfw/VERDE_me > ./sys/modules/drm2/radeonkmsfw/RV730_pfp > ./sys/modules/drm2/radeonkmsfw/CYPRESS_rlc > ./sys/modules/drm2/radeonkmsfw/R700_rlc > ./sys/modules/drm2/radeonkmsfw/RS780_pfp > ./sys/modules/drm2/radeonkmsfw/RV770_pfp > ./sys/modules/drm2/radeonkmsfw/R600_pfp > ./sys/modules/drm2/radeonkmsfw/RV710_uvd > ./sys/modules/drm2/radeonkmsfw/JUNIPER_me > ./sys/modules/drm2/radeonkmsfw/OLAND_rlc > ./sys/modules/drm2/radeonkmsfw/ARUBA_pfp > ./sys/modules/drm2/radeonkmsfw/TAHITI_mc > ./sys/modules/drm2/radeonkmsfw/TAHITI_me > ./sys/modules/drm2/radeonkmsfw/HAINAN_pfp > ./sys/modules/drm2/radeonkmsfw/REDWOOD_rlc > ./sys/modules/drm2/radeonkmsfw/RS780_me > ./sys/modules/drm2/radeonkmsfw/CYPRESS_uvd > ./sys/modules/drm2/radeonkmsfw/RV635_me > ./sys/modules/drm2/radeonkmsfw/R600_me > ./sys/modules/drm2/radeonkmsfw/R420_cp > ./sys/modules/drm2/radeonkmsfw/PITCAIRN_rlc > ./sys/modules/drm2/radeonkmsfw/PALM_me > ./sys/modules/drm2/radeonkmsfw/OLAND_mc > ./sys/modules/drm2/radeonkmsfw/OLAND_me > ./sys/modules/drm2/radeonkmsfw/JUNIPER_pfp > ./sys/modules/drm2/radeonkmsfw/TAHITI_rlc > ./sys/modules/drm2/radeonkmsfw/RV620_pfp > ./sys/modules/drm2/radeonkmsfw/SUMO2_me > ./sys/modules/drm2/radeonkmsfw/CAYMAN_mc > ./sys/modules/drm2/radeonkmsfw/TURKS_mc > ./sys/modules/drm2/radeonkmsfw/PITCAIRN_mc > ./sys/modules/drm2/radeonkmsfw/SUMO_pfp > ./sys/modules/drm2/radeonkmsfw/CAYMAN_me > ./sys/modules/drm2/radeonkmsfw/TURKS_me > ./sys/modules/drm2/radeonkmsfw/PITCAIRN_me > ./sys/modules/drm2/radeonkmsfw/RS600_cp > ./sys/modules/drm2/radeonkmsfw/RV610_me > ./sys/modules/drm2/radeonkmsfw/RV620_me > ./sys/modules/drm2/radeonkmsfw/TAHITI_uvd > ./sys/modules/drm2/radeonkmsfw/RV630_me > ./sys/modules/drm2/radeonkmsfw/R100_cp > ./sys/modules/drm2/radeonkmsfw/SUMO_me > ./sys/modules/drm2/radeonkmsfw/RS690_cp > ./sys/modules/drm2/radeonkmsfw/RV670_me > ./sys/modules/drm2/radeonkmsfw/CYPRESS_me > ./sys/modules/drm2/radeonkmsfw/R520_cp > ./sys/modules/drm2/radeonkmsfw/VERDE_pfp > ./sys/modules/drm2/i915kms > ./sys/modules/drm2/radeonkms > ./sys/modules/if_tap > ./sys/dev/nand > ./crypto/heimdal/lib/sqlite >
Source tree has many empty directories?
Hi Developers, My -head source tree might be dirty over the years, but there appears to be some empty directories. Can these just be removed? --HPS find . -type d -empty ./sys/fs/nandfs ./sys/mips/gxemul ./sys/gnu/dts/include/dt-bindings/genpd ./sys/modules/drm/r128 ./sys/modules/drm/sis ./sys/modules/drm/via ./sys/modules/drm/drm ./sys/modules/drm/mach64 ./sys/modules/drm/mga ./sys/modules/drm/tdfx ./sys/modules/drm/savage ./sys/modules/if_tun ./sys/modules/nandfs ./sys/modules/nand ./sys/modules/nandsim ./sys/modules/drm2/drm2 ./sys/modules/drm2/radeonkmsfw/ARUBA_me ./sys/modules/drm2/radeonkmsfw/VERDE_ce ./sys/modules/drm2/radeonkmsfw/TURKS_pfp ./sys/modules/drm2/radeonkmsfw/HAINAN_mc ./sys/modules/drm2/radeonkmsfw/CAYMAN_pfp ./sys/modules/drm2/radeonkmsfw/HAINAN_me ./sys/modules/drm2/radeonkmsfw/BARTS_pfp ./sys/modules/drm2/radeonkmsfw/CAICOS_mc ./sys/modules/drm2/radeonkmsfw/CAICOS_me ./sys/modules/drm2/radeonkmsfw/CEDAR_pfp ./sys/modules/drm2/radeonkmsfw/RV710_pfp ./sys/modules/drm2/radeonkmsfw/RV630_pfp ./sys/modules/drm2/radeonkmsfw/R600_rlc ./sys/modules/drm2/radeonkmsfw/TAHITI_ce ./sys/modules/drm2/radeonkmsfw/RV670_pfp ./sys/modules/drm2/radeonkmsfw/BARTS_mc ./sys/modules/drm2/radeonkmsfw/ARUBA_rlc ./sys/modules/drm2/radeonkmsfw/RV635_pfp ./sys/modules/drm2/radeonkmsfw/BARTS_me ./sys/modules/drm2/radeonkmsfw/CYPRESS_pfp ./sys/modules/drm2/radeonkmsfw/PALM_pfp ./sys/modules/drm2/radeonkmsfw/HAINAN_rlc ./sys/modules/drm2/radeonkmsfw/RV710_me ./sys/modules/drm2/radeonkmsfw/OLAND_pfp ./sys/modules/drm2/radeonkmsfw/RV730_me ./sys/modules/drm2/radeonkmsfw/OLAND_ce ./sys/modules/drm2/radeonkmsfw/R200_cp ./sys/modules/drm2/radeonkmsfw/RV770_me ./sys/modules/drm2/radeonkmsfw/REDWOOD_pfp ./sys/modules/drm2/radeonkmsfw/SUMO2_pfp ./sys/modules/drm2/radeonkmsfw/JUNIPER_rlc ./sys/modules/drm2/radeonkmsfw/PITCAIRN_pfp ./sys/modules/drm2/radeonkmsfw/PITCAIRN_ce ./sys/modules/drm2/radeonkmsfw/SUMO_rlc ./sys/modules/drm2/radeonkmsfw/REDWOOD_me ./sys/modules/drm2/radeonkmsfw/TAHITI_pfp ./sys/modules/drm2/radeonkmsfw/CEDAR_me ./sys/modules/drm2/radeonkmsfw/SUMO_uvd ./sys/modules/drm2/radeonkmsfw/VERDE_rlc ./sys/modules/drm2/radeonkmsfw/HAINAN_ce ./sys/modules/drm2/radeonkmsfw/CAICOS_pfp ./sys/modules/drm2/radeonkmsfw/R300_cp ./sys/modules/drm2/radeonkmsfw/BTC_rlc ./sys/modules/drm2/radeonkmsfw/CAYMAN_rlc ./sys/modules/drm2/radeonkmsfw/CEDAR_rlc ./sys/modules/drm2/radeonkmsfw/RV610_pfp ./sys/modules/drm2/radeonkmsfw/VERDE_mc ./sys/modules/drm2/radeonkmsfw/VERDE_me ./sys/modules/drm2/radeonkmsfw/RV730_pfp ./sys/modules/drm2/radeonkmsfw/CYPRESS_rlc ./sys/modules/drm2/radeonkmsfw/R700_rlc ./sys/modules/drm2/radeonkmsfw/RS780_pfp ./sys/modules/drm2/radeonkmsfw/RV770_pfp ./sys/modules/drm2/radeonkmsfw/R600_pfp ./sys/modules/drm2/radeonkmsfw/RV710_uvd ./sys/modules/drm2/radeonkmsfw/JUNIPER_me ./sys/modules/drm2/radeonkmsfw/OLAND_rlc ./sys/modules/drm2/radeonkmsfw/ARUBA_pfp ./sys/modules/drm2/radeonkmsfw/TAHITI_mc ./sys/modules/drm2/radeonkmsfw/TAHITI_me ./sys/modules/drm2/radeonkmsfw/HAINAN_pfp ./sys/modules/drm2/radeonkmsfw/REDWOOD_rlc ./sys/modules/drm2/radeonkmsfw/RS780_me ./sys/modules/drm2/radeonkmsfw/CYPRESS_uvd ./sys/modules/drm2/radeonkmsfw/RV635_me ./sys/modules/drm2/radeonkmsfw/R600_me ./sys/modules/drm2/radeonkmsfw/R420_cp ./sys/modules/drm2/radeonkmsfw/PITCAIRN_rlc ./sys/modules/drm2/radeonkmsfw/PALM_me ./sys/modules/drm2/radeonkmsfw/OLAND_mc ./sys/modules/drm2/radeonkmsfw/OLAND_me ./sys/modules/drm2/radeonkmsfw/JUNIPER_pfp ./sys/modules/drm2/radeonkmsfw/TAHITI_rlc ./sys/modules/drm2/radeonkmsfw/RV620_pfp ./sys/modules/drm2/radeonkmsfw/SUMO2_me ./sys/modules/drm2/radeonkmsfw/CAYMAN_mc ./sys/modules/drm2/radeonkmsfw/TURKS_mc ./sys/modules/drm2/radeonkmsfw/PITCAIRN_mc ./sys/modules/drm2/radeonkmsfw/SUMO_pfp ./sys/modules/drm2/radeonkmsfw/CAYMAN_me ./sys/modules/drm2/radeonkmsfw/TURKS_me ./sys/modules/drm2/radeonkmsfw/PITCAIRN_me ./sys/modules/drm2/radeonkmsfw/RS600_cp ./sys/modules/drm2/radeonkmsfw/RV610_me ./sys/modules/drm2/radeonkmsfw/RV620_me ./sys/modules/drm2/radeonkmsfw/TAHITI_uvd ./sys/modules/drm2/radeonkmsfw/RV630_me ./sys/modules/drm2/radeonkmsfw/R100_cp ./sys/modules/drm2/radeonkmsfw/SUMO_me ./sys/modules/drm2/radeonkmsfw/RS690_cp ./sys/modules/drm2/radeonkmsfw/RV670_me ./sys/modules/drm2/radeonkmsfw/CYPRESS_me ./sys/modules/drm2/radeonkmsfw/R520_cp ./sys/modules/drm2/radeonkmsfw/VERDE_pfp ./sys/modules/drm2/i915kms ./sys/modules/drm2/radeonkms ./sys/modules/if_tap ./sys/dev/nand ./crypto/heimdal/lib/sqlite ./usr.bin/send-pr ./sbin/nandfs ./sbin/newfs_nandfs ./tools/tools/nanobsd/gateworks/Files/root ./tools/tools/nanobsd/gateworks/cfg/ssh ./tools/tools/nanobsd/rescue/Pkg ./contrib/traceroute/lbl ./contrib/ipfilter/net ./contrib/ipfilter/ipsd/Celler ./contrib/netbsd-tests/dev/usb/libhid ./contrib/netbsd-tests/dev/usb/t_hid ./contrib/netbsd-tests/crypto/libcrypto/x509v3 ./contrib/netbsd-tests/crypto/libcrypto/rsa ./contrib/netbsd-tests/crypto/libcrypto/rc2
Re: panic: rcv_start < rcv_end
Michael Tuexen wrote: On 10. Sep 2019, at 14:37, Yuri Pankov wrote: Just seen this almost immediately after booting the system installed from amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, I didn't have the swap/dump device configured at the time, so no dump was saved. But it looks like I'm not alone, seeing the https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ topic. Note that I'm running on bare metal, so bhyve isn't involved. My panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. In (the most likely) case it's not helpful enough, I'm now running with dump device configured, and will update if/when the panic reproduces. This panic should be fixed by: https://svnweb.freebsd.org/changeset/base/352072 Please drop me a note if not. Good to know, thanks! I only seen it once after installing the snapshot that didn't include the fix, and didn't notice that the fix is already committed. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: rcv_start < rcv_end
On 09/10/2019 9:20 am, Michael Tuexen wrote: On 10. Sep 2019, at 14:37, Yuri Pankov wrote: Just seen this almost immediately after booting the system installed from amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, I didn't have the swap/dump device configured at the time, so no dump was saved. But it looks like I'm not alone, seeing the https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ topic. Note that I'm running on bare metal, so bhyve isn't involved. My panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. In (the most likely) case it's not helpful enough, I'm now running with dump device configured, and will update if/when the panic reproduces. This panic should be fixed by: https://svnweb.freebsd.org/changeset/base/352072 Please drop me a note if not. Best regards Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" is this the same panic: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240471 I *DO* have a core. -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: rcv_start < rcv_end
> On 10. Sep 2019, at 14:37, Yuri Pankov wrote: > > Just seen this almost immediately after booting the system installed from > amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, > I didn't have the swap/dump device configured at the time, so no dump was > saved. > > But it looks like I'm not alone, seeing the > https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ > topic. Note that I'm running on bare metal, so bhyve isn't involved. My > panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. > > In (the most likely) case it's not helpful enough, I'm now running with dump > device configured, and will update if/when the panic reproduces. This panic should be fixed by: https://svnweb.freebsd.org/changeset/base/352072 Please drop me a note if not. Best regards Michael > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: rcv_start < rcv_end
Just seen this almost immediately after booting the system installed from amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, I didn't have the swap/dump device configured at the time, so no dump was saved. But it looks like I'm not alone, seeing the https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ topic. Note that I'm running on bare metal, so bhyve isn't involved. My panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. In (the most likely) case it's not helpful enough, I'm now running with dump device configured, and will update if/when the panic reproduces. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Mon, Sep 09, 2019 at 03:42:43PM -0600, Warner Losh wrote: > On Mon, Sep 9, 2019 at 3:12 PM Ian Lepore wrote: > > > On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote: > > > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > > > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > > > > Belousov writes: > > > > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert > > > > > > > > wrote: > > > > > > > > > [...] > > > > > > > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > > > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > > > > on a box that has it configured is a total no win situation. > > > > > > > > > > > > > Does it have that effect? I don't know. But I would argue that that's > > > > a separate issue, and we should make that happen by adding > > > > ntpd_oomprotect=YES to /etc/defaults/rc.conf > > > > > > Wiring process memory has no effect on OOM selection. More, because > > > all potentially allocated pages are allocated for real after mlockall(), > > > the size of the vmspace, as accounted by OOM, is the largest possible > > > size from the whole lifetime. > > > > > > On the other hand, the code execution times are not predictable if the > > > process's pages can be paged out. Under severe load next instruction > > > might take several seconds or even minutes to start. It is quite unlike > > > the scheduler delays. That introduces a jitter in the local time > > > measurements and their usage as done in userspace. Wouldn't this affect > > > the accuracy ? > > > > > > > IMO, there is a large gap between "in theory, paging could cause > > indeterminate delays in code execution" and "time will be inaccurate on > > your system". If there were a delay in a part of the code where it > > matters that amounted to "seconds or even minutes", what you'd end up > > with is a measurement that would be discarded by the median filter as > > an outlier. There would be some danger that if that kind of delay > > happened for too many polling cycles in a row, you'd end up with no > > usable measurements after a while and clock accuracy would suffer. > > Sub-second delays would be more worriesome because they might not be > > rejected as outliers. > > > > There are only a couple code paths in freebsd ntpd processing where a > > paging (or scheduling) delay could cause measurement inaccuracy: > > > > - When stepping the clock, the code that runs between calling > > clock_gettime() and calling clock_settime() to apply the step > > adjustment to the clock. > > > > - When beginning an exchange with or replying to a peer, the code that > > runs between obtaining system time for the outgoing Transmit Timestamp > > and actually transmitting that packet. > > > > Stepping the clock typically only happens once at startup. The ntpd > > code itself recognizes that this is a time-critical path (it has > > comments to that effect) but unfortunately the code that runs is > > scattered among several different .c files so it's hard to say what the > > likelyhood is that code in the critical section will all be in the same > > page (or be already-resident because other startup-time code faulted in > > those pages). IMO, the right fix for this would be a kernel interface > > that let you apply a step-delta to the clock with a single syscall > > (perhaps as an extension to the existing ntp_adjtime() using a new mode > > flag). > > > > On freebsd, the Receive timestamps are captured in the kernel and > > delivered along with the packet to userland, and are retrieved by the > > ntpd code from the SCM_BINTIME control message in the packet, so there > > is no latency problem in the receive path. There isn't a corresponding > > kernel mechanism for setting the outgoing timestamps, so whether it's > > originating a request to a peer or replying to a request from a peer, > > the transmit timestamp could be wrong due to: > > > > - paging delays > > - scheduler delays > > - network stack, outgoing queues, and driver delays > > > > So the primary vulnerability is on the transmit path between obtaining > > system time and the packet leaving the system. A quick glance at that > > code makes me think that most of the data being touched has already > > been referenced pretty recently during the process of assembling the > > outgoing packet, so it's unlikely that storing the timestamp into the > > outgoing packet or the other bit of work that happens after that > > triggers a pagein unless the system is pathologically overloaded. > > Naturally, obtaining the timestamp and putting it into the packet is > > one of the last things it does before sending, so the code path is > > relatively short, but it's not clear to me whether it's likely or not > > that the code involved all lives in the same page.
