Bug 53393

Summary:

[Bisected (sort of) SNB regression] rc6 never happening

Product:

DRI

Reporter:

Ben Widawsky <ben>

Component:

DRM/Intel

Assignee:

Daniel Vetter <daniel>

Status:

CLOSED FIXED

QA Contact:

Severity:

major

Priority:

medium

CC:

ben, chris, daniel, jbarnes

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
use hsw rps thresholds	none

Description Ben Widawsky 2012-08-12 05:47:53 UTC

While trying to reproduce the supposed semaphore related power regression in 3.5, I recovered a long forgotten Toshiba laptop. Not surprisingly, I couldn't reproduce any regression related to semaphores but instead found out that I was never entering RC6.

A bisect revealed 7b0cfee1a24efdfe0235bac62e53f686fe8a8e24 to be the guilty commit. Unfortunately, this is merely a merge commit that required manual conflict resolution, and I think git bisect isn't doing what I want in this case.

The failure can be reproduced with intel-gpu-tools/tests/sysfs_rc6_residency. The issue causes somewhere between 4W-8W regression in idle cases.

The exact model number is Toshiba Satellite A665-S5185 with a pci id of 0x116.

Comment 1 Ben Widawsky 2012-08-12 05:48:41 UTC

I forgot to mention, I've tried to reproduce on 2 other SNB laptops and had no success.

Comment 2 Daniel Vetter 2012-08-13 15:46:11 UTC

Created attachment 65500 [details] [review]
use hsw rps thresholds

Shot in the dark, please test.

Comment 3 Ben Widawsky 2012-08-13 18:32:20 UTC

Patch works for me. Assigning to you.

Comment 4 Chris Wilson 2012-08-13 18:35:55 UTC

Good to know... But do we have a theory that could account for the apparent regression? Why is the GPU waking up more often to keep the rp upclocked?

Comment 5 Ben Widawsky 2012-08-13 18:44:57 UTC

(In reply to comment #4)
> Good to know... But do we have a theory that could account for the apparent
> regression? Why is the GPU waking up more often to keep the rp upclocked?

I have none. TBH, I was pretty certain the patch wouldn't fix anything.

Comment 6 Daniel Vetter 2012-08-13 18:57:34 UTC

I have to admit that I didn't expect this to fix anything, either.

Since the patch touches the rps limits, not the rc6 limits.

Can we go into the zoo instead and watch the real elephants there for a change?

Comment 7 Ben Widawsky 2012-08-13 23:10:00 UTC

I have learned something really disheartening. Upon Daniel's request to try all the semaphore combinations on the bisect commit I've learned that the issue is indeed intermittent. On drm-intel-next-2012-06-21-merged, I see working RC6 approximately 1/6 times. 

I guess I have more work to do in order to find out what is actually going on.

Comment 8 Ben Widawsky 2012-08-13 23:28:37 UTC

Also, gpu reset doesn't seem to flip the results one way or another (ie. if it's working it remains good, and if it isn't, blap).

Comment 9 Ben Widawsky 2012-08-14 00:03:35 UTC

Parent of -merged-06-21 (9756fe38d) /appears/ to be stable, as in, it works properly.

9756fe38d seems to work fine both with, and without semaphores.

Comment 10 Ben Widawsky 2012-08-14 23:11:12 UTC

Ok. The patch seems to make all problems go away, both with, and without semaphores. I say we merge it.

Tested-by: Ben Widawsky <ben@bwidawsk.net>

Comment 11 Daniel Vetter 2012-08-22 09:09:23 UTC

Patch merged to -fixes:

commit 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 15 10:41:45 2012 +0200

    drm/i915: use hsw rps tuning values everywhere on gen6+

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.