Re: [Intel-gfx] Skylake 6700k Intel HD Graphics 530 Display Port Panic
Just to update, this also happens with the latest current git://anongit.freedesktop.org/drm-intel kernel on the drm-intel-nightly branch. On 2015-09-06 06:05, Matthew Minter wrote: Hello, I am currently trying to set up a newly built system with a Skylake 6700k CPU but am having an extremely reproducible kernel panic every time I connect a monitor to the display port connector of the Intel integrated graphics chip. This issue occurs either immediately upon connecting a display port monitor to the machine while it is up or late in the boot process if the display port is connected at boot time. The monitor which I am using is a Dell U3415W ultra wide and the motherboard is a MSI Z170A Gaming M7. I am not entirely surprised by the link train errors as there appear to be various posts about users having problems with this monitor and display port training, what surprises me most is the fact it is causing a kernel panic. Upon the panic happening the kernel prints the following dump (to the second non DP monitor), (note this is hand copied as I have no way to dump the messages anywhere but the display so pardon any small typos). [ 22.318630] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.365449] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.420272] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.475105] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.529931] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.584759] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.639588] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.649935] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.650532] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 24.329955] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 25.345911] Shutting down cpus with NMI [ 25.356092] Kernel offset: disabled [ 25.356101] Rebooting in 30 seconds. If running kernel 4.2 occasionally these errors are followed by what seems to be a an mce machine check exception mentioning a corrupt processor context which is very hard to note down as it is only on the screen very briefly. However if running the latest kernel from https://github.com/torvalds/linux only the above error occurs, not the mce exception. I am pretty confident the mce exception is spurious due to this and the fact the system otherwise tests out fine. I apologise if this report is a little sparse on details, it is very hard to post mortem debug the system due to the panic and the fact I have no available serial terminal or hardware debugger. Otherwise the system flawlessly passes memtest86+ and is completely stable even under heavy load. This issue seems to occur on every kernel I have tested so far including a stock ubuntu 15.4, a vanilla 4.0.5 kernel, a vanilla 4.2.0 kernel and the head of https://github.com/torvalds/linux as of a few hours ago. The kernel config used for the kernel taken from git is available here: http://paste2.org/MH9vV4Le The 4.2 and 4.0.5 configs were extremely similar and only differ in the new entries made by oldconfig. If there is anything I can do to produce more info I am more than happy to do so. Or if this is not the right mailing list for this issue please let me know where would be better. Many thanks, Matthew ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Skylake 6700k Intel HD Graphics 530 Display Port Panic
Hello, I am currently trying to set up a newly built system with a Skylake 6700k CPU but am having an extremely reproducible kernel panic every time I connect a monitor to the display port connector of the Intel integrated graphics chip. This issue occurs either immediately upon connecting a display port monitor to the machine while it is up or late in the boot process if the display port is connected at boot time. The monitor which I am using is a Dell U3415W ultra wide and the motherboard is a MSI Z170A Gaming M7. I am not entirely surprised by the link train errors as there appear to be various posts about users having problems with this monitor and display port training, what surprises me most is the fact it is causing a kernel panic. Upon the panic happening the kernel prints the following dump (to the second non DP monitor), (note this is hand copied as I have no way to dump the messages anywhere but the display so pardon any small typos). [ 22.318630] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.365449] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.420272] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.475105] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.529931] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.584759] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.639588] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.649935] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 22.650532] [drm:intel_dp_start_link_traln [i915]] *ERROR* too many full retries, give up [ 24.329955] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 25.345911] Shutting down cpus with NMI [ 25.356092] Kernel offset: disabled [ 25.356101] Rebooting in 30 seconds. If running kernel 4.2 occasionally these errors are followed by what seems to be a an mce machine check exception mentioning a corrupt processor context which is very hard to note down as it is only on the screen very briefly. However if running the latest kernel from https://github.com/torvalds/linux only the above error occurs, not the mce exception. I am pretty confident the mce exception is spurious due to this and the fact the system otherwise tests out fine. I apologise if this report is a little sparse on details, it is very hard to post mortem debug the system due to the panic and the fact I have no available serial terminal or hardware debugger. Otherwise the system flawlessly passes memtest86+ and is completely stable even under heavy load. This issue seems to occur on every kernel I have tested so far including a stock ubuntu 15.4, a vanilla 4.0.5 kernel, a vanilla 4.2.0 kernel and the head of https://github.com/torvalds/linux as of a few hours ago. The kernel config used for the kernel taken from git is available here: http://paste2.org/MH9vV4Le The 4.2 and 4.0.5 configs were extremely similar and only differ in the new entries made by oldconfig. If there is anything I can do to produce more info I am more than happy to do so. Or if this is not the right mailing list for this issue please let me know where would be better. Many thanks, Matthew ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func
On 9/4/2015 8:17 PM, Daniel Vetter wrote:
On Fri, Sep 04, 2015 at 06:56:15PM +0530, Sonika Jindal wrote:
If the same port is enumerated as hdmi as well as DP, this will get
called for DP connector as well which is not required because
i915_hotplug_work_func is solely to handle hdmi HPD.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..8e1c43e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -325,7 +325,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
list_for_each_entry(connector, &mode_config->connector_list, head) {
intel_connector = to_intel_connector(connector);
- if (!intel_connector->encoder)
+ if (!intel_connector->encoder
+ && connector->connector_type !=
DRM_MODE_CONNECTOR_HDMIA)
continue;
Pretty sure this breaks hotplug detection for everything but HDMI (since
now nothing but hdmi gets called it's ->detect function, and only if that
signals a status change will we send out an uevent to userspace). Does
this really not break DP hotplug?
Yes we probe both hdmi and DP always, and probably we could be more
intelligent with the fallback between the too. But this here doesn't seem
to be the right solution.
-Daniel
Hmm :(
This doesn't allow detect to be called for dp. I missed the part that
hpd_pulse only handles mst. From the name and comments it looks like it
should handle hpd for dp completely. I think this this code needs some
refactoring.
For now, I think I better move this check to intel_encoder->hot_plug
function because for the connectors with dp and hdmi both, this hot_plug
hook gets called twice.
intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Add NV12 to primary plane programming.
On Sat, Sep 05, 2015 at 01:10:11AM +, Konduru, Chandra wrote:
> > > +
> > > + if (fb->pixel_format == DRM_FORMAT_NV12) {
> > > + int height_in_mem = (fb->offsets[1]/fb->pitches[0]);
> > > + /*
> > > + * If UV starts from middle of a page, then UV start
> > should
> > > + * be programmed to beginning of that page. And offset
> > into that
> > > + * page to be programmed into y-offset
> > > + */
> > > + tile_row_adjustment = height_in_mem % tile_height;
> > > + aux_dist = fb->pitches[0] * (height_in_mem -
> > tile_row_adjustment);
> > > + aux_x_offset = DIV_ROUND_UP(x, 2);
> > > + aux_y_offset = DIV_ROUND_UP(y, 2) +
> > tile_row_adjustment;
> > > + /* For tile-Yf, uv-subplane tile width is 2x of
> > > Y-subplane
> > */
> > > + aux_stride = fb->modifier[0] ==
> > I915_FORMAT_MOD_Yf_TILED ?
> > > + stride / 2 : stride;
> >
> > The 2x part was rather well hidden in the spec. How do we deal with
> > cases when the Y stride is an odd number of tiles?
>
> It should be a round up division to take care of that scenario.
That would stil lresult in a corrupted picture I think. So I was
thinking that we should just refuse to create NCV12 framebuffers with a
poorly aligned stride.
> Fixing this and resolving your other comments.
> Will be sending updated patches shortly.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds
On Sat, Sep 05, 2015 at 01:28:56AM +, Konduru, Chandra wrote:
> > > +
> > > + if (((IS_SKYLAKE(dev) && intel_get_stepping(dev) == 'C') ||
> > > + (IS_BROXTON(dev) && intel_get_stepping(dev) == 'A')) &&
> > > + fb->pixel_format == DRM_FORMAT_NV12) {
> > > + I915_WRITE(CHICKEN_PIPESL(pipe),
> > > + I915_READ(CHICKEN_PIPESL(pipe)) |
> > DISABLE_STREAMER_FIX);
> > > + }
> >
> > According to Bspec this would need to be disabled for render
> > compression. And to do that we'd need to add some vblank waits to make
> > sure we don't disable it too soon. But since it's pre-production
> > hardware anyway I guess we might not care too much.
>
> Render compression related checks will be coming as part of that patch.
>
> >
> > I would probably drop SKL from these since I'd assume almost everyone
> > has D+ by now. And maybe just stuff it in init_clock_gating for BXT
> > since we're going to eliminate it soonish anyway.
>
> Last checked some folks are still using, so keep it intact for completeness.
>
> > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> > > + int pipe, int enable)
> > > +{
> > > + if (pipe == PIPE_A || pipe == PIPE_B) {
> > > + if (enable)
> > > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > > + DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> > > + else
> > > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > > + I915_READ(CLKGATE_DIS_PSL(pipe) &
> > > + ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS)));
> > > + }
> > > +}
> > > +
> > > static void haswell_crtc_enable(struct drm_crtc *crtc)
> > > {
> > > struct drm_device *dev = crtc->dev;
> > > @@ -5094,6 +5119,9 @@ static void haswell_crtc_enable(struct drm_crtc
> > *crtc)
> > > intel_wait_for_vblank(dev, hsw_workaround_pipe);
> > > intel_wait_for_vblank(dev, hsw_workaround_pipe);
> > > }
> > > +
> > > + /* workaround for NV12 */
> > > + skl_wa_clkgate(dev_priv, pipe, 1);
> >
> > I wonder what's the cost of having this
> > a) always enabled
> > b) enabled when the pipe is enabled
> > c) enabled only when NV12 is used
> > ?
>
> Initially optimized to enable only when nv12 is used,
> but there are some corner cases when planes switch to and
> from nv12 to non-nv12 and SV recommendation is to enable
> always; and SV evaluated cost, and it isn't a big concern.
So, based on that we could just stuff it into init_clock_gating and
forget about it.
But we'll run into problems as soon as render compression enters the
picure. But I don't have a problem leaving it up to the render
compression patches to solve.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add 90/270 rotation for NV12 format.
On Sat, Sep 05, 2015 at 01:38:14AM +, Konduru, Chandra wrote:
> > > /* Adjust (macro)pixel boundary */
> > > if (fb && intel_format_is_yuv(fb->pixel_format)) {
> > > - to_intel_plane_state(plane_state)->src.x1 &= ~0x1;
> > > - to_intel_plane_state(plane_state)->src.x2 &= ~0x1;
> > > + if (intel_rotation_90_or_270(plane_state->rotation)) {
> > > + to_intel_plane_state(plane_state)->src.y1 &=
> > ~0x1;
> > > + to_intel_plane_state(plane_state)->src.y2 &=
> > ~0x1;
> > > + } else {
> > > + to_intel_plane_state(plane_state)->src.x1 &=
> > ~0x1;
> > > + to_intel_plane_state(plane_state)->src.x2 &=
> > ~0x1;
> > > + }
> >
> > IIRC we concluded (with Art's help) that this is not needed. We always
> > want to align in src.x.
>
> Initial code that I added was making both X and Y offsets as even
> when 90/270 as per bspec at that time.
>
> But later Art update is as below:
> >> " the X offset must always be even for YUV422+NV12, and
> >> the Y offset must be even when rotated 90/270 degrees."
>
> So, above code change is needed.
That's the orignal text, later update from Art was:
"They don't both have to be even when roated. The text should say " the
X offset must be even for YUV422+NV12 ***when not rotated 90/270***, and
the Y offset must be even when rotated 90/270 degrees.""
And the spec has been updated since to include the same information. For
us we just need to align src.x? since that's what gets programmed into
the X offset for 0/180, and into the Y offset for 90/270. So the current
code is fine as is.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
