On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > If true, this sounds like some sort of erratum, so it would be good to > get some input from Intel, and I cc'd a few Intel folks. Yes, it would be great to get their input. > It's interesting that all the systems below are from Asus. That makes > me think there's some BIOS or SMM connection, e.g., SMM traps the > register write and does something magic. Is there a way I can check if there is a SMM trap active for this address? > Does this problem happen after a full system suspend/resume, or does > it happen after runtime suspend of only the GPU? Or runtime suspend > of only the GPU and the upstream bridge? runtime suspend/resume works fine. It only happens after S3 suspend. > 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. Any suggestions for how to make this happen? Booting windows in virt-manager (hoping that I could then spy on PCI config space reg accesses), I don't see an option for S3 suspend, but I'll keep looking into this. Thanks Daniel
