From owner-freebsd-current@freebsd.org Wed Jan 20 10:02:30 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E87174F041D for ; Wed, 20 Jan 2021 10:02:30 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4DLLft09Lfz4Tvh for ; Wed, 20 Jan 2021 10:02:29 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-f649235c.06-431-73746f70.bbcust.telenor.se ([92.35.73.246] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1l2AJi-000Fsx-0I; Wed, 20 Jan 2021 11:02:22 +0100 Received: from [192.168.67.27] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1l2AJh-0005aX-FL; Wed, 20 Jan 2021 11:02:21 +0100 Subject: Re: Waiting for bufdaemon To: Konstantin Belousov Cc: freebsd-current References: <7c4da243-52ff-c5ee-3d56-1ae651286e0e@alvermark.net> <369b3d82-98c5-b31e-6168-4003a042f174@FreeBSD.org> <556d40b8-92d7-303e-7d87-ea496d0ca733@FreeBSD.org> <9ae3cc65-193a-39c3-4067-0d42e9f634b0@gwdg.de> From: Jakob Alvermark Message-ID: <1d675d77-8bdb-c285-ffa2-28330b839734@alvermark.net> Date: Wed, 20 Jan 2021 11:02:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4DLLft09Lfz4Tvh X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[alvermark.net:s=x]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.34.136.138]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[alvermark.net: no valid DMARC record]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[185.34.136.138:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[alvermark.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.980]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.34.136.138:from]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/23, country:IT]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 20 Jan 2021 10:02:31 -0000 On 1/17/21 10:49 AM, Konstantin Belousov wrote: > On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote: >> Am 17.01.21 um 05:33 schrieb Konstantin Belousov: >>> On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote: >>>> During another shutdown after heavy usage of the box, the following >>>> messages were also seen: >>>> >>>> >>>> [...] >>>> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 >>>> efirtc0: CLOCK_SETTIME error 14 >>> This means that BIOS code faulted during RTC settime call. I doubt that >>> it is related. >>> >>> On the other hand, it is good that the onfault EFI RT code got tested finally. >>> >> Thanks for clarification :) >> >> >> Any chance of getting a fix for the AMD CPUs in the foreseeable future? >> >> Or should I revert commit 9e680e4005b7 on affected boxes until further >> notice (as a workaround)? > I am working on it, no ETA. > > Interesting point would be to check on machines of other testers, > if the following hides the problem. > > diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c > index 85924df98312..5700a8ca98e5 100644 > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -639,7 +639,7 @@ init_TSC_tc(void) > * on Intel, and MFENCE;RDTSC on AMD. > * - For really old CPUs, just use RDTSC. > */ > - if ((cpu_vendor_id == CPU_VENDOR_AMD || > + if (false && (cpu_vendor_id == CPU_VENDOR_AMD || > cpu_vendor_id == CPU_VENDOR_HYGON) && > CPUID_TO_FAMILY(cpu_id) >= 0x17) { > tsc_timecounter.tc_get_timecount = shift > 0 ? This patch hides the problem for me. The system seems to work better now. No waiting on reboot, and the webcam works better. Jakob