Bug 66808

(In reply to comment #0)
> Bisect shows:The first bad commit could be any of:
> 035dc1e0f9008b48630e02bf0eaa7cc547416d1d
> 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e
> bf51d5e2cda5d36d98e4b46ac7fca9461e512c41

Have you used git skip or why exactly could bisect not nail down the commit further?

The first two patches should be unrelated, but the 3rd one changes the default for power wells on haswell. Can you please retest latest -nightly with i915.disable_power_well=0 added to your kernel cmdline?

Also is the failure exactly reproducible, i.e. when running this subtest it always fails with this output?


Beginning blocking-absolute-wf_vblank on crtc 5, connector 9
  1920x1200 60 1920 1968 2000 2080 1200 1203 1209 1235 0x9 0x48 154000
.run_test_step:749 failed, ret=-16, errno=16
Aborted (core dumped)

The important part is "crtc 5, connector 9". If the failure happens when testing other crtcs/connectors (on this specific machine, connectors are not numbered the same way depending upon the exact board configuratino) this would be very important to know.

Note to self: Connector 9 here is VGA on the LPT pch.

The likely cause of EBUSY here requires drm.debug=7 for the error message to be printed to dmesg. Can you please do a run with drm.debug=7?

Created attachment 82357 [details]
dmesg with drm.debug=7

Test on latest nightly kernel with i915.disable_power_well=0, This issue goes away.

revert bf51d5e2cda5d36d98e4b46ac7fca9461e512c41, this issue goes away.
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Jul 3 17:12:13 2013 -0300

    drm/i915: switch disable_power_well default value to 1

    Now that the audio driver is using our power well API, everything
    should be working correctly, so let's give it a try.

    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

One for Paulo to figure out. Worst case we need to disable the power well again in 3.11.

But why is this also a regression on Pineview? Makes no sense to me.

(In reply to comment #5)
> But why is this also a regression on Pineview? Makes no sense to me.

Iirc we already have a pnv bug for soemthing similar. If not, please file a new one, since this issue here is clearly haswell related.

It has Bug 60002 on PNV.

Problem also happens if I use eDP+DP instead of eDP+VGA. When it tries DP1 on CRTC 1, it fails. I'll keep investigating.

For the very first time we run the test on pipe B, it works. After the power well is reset for the first time, the test on pipe B starts to fail and keeps failing forever.

Considering that the problem doesn't happen with i915.disable_power_well=0, I wonder if the bug is related to the fact that the pipe counters go back to 0 after we disable the power well (PIPE_FRMCNT, etc). Or maybe it's related to other registers that get reset.

(In reply to comment #9)
> For the very first time we run the test on pipe B, it works. After the power
> well is reset for the first time, the test on pipe B starts to fail and
> keeps failing forever.
> 
> Considering that the problem doesn't happen with i915.disable_power_well=0,
> I wonder if the bug is related to the fact that the pipe counters go back to
> 0 after we disable the power well (PIPE_FRMCNT, etc). Or maybe it's related
> to other registers that get reset.

Yeah, if I set dev->last_vblank[1] = 0; and dev->last_vblank[2] = 0; at the !enable case inside __intel_set_power_well, the problem goes away. Now we need to discover what's the correct way to reset these counters without messing with the drm helpers or the vblank locking.

Created attachment 82845 [details] [review]
possible fix

Hi

Can you please try this patch and repor the result? If fixes the problem on my machine.

Thanks,
Paulo

(In reply to comment #11)
> Created attachment 82845 [details] [review] [review]
> possible fix
> 
> Hi
> 
> Can you please try this patch and repor the result? If fixes the problem on
> my machine.
> 
> Thanks,
> Paulo

Fixed by this patch.

Patch merged, closing bug.

http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=9dbd8febb4dbc9199fcf340b882eb930e36b65b6

Thanks,
Paulo

Verified.Fixed.

Closing old verified.