Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

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