[Bug 86201] [VLV Bisected] Delayed boot and distorted text console after commit 773538e8

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86201

--- Comment #8 from Egbert Eich <eich at pdx.freedesktop.org> ---
(In reply to Ville Syrjala from comment #5)

> The log is from an older kernel since it doesn't have the port information
> in the vdd debug messages. But I guess you're sayng it still happens with
> the more recent kernels too.

The dump was from the very version that introduced this regression but I'm
seeingthe same behavior on recent intel nightly kernels (as of last week). 
I will generate more dumps on more recent kernels.

> 
> Apart from the massive delay there's one other WTF in the logs:
> [    3.840671] [drm:intel_dp_init_panel_power_sequencer_registers] panel
> power sequencer register settings: PP_ON 0x87d00001, PP_OFF 0x1f40001,
> PP_DIV 0x270f06
> [    5.068936] [drm:intel_dp_init_panel_power_sequencer_registers] panel
> power sequencer register settings: PP_ON 0x80000001, PP_OFF 0x1, PP_DIV
> 0x270f00
> 
> I'm left wondering what happened to the delays we had in those registers.
> Somehow they got zeroed after we already computed them to !=0 values.
> Althoguh that issue was already present in the "good" log.

Right. I did notice those delays as well hadn't paid much attention to them,
yet so I didn't check the logs for them explicitly.

As it looks like a v3.13 kernel (with a regression fix for DP on top) is the
most stable version on this hardware. I've seen other regressions introduced
before the mentioned patch (for instance even without this patch the fb console
is not entirely stable) but I haven't bisected these, yet.

> Also can you make edp_panel_vdd_on() dump a backtrace so we can see where
> it's coming from. I guess it's some AUX stuff (EDID read perhaps). I can't
> see why it would suddenly take forever. Especially since it doesn't appear
> to time out or anything.

Will do!

> I don't see any "disabling display" power well debug messages in the log, so
> at least resetting pps_pipe doesn't seem to happen anywhere. The other part
> of the patch adds the power_domain get/put around the pps_mutex, but since
> we have init power enabled here, these should be mostly nops. It does mean
> we grab and release the power domain mutex a few extra times as well, so
> there's some overhead, but I would think there would have to some serious
> contention on the lock to get this kind of effect.
> 
> Sadly I can't reproduce this here.

I will play with this some more and also check more recent kernels.

(In reply to Ville Syrjala from comment #6)
> Created attachment 109670 [details] [review]
> [PATCH] drm/i915: Try to avoid pps_{lock,unlock}() on DP ports
> 
> Attempt at reducing the locking overhead for regular DP AUX transfers.
> 
> In case the extra locking we now do is really the culprit, can you test this
> one?

Sure!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141120/37accb94/attachment-0001.html>