Created attachment 145301 [details] dmesg Hardware is a laptop with a Core i5 8250U and Intel GFX 620 running Coreboot. # turbostat --show Pkg%pc8 Pkg%pc8 80.72 80.72 # xset dpms force off wait a minute or so, then turn the screen back on # turbostat --show Pkg%pc8 Pkg%pc8 0.00 0.00 Powertop also confirms this. PC states 2 and below are never reached. All 5.3.0-RCs have this, 5.2.x all work well.
Created attachment 145302 [details] powertop before
Created attachment 145303 [details] powertop after
Created attachment 145304 [details] turbostat before
Created attachment 145305 [details] turbostat after
> All 5.3.0-RCs have this, 5.2.x all work well. A bisect will help us to find clues. Can you bisect?
I'm afraid I can't :-/
5.3 final also has this. Tried with a Skylake laptop this time (Xps15, 6700HQ). Could it be firmware related, 5.3 uses a different GuC.
Could you please try with i915.enable_guc=0 and let us know if behaviour is different?
Nailed it! No problem with i915.enable_guc=0 on both machines. Thanks.
Thanks for the feedback.(In reply to Radosław Szwichtenberg from comment #8) > Could you please try with i915.enable_guc=0 and let us know if behaviour is > different? (In reply to kitestramuort from comment #9) > Nailed it! No problem with i915.enable_guc=0 on both machines. > > Thanks. Thanks for the feedback.
I'm currently assessing this bug. But it looks to be a firmware problem.
This appears to be the same issue as fdo#111623. I have submitted a patch https://patchwork.freedesktop.org/patch/337552/ that is waiting for a review.
(In reply to Don Hiatt from comment #12) > This appears to be the same issue as fdo#111623. I have submitted a patch > https://patchwork.freedesktop.org/patch/337552/ that is waiting for a review. Your patch fixes this issue for me; I can get rc6 states on a CoffeeLake UHD620 after a resume now.
Doesn't fix it for me on KBL. The patch fixes the problem when I force the screen off, not when the laptop resumes from suspend. After suspend I have: GFX%rc6 5.45 5.45 Pkg%pc8 0.00 0.00
(In reply to kitestramuort from comment #14) > Doesn't fix it for me on KBL. > The patch fixes the problem when I force the screen off, not when the laptop > resumes from suspend. > > After suspend I have: > > GFX%rc6 > 5.45 > 5.45 > > Pkg%pc8 > 0.00 > 0.00 Suspend is what I'm using for this on kbl. I'll be posting a new patch later today and will update with the url. Are you changing the guc_enable without rebooting? (If so, check for error messages in dmesg). Can you please do fresh reboot and then post the output of this commands along with the dmesg. Thank you. modprobe i915 enable_guc=3 turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10 rtcwake -s 30 -m disk turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10
i915 is compiled in, along with the required firmware. Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 0.264710] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0) [ 0.276705] [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version 32.0) [ 0.284788] [drm] CT: enabled [ 0.305613] [drm] Initialized i915 1.6.0 20190619 for 0000:00:02.0 on minor 0 # turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10 10.004035 sec CPU%c7 GFX%rc6 Totl%C0 Any%C0 GFX%C0 96.69 99.06 4.74 4.13 0.32 95.04 99.06 4.74 4.13 0.32 97.03 97.29 97.41 # rtcwake -s 30 -m disk # turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10 10.002372 sec CPU%c7 GFX%rc6 Totl%C0 Any%C0 GFX%C0 96.35 5.20 7.43 6.78 80.83 91.77 5.20 7.43 6.78 80.83 99.09 96.83 97.71 The dreadful 5.20... After that... # turbostat --show Pkg%pc8 Pkg%pc8 0.00 0.00
(In reply to kitestramuort from comment #16) > i915 is compiled in, along with the required firmware. > > Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) > [ 0.264710] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin > (version 2.0) > [ 0.276705] [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version > 32.0) > [ 0.284788] [drm] CT: enabled > [ 0.305613] [drm] Initialized i915 1.6.0 20190619 for 0000:00:02.0 on > minor 0 > > # turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10 > 10.004035 sec > CPU%c7 GFX%rc6 Totl%C0 Any%C0 GFX%C0 > 96.69 99.06 4.74 4.13 0.32 > 95.04 99.06 4.74 4.13 0.32 > 97.03 > 97.29 > 97.41 > > # rtcwake -s 30 -m disk > > > # turbostat --quiet --show CPU%c7,GFX%rc6,Totl%C0,Any%C0,GFX%C0 sleep 10 > 10.002372 sec > CPU%c7 GFX%rc6 Totl%C0 Any%C0 GFX%C0 > 96.35 5.20 7.43 6.78 80.83 > 91.77 5.20 7.43 6.78 80.83 > 99.09 > 96.83 > 97.71 > > The dreadful 5.20... > After that... > # turbostat --show Pkg%pc8 > Pkg%pc8 > 0.00 > 0.00 What value of guc_enable are you giving? Also, this is what it looks like on KBL with drm-tip with the proper firmware. [ 213.513852] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 213.573467] [drm] GuC communication enabled [ 213.578063] i915 0000:00:02.0: GuC firmware i915/kbl_guc_33.0.0.bin version 33.0 submission:disabled [ 213.578065] i915 0000:00:02.0: HuC firmware i915/kbl_huc_4.0.0.bin version 4.0 authenticated:yes [ 213.579030] [drm] Initialized i915 1.6.0 20191007 for 0000:00:02.0 on minor 0 [ 213.581581] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
I'm working on a better way to determine if GuC submission is active per review comment, but v2 of the patch is: https://patchwork.freedesktop.org/patch/338019/
(In reply to Don Hiatt from comment #17) > What value of guc_enable are you giving? Also, this is what it looks like on > KBL with drm-tip with the proper firmware. > > [ 213.513852] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin > (v1.4) > [ 213.573467] [drm] GuC communication enabled > [ 213.578063] i915 0000:00:02.0: GuC firmware i915/kbl_guc_33.0.0.bin > version 33.0 submission:disabled > [ 213.578065] i915 0000:00:02.0: HuC firmware i915/kbl_huc_4.0.0.bin > version 4.0 authenticated:yes > [ 213.579030] [drm] Initialized i915 1.6.0 20191007 for 0000:00:02.0 on > minor 0 > [ 213.581581] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) I'm on the current stable kernel, 5.3.8. enable_guc is -1, which on this platform should be equivalent to 2. 5.3 only accepts guc 32.0.3 and huc 02 [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0) [ 116.266798] [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version 32.0) [ 116.266967] i915 0000:00:02.0: GuC firmware version 32.0 [ 116.266968] i915 0000:00:02.0: GuC submission disabled [ 116.266969] i915 0000:00:02.0: HuC enabled
(In reply to kitestramuort from comment #19) > (In reply to Don Hiatt from comment #17) > > What value of guc_enable are you giving? Also, this is what it looks like on > > KBL with drm-tip with the proper firmware. > > > > [ 213.513852] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin > > (v1.4) > > [ 213.573467] [drm] GuC communication enabled > > [ 213.578063] i915 0000:00:02.0: GuC firmware i915/kbl_guc_33.0.0.bin > > version 33.0 submission:disabled > > [ 213.578065] i915 0000:00:02.0: HuC firmware i915/kbl_huc_4.0.0.bin > > version 4.0 authenticated:yes > > [ 213.579030] [drm] Initialized i915 1.6.0 20191007 for 0000:00:02.0 on > > minor 0 > > [ 213.581581] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) > > I'm on the current stable kernel, 5.3.8. enable_guc is -1, which on this > platform should be equivalent to 2. 5.3 only accepts guc 32.0.3 and huc 02 > > [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0) > [ 116.266798] [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version > 32.0) > [ 116.266967] i915 0000:00:02.0: GuC firmware version 32.0 > [ 116.266968] i915 0000:00:02.0: GuC submission disabled > [ 116.266969] i915 0000:00:02.0: HuC enabled Yes, enable_guc = -1 is equivalent to 2. That said, I've been debugging this issue with drmtip and the latest firmware. So that seems to be the reason it is working for others and not you. BTW, just to confirm, you did apply the patch?
commit 82e0c5bbd6eb1d274b5a3e519ff0ab91f1f8e537 (HEAD -> drm-intel-next-queued, drm-intel/drm-intel-next-queued) Author: Don Hiatt <don.hiatt@intel.com> Date: Fri Nov 15 15:15:38 2019 -0800 drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC submission On some platforms (e.g. KBL) that do not support GuC submission, but the user enabled the GuC communication (e.g for HuC authentication) calling the GuC EXIT_S_STATE action results in lose of ability to enter RC6. We can remove the GuC suspend/resume entirely as we do not need to save the GuC submission status. Add intel_guc_submission_is_enabled() function to determine if GuC submission is active. v2: Do not suspend/resume the GuC on platforms that do not support Guc Submission. v3: Fix typo, move suspend logic to remove goto. v4: Use intel_guc_submission_is_enabled() to check GuC submission status. v5: No need to look at engine to determine if submission is enabled. Squash fix + intel_guc_submission_is_enabled() patch into one. v6: Move resume check into intel_guc_resume() for symmetry. Fix commit Fixes tag. Reported-by: KiteStramuort <kitestramuort@autistici.org> Reported-by: S. Zharkoff <s.zharkoff@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111594 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111623 Fixes: ffd5ce22faa4 ("drm/i915/guc: Updates for GuC 32.0.3 firmware") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceralo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomas Janousek <tomi@nomi.cz> Signed-off-by: Don Hiatt <don.hiatt@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191115231538.1249-1-don.hiatt@intel.com
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.