From owner-freebsd-current@freebsd.org Wed May 27 21:06:12 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3419B2CF34E for ; Wed, 27 May 2020 21:06:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49XNfW6VZKz48Hg for ; Wed, 27 May 2020 21:06:11 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.nyi.freebsd.org (Postfix) id DD3992CF525; Wed, 27 May 2020 21:06:11 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DCFFF2CF34D for ; Wed, 27 May 2020 21:06:11 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49XNfV1DPZz48Hf; Wed, 27 May 2020 21:06:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E547A260AFC; Wed, 27 May 2020 23:06:01 +0200 (CEST) Subject: Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time] To: Justin Hibbits , John Baldwin Cc: Andriy Gapon , Konstantin Belousov , FreeBSD Current References: <021d8df4-a4f8-620d-73b6-b6103d0bf7f1@FreeBSD.org> <199c8845-e42c-fbee-3f13-0b3d0d7234dc@FreeBSD.org> <20200526185528.GA48478@kib.kiev.ua> <114f788a-3947-0783-5472-173cf3a30d32@FreeBSD.org> <618658d9-b892-9255-2747-c5efbada0210@FreeBSD.org> <20200527084107.671238bb@titan.knownspace> From: Hans Petter Selasky Message-ID: <41192c31-f377-0517-5fa6-ec712313d7ea@selasky.org> Date: Wed, 27 May 2020 23:05:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200527084107.671238bb@titan.knownspace> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49XNfV1DPZz48Hf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.43 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-0.96)[-0.964]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-0.94)[-0.936]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.23)[-0.230]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[FreeBSD.org,gmail.com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 21:06:12 -0000 On 2020-05-27 15:41, Justin Hibbits wrote: > On Wed, 27 May 2020 06:27:16 -0700 > John Baldwin wrote: > >> On 5/27/20 2:39 AM, Andriy Gapon wrote: >>> On 27/05/2020 11:13, Andriy Gapon wrote: >>>> I added more diagnostics and it seems to support the idea that the >>>> problem is related to I/O cycles and bridges. >>>> >>>> ACPI timer suddenly starts returning 0xffffffff and that lasts for >>>> tens of microseconds before the timer goes back to returning >>>> normal values with an expected increase. >>>> AMD provides a proprietary way to access ACPI registers via MMIO >>>> (0xfed808xx). That mechanism is unaffected, ACPI timer register >>>> always returns good values. >>>> >>>> The problem seems to happen when restoring configuration of a >>>> particular PCI bridge. What's interesting is that the bridge >>>> decodes one memory range and one I/O range. >>>> >>>> Looking at pci_cfg_restore() I wonder if it is wise to restore >>>> PCIR_COMMAND so early. Could it be that after the resume the >>>> bridge is configured with a wrong I/O range (e.g., too wide) and >>>> by writing PCIR_COMMAND we enable that decoding. So, the bridge >>>> steals I/O cycles destined for ACPI support hardware. If there is >>>> nothing behind the bridge to handle those ports, then we get those >>>> bad readings. Once the bridge configuration is fully restored, the >>>> I/O handling goes back to normal. >>> >>> From what I see, this looks like a BIOS bug. >>> Upon resume, it swaps window configurations of pcib1 and pcib2 >>> (until FreeBSD restores them). pcib1 originally does not have an >>> I/O window. So, BIOS programs both base and limit of pcib2 I/O >>> window to zero. When FreeBSD writes its command register to >>> enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range. >>> That covers the ACPI ports at 0x8xx. >>> >>> Some printf-s. >>> From (verbose) boot time: >>> pcib1: domain 0 >>> pcib1: secondary bus 1 >>> pcib1: subordinate bus 1 >>> pcib1: memory decode 0xfea00000-0xfeafffff >>> pcib2: domain 0 >>> pcib2: secondary bus 2 >>> pcib2: subordinate bus 2 >>> pcib2: I/O decode 0xf000-0xffff >>> pcib2: memory decode 0xfe900000-0xfe9fffff >>> >>> My printf-s from resume time: >>> pcib1: old I/O base (low): 0xf1 >>> pcib1: old I/O base (high): 0x0 >>> pcib1: old I/O limit (low): 0x1 >>> pcib1: old I/O limit (high): 0x0 >>> pcib2: old I/O base (low): 0x1 >>> pcib2: old I/O base (high): 0x0 >>> pcib2: old I/O limit (low): 0x1 >>> pcib2: old I/O limit (high): 0x0 >> >> The "solution" I think is to have resume be multi-pass and to resume >> all the bridges first before trying to resume leaf devices (including >> timers), but that's a fair bit of work. It might be that we just >> need to resume timer interrupts later after the new-bus resume (I >> think we currently do it before?), though the reason for that was to >> allow resume methods in devices to sleep (I'm not sure if any do). >> > > That sounds like a good fit for https://reviews.freebsd.org/D203 . > Someone (TM) just needs to take it over the finish line... 6 years > later. Is this perhaps related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 --HPS