From nobody Thu Oct 07 20:52:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 712BA12B9B6C for ; Thu, 7 Oct 2021 20:52:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQNnN2bqCz50NK for ; Thu, 7 Oct 2021 20:52:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id r1so7545503qta.12 for ; Thu, 07 Oct 2021 13:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vplskjgBLCQoZyRkA36+u3+1mPEKrOdD8xEg/QgA9tE=; b=lTZtUpxdg01spiK1nQJUqynJWR+rJQBrPfMxXy7eemlf9H3B/XgG7Y/89Ci2zTXFV8 iLdTptYCCoNL9gO2HIBPlK3c71zKAiT5WYUTIiU4krYQhlnCY4+zpL0Tp4WLTe149EWu ueUADFTCoSWxRJ8/El7mJXenzMCpKQHK7g0H9w2XC5rlv7MInXhWnKcyHjgh9vmGDpXO vclpzyZvIQxeB+69s9/EUalCGyOEfVs4AuQK3/6wqnwtYF74c+qA3ooVthSnXLvOOwvO O+YKdm2myOauNlxCv0qDL5Gfh6XneQEWGpNj275avI6qiaTXAacgzMJ9SXzDv3QvG1WS vQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=vplskjgBLCQoZyRkA36+u3+1mPEKrOdD8xEg/QgA9tE=; b=RG8v6PUyfxRG9ZjDzf++uGzNghyjII99r5x8ZFkYp2KvbPRIDS77AR+h0XpTCNfSZh oSPcb1qrcuzkTVgMxjRHxCmk0YRZNlxhCecDRZVTpyWcGkK51MedE8kWgOhjHFe7e6k3 eKNBZ66YaFvN5F0y6eh+RzDtu6uvNQrp1M2Pi4+KS3wgnRoqlejDGCuxnelVywvEtaPN F6wMHTLdeaaYWgF3UlpHhs/0KJnRBvHaeIPNv5le+GgmSXuQg0WRe7ktgGGX+BxCgj/F rM1uLMnFW4/ujvQzfxGMzbI/qRlTOzXkWC4/kXepBpdbMgN+PmFldtAOA5/Wk/zi1XsM 4DyA== X-Gm-Message-State: AOAM530cIl+QwkABa4raU6LS17yY9Zddjb3prK6q8oEmTR5LCteSlIdU dy3IhsoMR63K5cf3VXpxQ4ZI7gGeFaE= X-Google-Smtp-Source: ABdhPJxvwcIh+pWblzCrDfDwzE0JzbX86pJyXs20bB6zP+dF+a35K0TfGLLaJlmJhcGxBe/FyAJgMA== X-Received: by 2002:ac8:4084:: with SMTP id p4mr7569934qtl.306.1633639970487; Thu, 07 Oct 2021 13:52:50 -0700 (PDT) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id c8sm529888qtb.9.2021.10.07.13.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 13:52:50 -0700 (PDT) Date: Thu, 7 Oct 2021 16:52:52 -0400 From: Mark Johnston To: imb@protected-networks.net Cc: Konstantin Belousov , freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> X-Rspamd-Queue-Id: 4HQNnN2bqCz50NK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: > On 10/7/21 15:39, Konstantin Belousov wrote: > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > >> While building a local release bundle, I sometimes get bsdtar failing (and > >> dumping core) as follows below. Worse, as can be seen below, it doesn't stop > >> the build unless I happen to notice and it yields an incomplete package. > >> > >> a usr/src/sys/netgraph/ng_checksum.h > >> a usr/src/sys/netgraph/ng_message.h > >> a usr/src/sys/netgraph/ng_echo.c > >> a usr/src/sys/netgraph/ng_gif.h > >> : jemalloc_arena.c:747: Failed assertion: > >> "nstime_compare(&decay->epoch, &time) <= 0" > >> Abort trap (core dumped) > >> sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > >> > >> What causes this? Build machine is a 2x4-core Intel box with ZFS > >> file-systems all around. I tried stopping NTPD temporarily but the failures > >> persist .. sometimes :-( > >> > >> I've seen this at different points in the archiving process so it doesn't > >> seem specific to building kernel.txz. > > > > What timecounter do you use? Perhaps show the whole output from > > sysctl kern.timecounter. > > imb@vm01:/home/imb> sysctl kern.timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 16124892 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 1883995229 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 57 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1413153007 > kern.timecounter.tc.TSC-low.counter: 2352002295 > kern.timecounter.tc.TSC-low.mask: 4294967295 > > I overrode the default selection of counter-type as NTPD drifted so > badly as to require stepping almost hourly :-( Could you show output from # kldload cpuctl # cpucontrol -i 0x15 /dev/cpuctl0 # cpucontrol -i 0x16 /dev/cpuctl0 as well as a copy of the dmesg after a boot? I am looking at a similar problem currently.