On Thu, Oct 05, 2023 at 05:57:52PM +0200, Thomas Witt wrote: > On 05/10/2023 17:30, Bjorn Helgaas wrote: > ... > > Right, without the denylist, I expect Thomas' TUXEDO to fail, but I > > still hope we can figure out why. If we just keep it on the denylist, > > that system will suffer from more power consumption than necessary, > > but only after suspend/resume. > > > > A denylist seems like the absolute last resort. In this case we don't > > know about anything *wrong* with those platforms; all we know is that > > our resume path doesn't work. It's likely that it fails on other > > platforms we haven't heard about, too. > > The best guess from Mika and David was a firmware issue, but I run the same > Firmware revision as Werner. I even reflashed the Firmware, but that did not > change anything: Possibly a BIOS settings difference? > Quoting David Box: > > I agree that we should pursue an exception for your system. This is > > looking like a firmware bug. One thing we did notice in the turbostat > > results is your IRTL (Interrupt Response Time Limit) values are bogus: > > > > cpu6: MSR_PKGC3_IRTL: 0x0000884e (valid, 79872 ns) > > cpu6: MSR_PKGC6_IRTL: 0x00008000 (valid, 0 ns) > > cpu6: MSR_PKGC7_IRTL: 0x00008000 (valid, 0 ns) > > cpu6: MSR_PKGC8_IRTL: 0x00008000 (valid, 0 ns) > > cpu6: MSR_PKGC9_IRTL: 0x00008000 (valid, 0 ns) > > cpu6: MSR_PKGC10_IRTL: 0x00008000 (valid, 0 ns) > > > > This is despite the PKGC configuration register showing that all > > states are enabled: > > > > cpu6: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3, UNdemote-C1, > demote- > C3, demote-C1, locked, pkg-cstate-limit=8 (unlimited)) > > > > Firmware sets this. I can't find this discussion, but if there's a firmware issue related to IRTL MSRs, I would want the workaround in intel-idle.c or whatever code deals with the MSRs, not in the ASPM code. Bjorn
