Date: Wed, 27 May 2020 11:13:08 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <current@FreeBSD.org> Subject: Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time] Message-ID: <114f788a-3947-0783-5472-173cf3a30d32@FreeBSD.org> In-Reply-To: <b6f5429a-fa0b-3d85-1250-a11807757ef7@FreeBSD.org> References: <021d8df4-a4f8-620d-73b6-b6103d0bf7f1@FreeBSD.org> <199c8845-e42c-fbee-3f13-0b3d0d7234dc@FreeBSD.org> <20200526185528.GA48478@kib.kiev.ua> <b6f5429a-fa0b-3d85-1250-a11807757ef7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/05/2020 01:14, John Baldwin wrote: > On 5/26/20 11:55 AM, Konstantin Belousov wrote: >> On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote: >>> I am not sure if this is just a coincidence but it appears as if a write to some >>> PCI configuration register could temporarily interfere with access to the PM >>> timer I/O port. >>> Is that plausible? >> If something disabled a BAR, then typical response of x86 chipset for timed >> out read from PCIe is 0xfffff... . > > And the ACPI timer might be "behind" the isab0 bridge device which would indeed > cause this. 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. Is this possible? P.S. pci_cfg_restore() also attempts to restore PCIR_INTPIN, but it's read-only? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?114f788a-3947-0783-5472-173cf3a30d32>