Summary: | [SKL-Y] Can't reach deepest state than pc2 | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | cprigent <christophe.prigent> | ||||||||||||||||||||||||||||||||||||||||||||||||
Component: | DRM/Intel | Assignee: | cprigent <christophe.prigent> | ||||||||||||||||||||||||||||||||||||||||||||||||
Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||||||||||||||||||||||||||||||
Severity: | critical | ||||||||||||||||||||||||||||||||||||||||||||||||||
Priority: | high | CC: | imre.deak, intel-gfx-bugs | ||||||||||||||||||||||||||||||||||||||||||||||||
Version: | unspecified | ||||||||||||||||||||||||||||||||||||||||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||||||||||||||||||||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||||||||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||||||||||||||||||||||||||||
i915 platform: | SKL | i915 features: | power/runtime PM | ||||||||||||||||||||||||||||||||||||||||||||||||
Attachments: |
|
Description
cprigent
2015-11-20 10:13:28 UTC
Created attachment 119972 [details]
kern.log.tar.gz
(In reply to cprigent from comment #1) > Created attachment 119972 [details] > kern.log.tar.gz For power state residency problems could you please always provide also the output of the followings, captured at the moment where you expect some non-zero residency (all ran as root): lspci -vvk lsmod for d in /sys/devices/pci*/0*; do \ grep . $d/power/{control,runtime_usage,runtime_suspended_time}; \ done sleep 5 for d in /sys/devices/pci*/0*; do \ grep . $d/power/{control,runtime_usage,runtime_suspended_time}; \ done cat /sys/kernel/debug/dri/0/i915_power_domain_info cat /sys/kernel/debug/dri/0/i915_dmc_info <linux_src>/tools/power/x86/turbostat --debug sleep 5 Also please retest with the latest DMC firmware: [ 8.678838] [drm:intel_csr_ucode_init] Loading i915/skl_dmc_ver1.bin [ 8.687031] [drm] Refusing to load old Skylake DMC firmware v1.22, please upgrade to v1.23 or later [https://01.org/linuxgraphics/intel-linux-graphics-firmwares]. [ 8.687094] [drm:csr_load_work_fn [i915]] *ERROR* Failed to load DMC firmware, disabling rpm Created attachment 119974 [details]
i915_dmc_info
Created attachment 119975 [details]
i915_power_domain_info
Created attachment 119976 [details]
lsmod
Created attachment 119977 [details]
lspci -vvk
Created attachment 119978 [details]
pci_runtime_status
For the VGA PCI controller not suspending: https://bugs.freedesktop.org/show_bug.cgi?id=93016 Created attachment 119984 [details]
turbostat
Reproduced with firmware DMC 1.23 (In reply to cprigent from comment #11) > Reproduced with firmware DMC 1.23 But now runtime PM actually got enabled, it's a completely new scenario, so we need a new capture of dmesg, and the rest of debug output from comment 2. Created attachment 119990 [details]
lspci -vvk
Created attachment 119991 [details]
lsmod
Created attachment 119992 [details]
turbostat
Created attachment 119993 [details]
pci_runtime_status
Created attachment 119994 [details]
report.html
Created attachment 119995 [details]
kern_dmc1.23.log
(In reply to cprigent from comment #18) > Created attachment 119995 [details] > kern_dmc1.23.log You forgot to add cat /sys/kernel/debug/dri/0/i915_power_domain_info and cat /sys/kernel/debug/dri/0/i915_dmc_info You left an easter-egg for me in your dmesg:) Nov 20 04:34:41 SKLY-8 kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-rc1-nightly+ root=UUID=984d322b-a35a-40bc-9ca6-f6d395aae9f6 ro Nov 20 05:56:25 SKLY-8 kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-rc1-nightly+ root=UUID=984d322b-a35a-40bc-9ca6-f6d395aae9f6 ro init=/sbin/upstart i915.disable_power_well=1 Nov 20 06:26:45 SKLY-8 kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-rc1-nightly+ root=UUID=984d322b-a35a-40bc-9ca6-f6d395aae9f6 ro init=/sbin/upstart drm.debug=0xe i915.disable_power_well=1 Nov 20 06:30:58 SKLY-8 kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-rc1-nightly+ root=UUID=984d322b-a35a-40bc-9ca6-f6d395aae9f6 ro init=/sbin/upstart drm.debug=0xe i915.disabe_power_well=1 The last one has a typo, which of course will keep power wells disabled. Please retest correcting the parameter. Created attachment 120057 [details]
i915_dmc_info
Created attachment 120058 [details]
i915_power_domain_info
Created attachment 120059 [details]
kern.log
Created attachment 120060 [details]
lsmod
Created attachment 120061 [details]
lspci -vvk
Created attachment 120062 [details]
pci_runtime_status
Created attachment 120063 [details]
report.html
Created attachment 120064 [details]
turbostat
Yes, I confirm the typo. Now PCI VGA controler successfully suspends. I still see residency only in PC2 state. New logs attached. Created attachment 120068 [details] [review] Patch to enable AHCI ALPM accounting (In reply to cprigent from comment #29) > Yes, I confirm the typo. Now PCI VGA controler successfully suspends. > I still see residency only in PC2 state. New logs attached. Ok, thanks for the report. It looks like from our side things are fine, we runtime suspend and enable DC6. We get DC5 residency, but not DC6. AFAIK this is because DC6 is allowed only once the PCU determines that everything else is ready for PC9/10, or some other system-wide condition prevents PCU from signaling DC6 readiness. In general it'll be difficult for us GFX team to ensure that everything else is correct for system power states. It does work now on a couple of machines here, so I guess we can give it a go, but we may need to reconsider testing system power states if independent components will break too often. I have two ideas what can go wrong on your machine: SSD and LPSS. To see if it's the SSD please apply the ALPM accounting patch and rerun/reattach the powertop --html. For LPSS please make sure you have the following enabled in your kconfig, I see that you don't have the corresponding driver loaded now, and it's not runtime suspended: CONFIG_MFD_INTEL_LPSS=y CONFIG_MFD_INTEL_LPSS_ACPI=y CONFIG_MFD_INTEL_LPSS_PCI=y If these don't help, some more random ideas, you could try them one-at-a-time: - Please make sure everything is disconnected (I saw you did this for most things already) - Reset the BIOS to default settings and enable 'ACPI Settings'/'Low Power S0 Idle Capability' - Try to disable devices in BIOS. Few suggestions: - run: sudo powertop --auto-tune - Remove wireless card - Unplug all USBs - Make sure you have a recent SSD with ALPM support as Imre mentioned. Bug scrub: Assigned to me to check last comments and try with different SSD Christophe, any update on this? Any change that QA could validate? I will check using a production device Not reproduced on a SKL NUC. PC8 is reached at step 3. Platform: NUC6i3SYH CPU: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHZ (family 6, model 78, stepping 3) Motherboard version: H81132-502 GPU: Intel Corporation Sky Lake Integrated Graphics (rev 07) Software Bios: SYSKLi35.86A.0024.2015.1027.2142 Linux distribution: Ubuntu 15.10 64 bits Kernel: drm-intel-nightly 4.4.0 8fe9e78 from http://cgit.freedesktop.org/drm-intel commit 8fe9e785ae04fa7c37f7935cff12d62e38054b60 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Thu Jan 21 11:03:06 2016 +0000 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest drm: tag libdrm-2.4.66 e342c0f from http://cgit.freedesktop.org/mesa/drm/ mesa: tag mesa-11.0.8 261daab from http://cgit.freedesktop.org/mesa/mesa/ cairo: tag 1.15.2 db8a7f1 from http://cgit.freedesktop.org/cairo waffle: master bb29b2a from https://github.com/waffle-gl/waffle xorg-server-macros: master d7acec2 from git://git.freedesktop.org/git/xorg/util/macros libva: tag libva-1.6.1 cb418f6 from http://cgit.freedesktop.org/libva/ vaapi-intel-driver: tag 1.6.1 2110b3a from http://cgit.freedesktop.org/vaapi/intel-driver PowerTop 2.8 180ac4f from https://github.com/fenrus75/powertop.git So closed |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.