On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > Can we tell whether Windows rewrites this register unconditionally at > resume-time? If so, it may be more robust for Linux to do the same. > The whole thing is black magic, which I hate, but if it's our only > choice, it may be better to have this applied everywhere so we don't > keep stubbing our toes on new systems that require the quirk. Checked this with qemu adding a PCI-to-PCI bridge (ioh3420). $ qemu-system-x86_64 -enable-kvm -M q35,accel=kvm -m 2G -vga qxl -cpu host -hda testimg.img -device ioh3420,id=rp1,bus=pcie.0,addr=1c.0,port=1 -trace events=events.txt events.txt has: pci_cfg_read pci_cfg_write Logged cfg space accesses during boot: https://gist.github.com/dsd/135fb255cb2b237567d8ea2d6bfc6917#file-boot-txt Suspend: https://gist.github.com/dsd/135fb255cb2b237567d8ea2d6bfc6917#file-suspend-txt Resume: https://gist.github.com/dsd/135fb255cb2b237567d8ea2d6bfc6917#file-resume-txt Notably during resume, the prefetch-related registers get rewritten: pci_cfg_write ioh3420 28:0 @0x24 <- 0xfeb0fea0 pci_cfg_write ioh3420 28:0 @0x28 <- 0x0 pci_cfg_write ioh3420 28:0 @0x2c <- 0x0 This happened even though there was nothing behind the bridge. Windows failed to resume in this test (black screen) but the traced register writes seem indicative enough. Peter Wu confirms the same results in a similar experiment: https://marc.info/?l=linux-pci&m=153616336225386&w=2 I'll look into creating a new patch that unconditionally reprograms the PCI bridge prefetch stuff on resume. Thanks Daniel
