Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Tue, Oct 20, 2015 at 03:33:27PM +1000, Dave Airlie wrote:
 > On 20 October 2015 at 07:54, Daniel Vetter  wrote:
 > > On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
 > >> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
 > >>
 > >>  > > The warning on boot seems to be gone as of rc3, but I can now 
 > >> trigger this pretty easily..
 > >>  >
 > >>  > http://patchwork.freedesktop.org/patch/60618/
 > >>
 > >> Back from several weeks of travel..  I tried again with rc6, and
 > >> I'm still seeing the same traces.
 > >
 > > Oh crap, applied patch to wrong tree. We need to cherry-pick
 > >
 > > commit 621bd0f6982badd6483acb191eb7b6226a578328
 > > Author: Daniel Vetter 
 > > Date:   Tue Sep 29 09:56:53 2015 +0200
 > >
 > > drm: Fix locking for sysfs dpms file
 > >
 > > to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
 > > even comes with the needed cc: stable included (since the locking breakage
 > > was done in 4.0, it only surface due to a new warning in 4.3).
 > 
 > That is already in Linus's tree, I picked it last week I think.

Yeah, that's in the tree I'm testing.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Tue, Oct 20, 2015 at 03:33:27PM +1000, Dave Airlie wrote:
 > On 20 October 2015 at 07:54, Daniel Vetter  wrote:
 > > On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
 > >> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
 > >>
 > >>  > > The warning on boot seems to be gone as of rc3, but I can now 
 > >> trigger this pretty easily..
 > >>  >
 > >>  > http://patchwork.freedesktop.org/patch/60618/
 > >>
 > >> Back from several weeks of travel..  I tried again with rc6, and
 > >> I'm still seeing the same traces.
 > >
 > > Oh crap, applied patch to wrong tree. We need to cherry-pick
 > >
 > > commit 621bd0f6982badd6483acb191eb7b6226a578328
 > > Author: Daniel Vetter 
 > > Date:   Tue Sep 29 09:56:53 2015 +0200
 > >
 > > drm: Fix locking for sysfs dpms file
 > >
 > > to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
 > > even comes with the needed cc: stable included (since the locking breakage
 > > was done in 4.0, it only surface due to a new warning in 4.3).
 > 
 > That is already in Linus's tree, I picked it last week I think.

Yeah, that's in the tree I'm testing.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[Dave Airlie]

On 20 October 2015 at 07:54, Daniel Vetter  wrote:
> On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
>> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
>>
>>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
>> this pretty easily..
>>  >
>>  > http://patchwork.freedesktop.org/patch/60618/
>>
>> Back from several weeks of travel..  I tried again with rc6, and
>> I'm still seeing the same traces.
>
> Oh crap, applied patch to wrong tree. We need to cherry-pick
>
> commit 621bd0f6982badd6483acb191eb7b6226a578328
> Author: Daniel Vetter 
> Date:   Tue Sep 29 09:56:53 2015 +0200
>
> drm: Fix locking for sysfs dpms file
>
> to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
> even comes with the needed cc: stable included (since the locking breakage
> was done in 4.0, it only surface due to a new warning in 4.3).

That is already in Linus's tree, I picked it last week I think.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[Daniel Vetter]

On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
> 
>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
> this pretty easily..
>  > 
>  > http://patchwork.freedesktop.org/patch/60618/
> 
> Back from several weeks of travel..  I tried again with rc6, and
> I'm still seeing the same traces.

Oh crap, applied patch to wrong tree. We need to cherry-pick

commit 621bd0f6982badd6483acb191eb7b6226a578328
Author: Daniel Vetter 
Date:   Tue Sep 29 09:56:53 2015 +0200

drm: Fix locking for sysfs dpms file

to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
even comes with the needed cc: stable included (since the locking breakage
was done in 4.0, it only surface due to a new warning in 4.3).
-Daniel

> 
>   Dave
> 
> 
>  > > WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x244/0x2d0()
>  > > CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
>  > >  0379 8801a1377c88 8e35d5ec 
>  > >  8801a1377cc0 8e07a862 880500b392b8 880500a13008
>  > >  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
>  > > Call Trace:
>  > >  [] dump_stack+0x4e/0x82
>  > >  [] warn_slowpath_common+0x82/0xc0
>  > >  [] warn_slowpath_null+0x1a/0x20
>  > >  [] drm_atomic_get_property+0x244/0x2d0
>  > >  [] drm_object_property_get_value+0x6c/0x70
>  > >  [] dpms_show+0x2f/0x70
>  > >  [] dev_attr_show+0x20/0x50
>  > >  [] ? sysfs_file_ops+0x41/0x60
>  > >  [] sysfs_kf_seq_show+0xb7/0x110
>  > >  [] kernfs_seq_show+0x26/0x30
>  > >  [] seq_read+0xe6/0x430
>  > >  [] kernfs_fop_read+0x127/0x170
>  > >  [] ? mutex_lock_nested+0x26b/0x3f0
>  > >  [] __vfs_read+0x28/0xe0
>  > >  [] ? mutex_lock_nested+0x287/0x3f0
>  > >  [] ? __fdget_pos+0x49/0x50
>  > >  [] ? __fdget_pos+0x49/0x50
>  > >  [] vfs_read+0x86/0x130
>  > >  [] SyS_read+0x49/0xb0
>  > >  [] entry_SYSCALL_64_fastpath+0x12/0x6f
>  > > ---[ end trace e053063c697a1355 ]---
>  > > 
>  > >  887 case DRM_MODE_OBJECT_CONNECTOR: {
>  > >  888 struct drm_connector *connector = 
> obj_to_connector(obj);
>  > >  889 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  > >  890 ret = drm_atomic_connector_get_property(connector,
>  > >  891 connector->state, property, val);
>  > >  892 break;
>  > >  893 }
>  > > 
>  > > ___
>  > > dri-devel mailing list
>  > > dri-de...@lists.freedesktop.org
>  > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>  > 
>  > -- 
>  > Daniel Vetter
>  > Software Engineer, Intel Corporation
>  > http://blog.ffwll.ch
> ---end quoted text---
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:

 > > The warning on boot seems to be gone as of rc3, but I can now trigger this 
 > > pretty easily..
 > 
 > http://patchwork.freedesktop.org/patch/60618/

Back from several weeks of travel..  I tried again with rc6, and
I'm still seeing the same traces.

Dave


 > > WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
 > > drm_atomic_get_property+0x244/0x2d0()
 > > CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
 > >  0379 8801a1377c88 8e35d5ec 
 > >  8801a1377cc0 8e07a862 880500b392b8 880500a13008
 > >  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
 > > Call Trace:
 > >  [] dump_stack+0x4e/0x82
 > >  [] warn_slowpath_common+0x82/0xc0
 > >  [] warn_slowpath_null+0x1a/0x20
 > >  [] drm_atomic_get_property+0x244/0x2d0
 > >  [] drm_object_property_get_value+0x6c/0x70
 > >  [] dpms_show+0x2f/0x70
 > >  [] dev_attr_show+0x20/0x50
 > >  [] ? sysfs_file_ops+0x41/0x60
 > >  [] sysfs_kf_seq_show+0xb7/0x110
 > >  [] kernfs_seq_show+0x26/0x30
 > >  [] seq_read+0xe6/0x430
 > >  [] kernfs_fop_read+0x127/0x170
 > >  [] ? mutex_lock_nested+0x26b/0x3f0
 > >  [] __vfs_read+0x28/0xe0
 > >  [] ? mutex_lock_nested+0x287/0x3f0
 > >  [] ? __fdget_pos+0x49/0x50
 > >  [] ? __fdget_pos+0x49/0x50
 > >  [] vfs_read+0x86/0x130
 > >  [] SyS_read+0x49/0xb0
 > >  [] entry_SYSCALL_64_fastpath+0x12/0x6f
 > > ---[ end trace e053063c697a1355 ]---
 > > 
 > >  887 case DRM_MODE_OBJECT_CONNECTOR: {
 > >  888 struct drm_connector *connector = 
 > > obj_to_connector(obj);
 > >  889 
 > > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 > >  890 ret = drm_atomic_connector_get_property(connector,
 > >  891 connector->state, property, val);
 > >  892 break;
 > >  893 }
 > > 
 > > ___
 > > dri-devel mailing list
 > > dri-de...@lists.freedesktop.org
 > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
 > 
 > -- 
 > Daniel Vetter
 > Software Engineer, Intel Corporation
 > http://blog.ffwll.ch
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:

 > > The warning on boot seems to be gone as of rc3, but I can now trigger this 
 > > pretty easily..
 > 
 > http://patchwork.freedesktop.org/patch/60618/

Back from several weeks of travel..  I tried again with rc6, and
I'm still seeing the same traces.

Dave


 > > WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
 > > drm_atomic_get_property+0x244/0x2d0()
 > > CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
 > >  0379 8801a1377c88 8e35d5ec 
 > >  8801a1377cc0 8e07a862 880500b392b8 880500a13008
 > >  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
 > > Call Trace:
 > >  [] dump_stack+0x4e/0x82
 > >  [] warn_slowpath_common+0x82/0xc0
 > >  [] warn_slowpath_null+0x1a/0x20
 > >  [] drm_atomic_get_property+0x244/0x2d0
 > >  [] drm_object_property_get_value+0x6c/0x70
 > >  [] dpms_show+0x2f/0x70
 > >  [] dev_attr_show+0x20/0x50
 > >  [] ? sysfs_file_ops+0x41/0x60
 > >  [] sysfs_kf_seq_show+0xb7/0x110
 > >  [] kernfs_seq_show+0x26/0x30
 > >  [] seq_read+0xe6/0x430
 > >  [] kernfs_fop_read+0x127/0x170
 > >  [] ? mutex_lock_nested+0x26b/0x3f0
 > >  [] __vfs_read+0x28/0xe0
 > >  [] ? mutex_lock_nested+0x287/0x3f0
 > >  [] ? __fdget_pos+0x49/0x50
 > >  [] ? __fdget_pos+0x49/0x50
 > >  [] vfs_read+0x86/0x130
 > >  [] SyS_read+0x49/0xb0
 > >  [] entry_SYSCALL_64_fastpath+0x12/0x6f
 > > ---[ end trace e053063c697a1355 ]---
 > > 
 > >  887 case DRM_MODE_OBJECT_CONNECTOR: {
 > >  888 struct drm_connector *connector = 
 > > obj_to_connector(obj);
 > >  889 
 > > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 > >  890 ret = drm_atomic_connector_get_property(connector,
 > >  891 connector->state, property, val);
 > >  892 break;
 > >  893 }
 > > 
 > > ___
 > > dri-devel mailing list
 > > dri-de...@lists.freedesktop.org
 > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
 > 
 > -- 
 > Daniel Vetter
 > Software Engineer, Intel Corporation
 > http://blog.ffwll.ch
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[Daniel Vetter]

On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
> 
>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
> this pretty easily..
>  > 
>  > http://patchwork.freedesktop.org/patch/60618/
> 
> Back from several weeks of travel..  I tried again with rc6, and
> I'm still seeing the same traces.

Oh crap, applied patch to wrong tree. We need to cherry-pick

commit 621bd0f6982badd6483acb191eb7b6226a578328
Author: Daniel Vetter 
Date:   Tue Sep 29 09:56:53 2015 +0200

drm: Fix locking for sysfs dpms file

to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
even comes with the needed cc: stable included (since the locking breakage
was done in 4.0, it only surface due to a new warning in 4.3).
-Daniel

> 
>   Dave
> 
> 
>  > > WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x244/0x2d0()
>  > > CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
>  > >  0379 8801a1377c88 8e35d5ec 
>  > >  8801a1377cc0 8e07a862 880500b392b8 880500a13008
>  > >  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
>  > > Call Trace:
>  > >  [] dump_stack+0x4e/0x82
>  > >  [] warn_slowpath_common+0x82/0xc0
>  > >  [] warn_slowpath_null+0x1a/0x20
>  > >  [] drm_atomic_get_property+0x244/0x2d0
>  > >  [] drm_object_property_get_value+0x6c/0x70
>  > >  [] dpms_show+0x2f/0x70
>  > >  [] dev_attr_show+0x20/0x50
>  > >  [] ? sysfs_file_ops+0x41/0x60
>  > >  [] sysfs_kf_seq_show+0xb7/0x110
>  > >  [] kernfs_seq_show+0x26/0x30
>  > >  [] seq_read+0xe6/0x430
>  > >  [] kernfs_fop_read+0x127/0x170
>  > >  [] ? mutex_lock_nested+0x26b/0x3f0
>  > >  [] __vfs_read+0x28/0xe0
>  > >  [] ? mutex_lock_nested+0x287/0x3f0
>  > >  [] ? __fdget_pos+0x49/0x50
>  > >  [] ? __fdget_pos+0x49/0x50
>  > >  [] vfs_read+0x86/0x130
>  > >  [] SyS_read+0x49/0xb0
>  > >  [] entry_SYSCALL_64_fastpath+0x12/0x6f
>  > > ---[ end trace e053063c697a1355 ]---
>  > > 
>  > >  887 case DRM_MODE_OBJECT_CONNECTOR: {
>  > >  888 struct drm_connector *connector = 
> obj_to_connector(obj);
>  > >  889 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  > >  890 ret = drm_atomic_connector_get_property(connector,
>  > >  891 connector->state, property, val);
>  > >  892 break;
>  > >  893 }
>  > > 
>  > > ___
>  > > dri-devel mailing list
>  > > dri-de...@lists.freedesktop.org
>  > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>  > 
>  > -- 
>  > Daniel Vetter
>  > Software Engineer, Intel Corporation
>  > http://blog.ffwll.ch
> ---end quoted text---
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[Dave Airlie]

On 20 October 2015 at 07:54, Daniel Vetter  wrote:
> On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
>> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
>>
>>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
>> this pretty easily..
>>  >
>>  > http://patchwork.freedesktop.org/patch/60618/
>>
>> Back from several weeks of travel..  I tried again with rc6, and
>> I'm still seeing the same traces.
>
> Oh crap, applied patch to wrong tree. We need to cherry-pick
>
> commit 621bd0f6982badd6483acb191eb7b6226a578328
> Author: Daniel Vetter 
> Date:   Tue Sep 29 09:56:53 2015 +0200
>
> drm: Fix locking for sysfs dpms file
>
> to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
> even comes with the needed cc: stable included (since the locking breakage
> was done in 4.0, it only surface due to a new warning in 4.3).

That is already in Linus's tree, I picked it last week I think.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Daniel Vetter]

On Tue, Sep 29, 2015 at 09:07:22PM -0400, da...@codemonkey.org.uk wrote:
> On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
>  > On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  
> wrote:
>  > > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
>  > >  > Hey,
>  > >  > 
>  > >  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
>  > >  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > >  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > >  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > >  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to 
> one of
>  > >  > >  > > > their recent patches.
>  > >  > >  > 
>  > >  > >  > Sounds like this showed up before my recent work, but I think I 
> might
>  > >  > >  > have seen similar problems while working on atomic watermarks; 
> the
>  > >  > >  > issues I was seeing were because the initial hardware readout 
> could
>  > >  > >  > leave primary->visible set to true even when the CRTC was off.  
> My
>  > >  > >  > series (which is still under development) contains this patch to 
> fix
>  > >  > >  > that:
>  > >  > >  > 
>  > >  > >  > http://patchwork.freedesktop.org/patch/59564/
>  > >  > >  > 
>  > >  > >  > Does applying that help with the problems reported here?
>  > >  > > 
>  > >  > > No difference at all for me.
>  > >  > Looks like a (reopened) dup of 91952?
>  > >  > 
>  > >  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
>  > >  > visible", and get me the results?
>  > >
>  > > This doesn't apply on top of Linus' current tree.
>  > > If you let me know what it's dependant on, I'll do a build with
>  > > those patches tomorrow.
>  > 
>  > It's now part of the drm-intel-fixes pull request [1], maybe it's
>  > easiest to pull that in? Just four commits on top of
>  > v4.3-rc2. Alternatively pick it up from our repo [2].
> 
> The warning on boot seems to be gone as of rc3, but I can now trigger this 
> pretty easily..

http://patchwork.freedesktop.org/patch/60618/

Cheers, Daniel

> 
> WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x244/0x2d0()
> CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
>  0379 8801a1377c88 8e35d5ec 
>  8801a1377cc0 8e07a862 880500b392b8 880500a13008
>  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
> Call Trace:
>  [] dump_stack+0x4e/0x82
>  [] warn_slowpath_common+0x82/0xc0
>  [] warn_slowpath_null+0x1a/0x20
>  [] drm_atomic_get_property+0x244/0x2d0
>  [] drm_object_property_get_value+0x6c/0x70
>  [] dpms_show+0x2f/0x70
>  [] dev_attr_show+0x20/0x50
>  [] ? sysfs_file_ops+0x41/0x60
>  [] sysfs_kf_seq_show+0xb7/0x110
>  [] kernfs_seq_show+0x26/0x30
>  [] seq_read+0xe6/0x430
>  [] kernfs_fop_read+0x127/0x170
>  [] ? mutex_lock_nested+0x26b/0x3f0
>  [] __vfs_read+0x28/0xe0
>  [] ? mutex_lock_nested+0x287/0x3f0
>  [] ? __fdget_pos+0x49/0x50
>  [] ? __fdget_pos+0x49/0x50
>  [] vfs_read+0x86/0x130
>  [] SyS_read+0x49/0xb0
>  [] entry_SYSCALL_64_fastpath+0x12/0x6f
> ---[ end trace e053063c697a1355 ]---
> 
>  887 case DRM_MODE_OBJECT_CONNECTOR: {
>  888 struct drm_connector *connector = obj_to_connector(obj);
>  889 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  890 ret = drm_atomic_connector_get_property(connector,
>  891 connector->state, property, val);
>  892 break;
>  893 }
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Daniel Vetter]

On Tue, Sep 29, 2015 at 09:07:22PM -0400, da...@codemonkey.org.uk wrote:
> On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
>  > On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  
> wrote:
>  > > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
>  > >  > Hey,
>  > >  > 
>  > >  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
>  > >  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > >  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > >  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > >  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to 
> one of
>  > >  > >  > > > their recent patches.
>  > >  > >  > 
>  > >  > >  > Sounds like this showed up before my recent work, but I think I 
> might
>  > >  > >  > have seen similar problems while working on atomic watermarks; 
> the
>  > >  > >  > issues I was seeing were because the initial hardware readout 
> could
>  > >  > >  > leave primary->visible set to true even when the CRTC was off.  
> My
>  > >  > >  > series (which is still under development) contains this patch to 
> fix
>  > >  > >  > that:
>  > >  > >  > 
>  > >  > >  > http://patchwork.freedesktop.org/patch/59564/
>  > >  > >  > 
>  > >  > >  > Does applying that help with the problems reported here?
>  > >  > > 
>  > >  > > No difference at all for me.
>  > >  > Looks like a (reopened) dup of 91952?
>  > >  > 
>  > >  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
>  > >  > visible", and get me the results?
>  > >
>  > > This doesn't apply on top of Linus' current tree.
>  > > If you let me know what it's dependant on, I'll do a build with
>  > > those patches tomorrow.
>  > 
>  > It's now part of the drm-intel-fixes pull request [1], maybe it's
>  > easiest to pull that in? Just four commits on top of
>  > v4.3-rc2. Alternatively pick it up from our repo [2].
> 
> The warning on boot seems to be gone as of rc3, but I can now trigger this 
> pretty easily..

http://patchwork.freedesktop.org/patch/60618/

Cheers, Daniel

> 
> WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x244/0x2d0()
> CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
>  0379 8801a1377c88 8e35d5ec 
>  8801a1377cc0 8e07a862 880500b392b8 880500a13008
>  880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
> Call Trace:
>  [] dump_stack+0x4e/0x82
>  [] warn_slowpath_common+0x82/0xc0
>  [] warn_slowpath_null+0x1a/0x20
>  [] drm_atomic_get_property+0x244/0x2d0
>  [] drm_object_property_get_value+0x6c/0x70
>  [] dpms_show+0x2f/0x70
>  [] dev_attr_show+0x20/0x50
>  [] ? sysfs_file_ops+0x41/0x60
>  [] sysfs_kf_seq_show+0xb7/0x110
>  [] kernfs_seq_show+0x26/0x30
>  [] seq_read+0xe6/0x430
>  [] kernfs_fop_read+0x127/0x170
>  [] ? mutex_lock_nested+0x26b/0x3f0
>  [] __vfs_read+0x28/0xe0
>  [] ? mutex_lock_nested+0x287/0x3f0
>  [] ? __fdget_pos+0x49/0x50
>  [] ? __fdget_pos+0x49/0x50
>  [] vfs_read+0x86/0x130
>  [] SyS_read+0x49/0xb0
>  [] entry_SYSCALL_64_fastpath+0x12/0x6f
> ---[ end trace e053063c697a1355 ]---
> 
>  887 case DRM_MODE_OBJECT_CONNECTOR: {
>  888 struct drm_connector *connector = obj_to_connector(obj);
>  889 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  890 ret = drm_atomic_connector_get_property(connector,
>  891 connector->state, property, val);
>  892 break;
>  893 }
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
 > On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  
 > wrote:
 > > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > >  > Hey,
 > >  > 
 > >  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > >  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to 
 > > one of
 > >  > >  > > > their recent patches.
 > >  > >  > 
 > >  > >  > Sounds like this showed up before my recent work, but I think I 
 > > might
 > >  > >  > have seen similar problems while working on atomic watermarks; the
 > >  > >  > issues I was seeing were because the initial hardware readout could
 > >  > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > >  > series (which is still under development) contains this patch to 
 > > fix
 > >  > >  > that:
 > >  > >  > 
 > >  > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > >  > 
 > >  > >  > Does applying that help with the problems reported here?
 > >  > > 
 > >  > > No difference at all for me.
 > >  > Looks like a (reopened) dup of 91952?
 > >  > 
 > >  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > >  > visible", and get me the results?
 > >
 > > This doesn't apply on top of Linus' current tree.
 > > If you let me know what it's dependant on, I'll do a build with
 > > those patches tomorrow.
 > 
 > It's now part of the drm-intel-fixes pull request [1], maybe it's
 > easiest to pull that in? Just four commits on top of
 > v4.3-rc2. Alternatively pick it up from our repo [2].

The warning on boot seems to be gone as of rc3, but I can now trigger this 
pretty easily..

WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
drm_atomic_get_property+0x244/0x2d0()
CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
 0379 8801a1377c88 8e35d5ec 
 8801a1377cc0 8e07a862 880500b392b8 880500a13008
 880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
Call Trace:
 [] dump_stack+0x4e/0x82
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] drm_atomic_get_property+0x244/0x2d0
 [] drm_object_property_get_value+0x6c/0x70
 [] dpms_show+0x2f/0x70
 [] dev_attr_show+0x20/0x50
 [] ? sysfs_file_ops+0x41/0x60
 [] sysfs_kf_seq_show+0xb7/0x110
 [] kernfs_seq_show+0x26/0x30
 [] seq_read+0xe6/0x430
 [] kernfs_fop_read+0x127/0x170
 [] ? mutex_lock_nested+0x26b/0x3f0
 [] __vfs_read+0x28/0xe0
 [] ? mutex_lock_nested+0x287/0x3f0
 [] ? __fdget_pos+0x49/0x50
 [] ? __fdget_pos+0x49/0x50
 [] vfs_read+0x86/0x130
 [] SyS_read+0x49/0xb0
 [] entry_SYSCALL_64_fastpath+0x12/0x6f
---[ end trace e053063c697a1355 ]---

 887 case DRM_MODE_OBJECT_CONNECTOR: {
 888 struct drm_connector *connector = obj_to_connector(obj);
 889 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 890 ret = drm_atomic_connector_get_property(connector,
 891 connector->state, property, val);
 892 break;
 893 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
 > On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  
 > wrote:
 > > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > >  > Hey,
 > >  > 
 > >  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > >  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to 
 > > one of
 > >  > >  > > > their recent patches.
 > >  > >  > 
 > >  > >  > Sounds like this showed up before my recent work, but I think I 
 > > might
 > >  > >  > have seen similar problems while working on atomic watermarks; the
 > >  > >  > issues I was seeing were because the initial hardware readout could
 > >  > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > >  > series (which is still under development) contains this patch to 
 > > fix
 > >  > >  > that:
 > >  > >  > 
 > >  > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > >  > 
 > >  > >  > Does applying that help with the problems reported here?
 > >  > > 
 > >  > > No difference at all for me.
 > >  > Looks like a (reopened) dup of 91952?
 > >  > 
 > >  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > >  > visible", and get me the results?
 > >
 > > This doesn't apply on top of Linus' current tree.
 > > If you let me know what it's dependant on, I'll do a build with
 > > those patches tomorrow.
 > 
 > It's now part of the drm-intel-fixes pull request [1], maybe it's
 > easiest to pull that in? Just four commits on top of
 > v4.3-rc2. Alternatively pick it up from our repo [2].

The warning on boot seems to be gone as of rc3, but I can now trigger this 
pretty easily..

WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
drm_atomic_get_property+0x244/0x2d0()
CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
 0379 8801a1377c88 8e35d5ec 
 8801a1377cc0 8e07a862 880500b392b8 880500a13008
 880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
Call Trace:
 [] dump_stack+0x4e/0x82
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] drm_atomic_get_property+0x244/0x2d0
 [] drm_object_property_get_value+0x6c/0x70
 [] dpms_show+0x2f/0x70
 [] dev_attr_show+0x20/0x50
 [] ? sysfs_file_ops+0x41/0x60
 [] sysfs_kf_seq_show+0xb7/0x110
 [] kernfs_seq_show+0x26/0x30
 [] seq_read+0xe6/0x430
 [] kernfs_fop_read+0x127/0x170
 [] ? mutex_lock_nested+0x26b/0x3f0
 [] __vfs_read+0x28/0xe0
 [] ? mutex_lock_nested+0x287/0x3f0
 [] ? __fdget_pos+0x49/0x50
 [] ? __fdget_pos+0x49/0x50
 [] vfs_read+0x86/0x130
 [] SyS_read+0x49/0xb0
 [] entry_SYSCALL_64_fastpath+0x12/0x6f
---[ end trace e053063c697a1355 ]---

 887 case DRM_MODE_OBJECT_CONNECTOR: {
 888 struct drm_connector *connector = obj_to_connector(obj);
 889 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 890 ret = drm_atomic_connector_get_property(connector,
 891 connector->state, property, val);
 892 break;
 893 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Jani Nikula]

On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  wrote:
> On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
>  > Hey,
>  > 
>  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
>  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one 
> of
>  > >  > > > their recent patches.
>  > >  > 
>  > >  > Sounds like this showed up before my recent work, but I think I might
>  > >  > have seen similar problems while working on atomic watermarks; the
>  > >  > issues I was seeing were because the initial hardware readout could
>  > >  > leave primary->visible set to true even when the CRTC was off.  My
>  > >  > series (which is still under development) contains this patch to fix
>  > >  > that:
>  > >  > 
>  > >  > http://patchwork.freedesktop.org/patch/59564/
>  > >  > 
>  > >  > Does applying that help with the problems reported here?
>  > > 
>  > > No difference at all for me.
>  > Looks like a (reopened) dup of 91952?
>  > 
>  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
>  > visible", and get me the results?
>
> This doesn't apply on top of Linus' current tree.
> If you let me know what it's dependant on, I'll do a build with
> those patches tomorrow.

It's now part of the drm-intel-fixes pull request [1], maybe it's
easiest to pull that in? Just four commits on top of
v4.3-rc2. Alternatively pick it up from our repo [2].

Thanks,
Jani.



[1] http://mid.gmane.org/87si646uyf@intel.com
[2] 
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a

>
>   Dave
>  

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Jani Nikula]

On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  wrote:
> On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
>  > Hey,
>  > 
>  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
>  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one 
> of
>  > >  > > > their recent patches.
>  > >  > 
>  > >  > Sounds like this showed up before my recent work, but I think I might
>  > >  > have seen similar problems while working on atomic watermarks; the
>  > >  > issues I was seeing were because the initial hardware readout could
>  > >  > leave primary->visible set to true even when the CRTC was off.  My
>  > >  > series (which is still under development) contains this patch to fix
>  > >  > that:
>  > >  > 
>  > >  > http://patchwork.freedesktop.org/patch/59564/
>  > >  > 
>  > >  > Does applying that help with the problems reported here?
>  > > 
>  > > No difference at all for me.
>  > Looks like a (reopened) dup of 91952?
>  > 
>  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
>  > visible", and get me the results?
>
> This doesn't apply on top of Linus' current tree.
> If you let me know what it's dependant on, I'll do a build with
> those patches tomorrow.

It's now part of the drm-intel-fixes pull request [1], maybe it's
easiest to pull that in? Just four commits on top of
v4.3-rc2. Alternatively pick it up from our repo [2].

Thanks,
Jani.



[1] http://mid.gmane.org/87si646uyf@intel.com
[2] 
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a

>
>   Dave
>  

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > Hey,
 > 
 > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > >  > > > their recent patches.
 > >  > 
 > >  > Sounds like this showed up before my recent work, but I think I might
 > >  > have seen similar problems while working on atomic watermarks; the
 > >  > issues I was seeing were because the initial hardware readout could
 > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > series (which is still under development) contains this patch to fix
 > >  > that:
 > >  > 
 > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > 
 > >  > Does applying that help with the problems reported here?
 > > 
 > > No difference at all for me.
 > Looks like a (reopened) dup of 91952?
 > 
 > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > visible", and get me the results?

This doesn't apply on top of Linus' current tree.
If you let me know what it's dependant on, I'll do a build with
those patches tomorrow.

Dave
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Lankhorst, Maarten]

Hey,

Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
> On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
>  > > > their recent patches.
>  > 
>  > Sounds like this showed up before my recent work, but I think I might
>  > have seen similar problems while working on atomic watermarks; the
>  > issues I was seeing were because the initial hardware readout could
>  > leave primary->visible set to true even when the CRTC was off.  My
>  > series (which is still under development) contains this patch to fix
>  > that:
>  > 
>  > http://patchwork.freedesktop.org/patch/59564/
>  > 
>  > Does applying that help with the problems reported here?
> 
> No difference at all for me.
Looks like a (reopened) dup of 91952?

Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
visible", and get me the results?

~Maarten
-
Intel International B.V.
Registered in The Netherlands under number 34098535
Statutory seat: Haarlemmermeer
Registered address: Capronilaan 37, 1119NG Schiphol-Rijk

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [regression] [git pull] drm for 4.3

[Lankhorst, Maarten]

Hey,

Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
> On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
>  > > > their recent patches.
>  > 
>  > Sounds like this showed up before my recent work, but I think I might
>  > have seen similar problems while working on atomic watermarks; the
>  > issues I was seeing were because the initial hardware readout could
>  > leave primary->visible set to true even when the CRTC was off.  My
>  > series (which is still under development) contains this patch to fix
>  > that:
>  > 
>  > http://patchwork.freedesktop.org/patch/59564/
>  > 
>  > Does applying that help with the problems reported here?
> 
> No difference at all for me.
Looks like a (reopened) dup of 91952?

Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
visible", and get me the results?

~Maarten
-
Intel International B.V.
Registered in The Netherlands under number 34098535
Statutory seat: Haarlemmermeer
Registered address: Capronilaan 37, 1119NG Schiphol-Rijk

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > Hey,
 > 
 > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > >  > > > their recent patches.
 > >  > 
 > >  > Sounds like this showed up before my recent work, but I think I might
 > >  > have seen similar problems while working on atomic watermarks; the
 > >  > issues I was seeing were because the initial hardware readout could
 > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > series (which is still under development) contains this patch to fix
 > >  > that:
 > >  > 
 > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > 
 > >  > Does applying that help with the problems reported here?
 > > 
 > > No difference at all for me.
 > Looks like a (reopened) dup of 91952?
 > 
 > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > visible", and get me the results?

This doesn't apply on top of Linus' current tree.
If you let me know what it's dependant on, I'll do a build with
those patches tomorrow.

Dave
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Dave Jones]

On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > > > their recent patches.
 > 
 > Sounds like this showed up before my recent work, but I think I might
 > have seen similar problems while working on atomic watermarks; the
 > issues I was seeing were because the initial hardware readout could
 > leave primary->visible set to true even when the CRTC was off.  My
 > series (which is still under development) contains this patch to fix
 > that:
 > 
 > http://patchwork.freedesktop.org/patch/59564/
 > 
 > Does applying that help with the problems reported here?

No difference at all for me.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Matt Roper]

On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> > their recent patches.

Sounds like this showed up before my recent work, but I think I might
have seen similar problems while working on atomic watermarks; the
issues I was seeing were because the initial hardware readout could
leave primary->visible set to true even when the CRTC was off.  My
series (which is still under development) contains this patch to fix
that:

http://patchwork.freedesktop.org/patch/59564/

Does applying that help with the problems reported here?


Matt

> 
> Adding Jairo to track this regression.
> -Daniel
> 
> >
> > Jesse
> >
> > On 09/21/2015 11:48 AM, Dave Jones wrote:
> > > On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > >  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >  >  >
> > >  >  > Hi Linus,
> > >  >  >
> > >  >  > This is the main pull request for the drm for 4.3. Nouveau is 
> > > probably the biggest
> > >  >  > amount of changes in here, since it missed 4.2. Highlights below, 
> > > along with the usual
> > >  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> > > nothing
> > >  >  > you can't handle. All stuff outside drm should have applicable acks.
> > >  >  >
> > >  >  > Highlights:
> > >  >  >
> > >  >  > ...
> > >  >  > i915:
> > >  >  > Skylake support enabled by default
> > >  >  > legacy modesetting using atomic infrastructure
> > >  >  > Skylake fixes
> > >  >  > GEN9 workarounds
> > >  >
> > >  > Since this merge, I'm seeing this twice during boot..
> > >
> > > And still there in -rc2.  Several other people reported this too,
> > > and they also got no reponse.
> > >
> > > I'll start bisecting when I get home tonight. It shouldn't be too hard,
> > > as 4.2 was fine.
> > >
> > > Dave
> > >
> > >  > [ cut here ]
> > >  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> > > assert_planes_disabled+0xdf/0x140()
> > >  > plane A assertion failure, should be disabled but not
> > >  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
> > >  > Workqueue: events_unbound async_run_entry_fn
> > >  >  0561 88050392b6f8 8d7dccce 88050392b740
> > >  >  88050392b730 8d079ee2 880500a6 
> > >  >    8805008e99c8 88050392b790
> > >  > Call Trace:
> > >  >  [] dump_stack+0x4e/0x79
> > >  >  [] warn_slowpath_common+0x82/0xc0
> > >  >  [] warn_slowpath_fmt+0x4c/0x50
> > >  >  [] assert_planes_disabled+0xdf/0x140
> > >  >  [] intel_disable_pipe+0x4b/0x2c0
> > >  >  [] haswell_crtc_disable+0x8a/0x2e0
> > >  >  [] intel_atomic_commit+0xff/0x1320
> > >  >  [] ? drm_atomic_check_only+0x21e/0x550
> > >  >  [] drm_atomic_commit+0x37/0x60
> > >  >  [] drm_atomic_helper_set_config+0x1c5/0x430
> > >  >  [] drm_mode_set_config_internal+0x65/0x110
> > >  >  [] restore_fbdev_mode+0xbe/0xe0
> > >  >  [] 
> > > drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
> > >  >  [] drm_fb_helper_set_par+0x2d/0x50
> > >  >  [] intel_fbdev_set_par+0x1a/0x60
> > >  >  [] fbcon_init+0x545/0x5d0
> > >  >  [] visual_init+0xca/0x130
> > >  >  [] do_bind_con_driver+0x1c5/0x3b0
> > >  >  [] do_take_over_console+0x149/0x1a0
> > >  >  [] do_fbcon_takeover+0x57/0xb0
> > >  >  [] fbcon_event_notify+0x66c/0x760
> > >  >  [] notifier_call_chain+0x3e/0xb0
> > >  >  [] __blocking_notifier_call_chain+0x4d/0x70
> > >  >  [] blocking_notifier_call_chain+0x16/0x20
> > >  >  [] fb_notifier_call_chain+0x1b/0x20
> > >  >  [] register_framebuffer+0x1e7/0x300
> > >  >  [] drm_fb_helper_initial_config+0x252/0x3e0
> > >  >  [] intel_fbdev_initial_config+0x1b/0x20
> > >  >  [] async_run_entry_fn+0x4a/0x140
> > >  >  [] process_one_work+0x1fd/0x670
> > >  >  [] ? process_one_work+0x16c/0x670
> > >  >  [] worker_thread+0x4e/0x450
> > >  >  [] ? process_one_work+0x670/0x670
> > >  >  [] kthread+0x101/0x120
> > >  >  [] ? kthread_create_on_node+0x250/0x250
> > >  >  [] ret_from_fork+0x3f/0x70
> > >  >  [] ? kthread_create_on_node+0x250/0x250
> > >  > ---[ end trace 54cab2e0c772d5d9 ]---
> > >  >
> > >  >
> > >  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> > > Processor Integrated Graphics Controller (rev 06)
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
--
To 

[regression] [git pull] drm for 4.3

[Daniel Vetter]

On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> their recent patches.

Adding Jairo to track this regression.
-Daniel

>
> Jesse
>
> On 09/21/2015 11:48 AM, Dave Jones wrote:
> > On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> >  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> >  >  >
> >  >  > Hi Linus,
> >  >  >
> >  >  > This is the main pull request for the drm for 4.3. Nouveau is 
> > probably the biggest
> >  >  > amount of changes in here, since it missed 4.2. Highlights below, 
> > along with the usual
> >  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> > nothing
> >  >  > you can't handle. All stuff outside drm should have applicable acks.
> >  >  >
> >  >  > Highlights:
> >  >  >
> >  >  > ...
> >  >  > i915:
> >  >  > Skylake support enabled by default
> >  >  > legacy modesetting using atomic infrastructure
> >  >  > Skylake fixes
> >  >  > GEN9 workarounds
> >  >
> >  > Since this merge, I'm seeing this twice during boot..
> >
> > And still there in -rc2.  Several other people reported this too,
> > and they also got no reponse.
> >
> > I'll start bisecting when I get home tonight. It shouldn't be too hard,
> > as 4.2 was fine.
> >
> > Dave
> >
> >  > [ cut here ]
> >  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> > assert_planes_disabled+0xdf/0x140()
> >  > plane A assertion failure, should be disabled but not
> >  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
> >  > Workqueue: events_unbound async_run_entry_fn
> >  >  0561 88050392b6f8 8d7dccce 88050392b740
> >  >  88050392b730 8d079ee2 880500a6 
> >  >    8805008e99c8 88050392b790
> >  > Call Trace:
> >  >  [] dump_stack+0x4e/0x79
> >  >  [] warn_slowpath_common+0x82/0xc0
> >  >  [] warn_slowpath_fmt+0x4c/0x50
> >  >  [] assert_planes_disabled+0xdf/0x140
> >  >  [] intel_disable_pipe+0x4b/0x2c0
> >  >  [] haswell_crtc_disable+0x8a/0x2e0
> >  >  [] intel_atomic_commit+0xff/0x1320
> >  >  [] ? drm_atomic_check_only+0x21e/0x550
> >  >  [] drm_atomic_commit+0x37/0x60
> >  >  [] drm_atomic_helper_set_config+0x1c5/0x430
> >  >  [] drm_mode_set_config_internal+0x65/0x110
> >  >  [] restore_fbdev_mode+0xbe/0xe0
> >  >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
> >  >  [] drm_fb_helper_set_par+0x2d/0x50
> >  >  [] intel_fbdev_set_par+0x1a/0x60
> >  >  [] fbcon_init+0x545/0x5d0
> >  >  [] visual_init+0xca/0x130
> >  >  [] do_bind_con_driver+0x1c5/0x3b0
> >  >  [] do_take_over_console+0x149/0x1a0
> >  >  [] do_fbcon_takeover+0x57/0xb0
> >  >  [] fbcon_event_notify+0x66c/0x760
> >  >  [] notifier_call_chain+0x3e/0xb0
> >  >  [] __blocking_notifier_call_chain+0x4d/0x70
> >  >  [] blocking_notifier_call_chain+0x16/0x20
> >  >  [] fb_notifier_call_chain+0x1b/0x20
> >  >  [] register_framebuffer+0x1e7/0x300
> >  >  [] drm_fb_helper_initial_config+0x252/0x3e0
> >  >  [] intel_fbdev_initial_config+0x1b/0x20
> >  >  [] async_run_entry_fn+0x4a/0x140
> >  >  [] process_one_work+0x1fd/0x670
> >  >  [] ? process_one_work+0x16c/0x670
> >  >  [] worker_thread+0x4e/0x450
> >  >  [] ? process_one_work+0x670/0x670
> >  >  [] kthread+0x101/0x120
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  >  [] ret_from_fork+0x3f/0x70
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  > ---[ end trace 54cab2e0c772d5d9 ]---
> >  >
> >  >
> >  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> > Processor Integrated Graphics Controller (rev 06)
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [git pull] drm for 4.3

[Jesse Barnes]

Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.

Jesse

On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
>  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
>  >  > 
>  >  > Hi Linus,
>  >  > 
>  >  > This is the main pull request for the drm for 4.3. Nouveau is probably 
> the biggest
>  >  > amount of changes in here, since it missed 4.2. Highlights below, along 
> with the usual
>  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> nothing 
>  >  > you can't handle. All stuff outside drm should have applicable acks.
>  >  > 
>  >  > Highlights:
>  >  > 
>  >  > ...
>  >  > i915:
>  >  > Skylake support enabled by default
>  >  > legacy modesetting using atomic infrastructure
>  >  > Skylake fixes
>  >  > GEN9 workarounds
>  > 
>  > Since this merge, I'm seeing this twice during boot..
> 
> And still there in -rc2.  Several other people reported this too,
> and they also got no reponse.
> 
> I'll start bisecting when I get home tonight. It shouldn't be too hard,
> as 4.2 was fine.
> 
>   Dave
> 
>  > [ cut here ]
>  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> assert_planes_disabled+0xdf/0x140()
>  > plane A assertion failure, should be disabled but not
>  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
>  > Workqueue: events_unbound async_run_entry_fn
>  >  0561 88050392b6f8 8d7dccce 88050392b740
>  >  88050392b730 8d079ee2 880500a6 
>  >    8805008e99c8 88050392b790
>  > Call Trace:
>  >  [] dump_stack+0x4e/0x79
>  >  [] warn_slowpath_common+0x82/0xc0
>  >  [] warn_slowpath_fmt+0x4c/0x50
>  >  [] assert_planes_disabled+0xdf/0x140
>  >  [] intel_disable_pipe+0x4b/0x2c0
>  >  [] haswell_crtc_disable+0x8a/0x2e0
>  >  [] intel_atomic_commit+0xff/0x1320
>  >  [] ? drm_atomic_check_only+0x21e/0x550
>  >  [] drm_atomic_commit+0x37/0x60
>  >  [] drm_atomic_helper_set_config+0x1c5/0x430
>  >  [] drm_mode_set_config_internal+0x65/0x110
>  >  [] restore_fbdev_mode+0xbe/0xe0
>  >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
>  >  [] drm_fb_helper_set_par+0x2d/0x50
>  >  [] intel_fbdev_set_par+0x1a/0x60
>  >  [] fbcon_init+0x545/0x5d0
>  >  [] visual_init+0xca/0x130
>  >  [] do_bind_con_driver+0x1c5/0x3b0
>  >  [] do_take_over_console+0x149/0x1a0
>  >  [] do_fbcon_takeover+0x57/0xb0
>  >  [] fbcon_event_notify+0x66c/0x760
>  >  [] notifier_call_chain+0x3e/0xb0
>  >  [] __blocking_notifier_call_chain+0x4d/0x70
>  >  [] blocking_notifier_call_chain+0x16/0x20
>  >  [] fb_notifier_call_chain+0x1b/0x20
>  >  [] register_framebuffer+0x1e7/0x300
>  >  [] drm_fb_helper_initial_config+0x252/0x3e0
>  >  [] intel_fbdev_initial_config+0x1b/0x20
>  >  [] async_run_entry_fn+0x4a/0x140
>  >  [] process_one_work+0x1fd/0x670
>  >  [] ? process_one_work+0x16c/0x670
>  >  [] worker_thread+0x4e/0x450
>  >  [] ? process_one_work+0x670/0x670
>  >  [] kthread+0x101/0x120
>  >  [] ? kthread_create_on_node+0x250/0x250
>  >  [] ret_from_fork+0x3f/0x70
>  >  [] ? kthread_create_on_node+0x250/0x250
>  > ---[ end trace 54cab2e0c772d5d9 ]---
>  > 
>  > 
>  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> Processor Integrated Graphics Controller (rev 06)
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[Matt Roper]

On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> > their recent patches.

Sounds like this showed up before my recent work, but I think I might
have seen similar problems while working on atomic watermarks; the
issues I was seeing were because the initial hardware readout could
leave primary->visible set to true even when the CRTC was off.  My
series (which is still under development) contains this patch to fix
that:

http://patchwork.freedesktop.org/patch/59564/

Does applying that help with the problems reported here?


Matt

> 
> Adding Jairo to track this regression.
> -Daniel
> 
> >
> > Jesse
> >
> > On 09/21/2015 11:48 AM, Dave Jones wrote:
> > > On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > >  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >  >  >
> > >  >  > Hi Linus,
> > >  >  >
> > >  >  > This is the main pull request for the drm for 4.3. Nouveau is 
> > > probably the biggest
> > >  >  > amount of changes in here, since it missed 4.2. Highlights below, 
> > > along with the usual
> > >  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> > > nothing
> > >  >  > you can't handle. All stuff outside drm should have applicable acks.
> > >  >  >
> > >  >  > Highlights:
> > >  >  >
> > >  >  > ...
> > >  >  > i915:
> > >  >  > Skylake support enabled by default
> > >  >  > legacy modesetting using atomic infrastructure
> > >  >  > Skylake fixes
> > >  >  > GEN9 workarounds
> > >  >
> > >  > Since this merge, I'm seeing this twice during boot..
> > >
> > > And still there in -rc2.  Several other people reported this too,
> > > and they also got no reponse.
> > >
> > > I'll start bisecting when I get home tonight. It shouldn't be too hard,
> > > as 4.2 was fine.
> > >
> > > Dave
> > >
> > >  > [ cut here ]
> > >  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> > > assert_planes_disabled+0xdf/0x140()
> > >  > plane A assertion failure, should be disabled but not
> > >  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
> > >  > Workqueue: events_unbound async_run_entry_fn
> > >  >  0561 88050392b6f8 8d7dccce 88050392b740
> > >  >  88050392b730 8d079ee2 880500a6 
> > >  >    8805008e99c8 88050392b790
> > >  > Call Trace:
> > >  >  [] dump_stack+0x4e/0x79
> > >  >  [] warn_slowpath_common+0x82/0xc0
> > >  >  [] warn_slowpath_fmt+0x4c/0x50
> > >  >  [] assert_planes_disabled+0xdf/0x140
> > >  >  [] intel_disable_pipe+0x4b/0x2c0
> > >  >  [] haswell_crtc_disable+0x8a/0x2e0
> > >  >  [] intel_atomic_commit+0xff/0x1320
> > >  >  [] ? drm_atomic_check_only+0x21e/0x550
> > >  >  [] drm_atomic_commit+0x37/0x60
> > >  >  [] drm_atomic_helper_set_config+0x1c5/0x430
> > >  >  [] drm_mode_set_config_internal+0x65/0x110
> > >  >  [] restore_fbdev_mode+0xbe/0xe0
> > >  >  [] 
> > > drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
> > >  >  [] drm_fb_helper_set_par+0x2d/0x50
> > >  >  [] intel_fbdev_set_par+0x1a/0x60
> > >  >  [] fbcon_init+0x545/0x5d0
> > >  >  [] visual_init+0xca/0x130
> > >  >  [] do_bind_con_driver+0x1c5/0x3b0
> > >  >  [] do_take_over_console+0x149/0x1a0
> > >  >  [] do_fbcon_takeover+0x57/0xb0
> > >  >  [] fbcon_event_notify+0x66c/0x760
> > >  >  [] notifier_call_chain+0x3e/0xb0
> > >  >  [] __blocking_notifier_call_chain+0x4d/0x70
> > >  >  [] blocking_notifier_call_chain+0x16/0x20
> > >  >  [] fb_notifier_call_chain+0x1b/0x20
> > >  >  [] register_framebuffer+0x1e7/0x300
> > >  >  [] drm_fb_helper_initial_config+0x252/0x3e0
> > >  >  [] intel_fbdev_initial_config+0x1b/0x20
> > >  >  [] async_run_entry_fn+0x4a/0x140
> > >  >  [] process_one_work+0x1fd/0x670
> > >  >  [] ? process_one_work+0x16c/0x670
> > >  >  [] worker_thread+0x4e/0x450
> > >  >  [] ? process_one_work+0x670/0x670
> > >  >  [] kthread+0x101/0x120
> > >  >  [] ? kthread_create_on_node+0x250/0x250
> > >  >  [] ret_from_fork+0x3f/0x70
> > >  >  [] ? kthread_create_on_node+0x250/0x250
> > >  > ---[ end trace 54cab2e0c772d5d9 ]---
> > >  >
> > >  >
> > >  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> > > Processor Integrated Graphics Controller (rev 06)
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
--
To 

Re: [regression] [git pull] drm for 4.3

[Dave Jones]

On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > > > their recent patches.
 > 
 > Sounds like this showed up before my recent work, but I think I might
 > have seen similar problems while working on atomic watermarks; the
 > issues I was seeing were because the initial hardware readout could
 > leave primary->visible set to true even when the CRTC was off.  My
 > series (which is still under development) contains this patch to fix
 > that:
 > 
 > http://patchwork.freedesktop.org/patch/59564/
 > 
 > Does applying that help with the problems reported here?

No difference at all for me.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [git pull] drm for 4.3

[Jesse Barnes]

Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.

Jesse

On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
>  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
>  >  > 
>  >  > Hi Linus,
>  >  > 
>  >  > This is the main pull request for the drm for 4.3. Nouveau is probably 
> the biggest
>  >  > amount of changes in here, since it missed 4.2. Highlights below, along 
> with the usual
>  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> nothing 
>  >  > you can't handle. All stuff outside drm should have applicable acks.
>  >  > 
>  >  > Highlights:
>  >  > 
>  >  > ...
>  >  > i915:
>  >  > Skylake support enabled by default
>  >  > legacy modesetting using atomic infrastructure
>  >  > Skylake fixes
>  >  > GEN9 workarounds
>  > 
>  > Since this merge, I'm seeing this twice during boot..
> 
> And still there in -rc2.  Several other people reported this too,
> and they also got no reponse.
> 
> I'll start bisecting when I get home tonight. It shouldn't be too hard,
> as 4.2 was fine.
> 
>   Dave
> 
>  > [ cut here ]
>  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> assert_planes_disabled+0xdf/0x140()
>  > plane A assertion failure, should be disabled but not
>  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
>  > Workqueue: events_unbound async_run_entry_fn
>  >  0561 88050392b6f8 8d7dccce 88050392b740
>  >  88050392b730 8d079ee2 880500a6 
>  >    8805008e99c8 88050392b790
>  > Call Trace:
>  >  [] dump_stack+0x4e/0x79
>  >  [] warn_slowpath_common+0x82/0xc0
>  >  [] warn_slowpath_fmt+0x4c/0x50
>  >  [] assert_planes_disabled+0xdf/0x140
>  >  [] intel_disable_pipe+0x4b/0x2c0
>  >  [] haswell_crtc_disable+0x8a/0x2e0
>  >  [] intel_atomic_commit+0xff/0x1320
>  >  [] ? drm_atomic_check_only+0x21e/0x550
>  >  [] drm_atomic_commit+0x37/0x60
>  >  [] drm_atomic_helper_set_config+0x1c5/0x430
>  >  [] drm_mode_set_config_internal+0x65/0x110
>  >  [] restore_fbdev_mode+0xbe/0xe0
>  >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
>  >  [] drm_fb_helper_set_par+0x2d/0x50
>  >  [] intel_fbdev_set_par+0x1a/0x60
>  >  [] fbcon_init+0x545/0x5d0
>  >  [] visual_init+0xca/0x130
>  >  [] do_bind_con_driver+0x1c5/0x3b0
>  >  [] do_take_over_console+0x149/0x1a0
>  >  [] do_fbcon_takeover+0x57/0xb0
>  >  [] fbcon_event_notify+0x66c/0x760
>  >  [] notifier_call_chain+0x3e/0xb0
>  >  [] __blocking_notifier_call_chain+0x4d/0x70
>  >  [] blocking_notifier_call_chain+0x16/0x20
>  >  [] fb_notifier_call_chain+0x1b/0x20
>  >  [] register_framebuffer+0x1e7/0x300
>  >  [] drm_fb_helper_initial_config+0x252/0x3e0
>  >  [] intel_fbdev_initial_config+0x1b/0x20
>  >  [] async_run_entry_fn+0x4a/0x140
>  >  [] process_one_work+0x1fd/0x670
>  >  [] ? process_one_work+0x16c/0x670
>  >  [] worker_thread+0x4e/0x450
>  >  [] ? process_one_work+0x670/0x670
>  >  [] kthread+0x101/0x120
>  >  [] ? kthread_create_on_node+0x250/0x250
>  >  [] ret_from_fork+0x3f/0x70
>  >  [] ? kthread_create_on_node+0x250/0x250
>  > ---[ end trace 54cab2e0c772d5d9 ]---
>  > 
>  > 
>  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> Processor Integrated Graphics Controller (rev 06)
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[regression] [git pull] drm for 4.3

[Daniel Vetter]

On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> their recent patches.

Adding Jairo to track this regression.
-Daniel

>
> Jesse
>
> On 09/21/2015 11:48 AM, Dave Jones wrote:
> > On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> >  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> >  >  >
> >  >  > Hi Linus,
> >  >  >
> >  >  > This is the main pull request for the drm for 4.3. Nouveau is 
> > probably the biggest
> >  >  > amount of changes in here, since it missed 4.2. Highlights below, 
> > along with the usual
> >  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> > nothing
> >  >  > you can't handle. All stuff outside drm should have applicable acks.
> >  >  >
> >  >  > Highlights:
> >  >  >
> >  >  > ...
> >  >  > i915:
> >  >  > Skylake support enabled by default
> >  >  > legacy modesetting using atomic infrastructure
> >  >  > Skylake fixes
> >  >  > GEN9 workarounds
> >  >
> >  > Since this merge, I'm seeing this twice during boot..
> >
> > And still there in -rc2.  Several other people reported this too,
> > and they also got no reponse.
> >
> > I'll start bisecting when I get home tonight. It shouldn't be too hard,
> > as 4.2 was fine.
> >
> > Dave
> >
> >  > [ cut here ]
> >  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> > assert_planes_disabled+0xdf/0x140()
> >  > plane A assertion failure, should be disabled but not
> >  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
> >  > Workqueue: events_unbound async_run_entry_fn
> >  >  0561 88050392b6f8 8d7dccce 88050392b740
> >  >  88050392b730 8d079ee2 880500a6 
> >  >    8805008e99c8 88050392b790
> >  > Call Trace:
> >  >  [] dump_stack+0x4e/0x79
> >  >  [] warn_slowpath_common+0x82/0xc0
> >  >  [] warn_slowpath_fmt+0x4c/0x50
> >  >  [] assert_planes_disabled+0xdf/0x140
> >  >  [] intel_disable_pipe+0x4b/0x2c0
> >  >  [] haswell_crtc_disable+0x8a/0x2e0
> >  >  [] intel_atomic_commit+0xff/0x1320
> >  >  [] ? drm_atomic_check_only+0x21e/0x550
> >  >  [] drm_atomic_commit+0x37/0x60
> >  >  [] drm_atomic_helper_set_config+0x1c5/0x430
> >  >  [] drm_mode_set_config_internal+0x65/0x110
> >  >  [] restore_fbdev_mode+0xbe/0xe0
> >  >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
> >  >  [] drm_fb_helper_set_par+0x2d/0x50
> >  >  [] intel_fbdev_set_par+0x1a/0x60
> >  >  [] fbcon_init+0x545/0x5d0
> >  >  [] visual_init+0xca/0x130
> >  >  [] do_bind_con_driver+0x1c5/0x3b0
> >  >  [] do_take_over_console+0x149/0x1a0
> >  >  [] do_fbcon_takeover+0x57/0xb0
> >  >  [] fbcon_event_notify+0x66c/0x760
> >  >  [] notifier_call_chain+0x3e/0xb0
> >  >  [] __blocking_notifier_call_chain+0x4d/0x70
> >  >  [] blocking_notifier_call_chain+0x16/0x20
> >  >  [] fb_notifier_call_chain+0x1b/0x20
> >  >  [] register_framebuffer+0x1e7/0x300
> >  >  [] drm_fb_helper_initial_config+0x252/0x3e0
> >  >  [] intel_fbdev_initial_config+0x1b/0x20
> >  >  [] async_run_entry_fn+0x4a/0x140
> >  >  [] process_one_work+0x1fd/0x670
> >  >  [] ? process_one_work+0x16c/0x670
> >  >  [] worker_thread+0x4e/0x450
> >  >  [] ? process_one_work+0x670/0x670
> >  >  [] kthread+0x101/0x120
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  >  [] ret_from_fork+0x3f/0x70
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  > ---[ end trace 54cab2e0c772d5d9 ]---
> >  >
> >  >
> >  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> > Processor Integrated Graphics Controller (rev 06)
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Jones]

On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
 > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
 >  > 
 >  > Hi Linus,
 >  > 
 >  > This is the main pull request for the drm for 4.3. Nouveau is probably 
 > the biggest
 >  > amount of changes in here, since it missed 4.2. Highlights below, along 
 > with the usual
 >  > bunch of fixes. There are a few minor conflicts with your tree but 
 > nothing 
 >  > you can't handle. All stuff outside drm should have applicable acks.
 >  > 
 >  > Highlights:
 >  > 
 >  > ...
 >  > i915:
 >  >   Skylake support enabled by default
 >  >   legacy modesetting using atomic infrastructure
 >  >   Skylake fixes
 >  >   GEN9 workarounds
 > 
 > Since this merge, I'm seeing this twice during boot..

And still there in -rc2.  Several other people reported this too,
and they also got no reponse.

I'll start bisecting when I get home tonight. It shouldn't be too hard,
as 4.2 was fine.

Dave

 > [ cut here ]
 > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
 > assert_planes_disabled+0xdf/0x140()
 > plane A assertion failure, should be disabled but not
 > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
 > Workqueue: events_unbound async_run_entry_fn
 >  0561 88050392b6f8 8d7dccce 88050392b740
 >  88050392b730 8d079ee2 880500a6 
 >    8805008e99c8 88050392b790
 > Call Trace:
 >  [] dump_stack+0x4e/0x79
 >  [] warn_slowpath_common+0x82/0xc0
 >  [] warn_slowpath_fmt+0x4c/0x50
 >  [] assert_planes_disabled+0xdf/0x140
 >  [] intel_disable_pipe+0x4b/0x2c0
 >  [] haswell_crtc_disable+0x8a/0x2e0
 >  [] intel_atomic_commit+0xff/0x1320
 >  [] ? drm_atomic_check_only+0x21e/0x550
 >  [] drm_atomic_commit+0x37/0x60
 >  [] drm_atomic_helper_set_config+0x1c5/0x430
 >  [] drm_mode_set_config_internal+0x65/0x110
 >  [] restore_fbdev_mode+0xbe/0xe0
 >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 >  [] drm_fb_helper_set_par+0x2d/0x50
 >  [] intel_fbdev_set_par+0x1a/0x60
 >  [] fbcon_init+0x545/0x5d0
 >  [] visual_init+0xca/0x130
 >  [] do_bind_con_driver+0x1c5/0x3b0
 >  [] do_take_over_console+0x149/0x1a0
 >  [] do_fbcon_takeover+0x57/0xb0
 >  [] fbcon_event_notify+0x66c/0x760
 >  [] notifier_call_chain+0x3e/0xb0
 >  [] __blocking_notifier_call_chain+0x4d/0x70
 >  [] blocking_notifier_call_chain+0x16/0x20
 >  [] fb_notifier_call_chain+0x1b/0x20
 >  [] register_framebuffer+0x1e7/0x300
 >  [] drm_fb_helper_initial_config+0x252/0x3e0
 >  [] intel_fbdev_initial_config+0x1b/0x20
 >  [] async_run_entry_fn+0x4a/0x140
 >  [] process_one_work+0x1fd/0x670
 >  [] ? process_one_work+0x16c/0x670
 >  [] worker_thread+0x4e/0x450
 >  [] ? process_one_work+0x670/0x670
 >  [] kthread+0x101/0x120
 >  [] ? kthread_create_on_node+0x250/0x250
 >  [] ret_from_fork+0x3f/0x70
 >  [] ? kthread_create_on_node+0x250/0x250
 > ---[ end trace 54cab2e0c772d5d9 ]---
 > 
 > 
 > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
 > Processor Integrated Graphics Controller (rev 06)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Jones]

On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
 > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
 >  > 
 >  > Hi Linus,
 >  > 
 >  > This is the main pull request for the drm for 4.3. Nouveau is probably 
 > the biggest
 >  > amount of changes in here, since it missed 4.2. Highlights below, along 
 > with the usual
 >  > bunch of fixes. There are a few minor conflicts with your tree but 
 > nothing 
 >  > you can't handle. All stuff outside drm should have applicable acks.
 >  > 
 >  > Highlights:
 >  > 
 >  > ...
 >  > i915:
 >  >   Skylake support enabled by default
 >  >   legacy modesetting using atomic infrastructure
 >  >   Skylake fixes
 >  >   GEN9 workarounds
 > 
 > Since this merge, I'm seeing this twice during boot..

And still there in -rc2.  Several other people reported this too,
and they also got no reponse.

I'll start bisecting when I get home tonight. It shouldn't be too hard,
as 4.2 was fine.

Dave

 > [ cut here ]
 > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
 > assert_planes_disabled+0xdf/0x140()
 > plane A assertion failure, should be disabled but not
 > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
 > Workqueue: events_unbound async_run_entry_fn
 >  0561 88050392b6f8 8d7dccce 88050392b740
 >  88050392b730 8d079ee2 880500a6 
 >    8805008e99c8 88050392b790
 > Call Trace:
 >  [] dump_stack+0x4e/0x79
 >  [] warn_slowpath_common+0x82/0xc0
 >  [] warn_slowpath_fmt+0x4c/0x50
 >  [] assert_planes_disabled+0xdf/0x140
 >  [] intel_disable_pipe+0x4b/0x2c0
 >  [] haswell_crtc_disable+0x8a/0x2e0
 >  [] intel_atomic_commit+0xff/0x1320
 >  [] ? drm_atomic_check_only+0x21e/0x550
 >  [] drm_atomic_commit+0x37/0x60
 >  [] drm_atomic_helper_set_config+0x1c5/0x430
 >  [] drm_mode_set_config_internal+0x65/0x110
 >  [] restore_fbdev_mode+0xbe/0xe0
 >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 >  [] drm_fb_helper_set_par+0x2d/0x50
 >  [] intel_fbdev_set_par+0x1a/0x60
 >  [] fbcon_init+0x545/0x5d0
 >  [] visual_init+0xca/0x130
 >  [] do_bind_con_driver+0x1c5/0x3b0
 >  [] do_take_over_console+0x149/0x1a0
 >  [] do_fbcon_takeover+0x57/0xb0
 >  [] fbcon_event_notify+0x66c/0x760
 >  [] notifier_call_chain+0x3e/0xb0
 >  [] __blocking_notifier_call_chain+0x4d/0x70
 >  [] blocking_notifier_call_chain+0x16/0x20
 >  [] fb_notifier_call_chain+0x1b/0x20
 >  [] register_framebuffer+0x1e7/0x300
 >  [] drm_fb_helper_initial_config+0x252/0x3e0
 >  [] intel_fbdev_initial_config+0x1b/0x20
 >  [] async_run_entry_fn+0x4a/0x140
 >  [] process_one_work+0x1fd/0x670
 >  [] ? process_one_work+0x16c/0x670
 >  [] worker_thread+0x4e/0x450
 >  [] ? process_one_work+0x670/0x670
 >  [] kthread+0x101/0x120
 >  [] ? kthread_create_on_node+0x250/0x250
 >  [] ret_from_fork+0x3f/0x70
 >  [] ? kthread_create_on_node+0x250/0x250
 > ---[ end trace 54cab2e0c772d5d9 ]---
 > 
 > 
 > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
 > Processor Integrated Graphics Controller (rev 06)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Linus Torvalds]

On Mon, Sep 7, 2015 at 9:56 PM, Dave Airlie  wrote:
>
> i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
> commits in a 20 commit tree would be bad.

I think it's about size of the commits. If it's 59 clean oneliner
fixes, I don't think it's a big deal. If it's 59 patches that add new
functionality, that's a different issue. The size of the base tree is
almost entirely irrelevant in that situation. Fixes are ok, new
features are not.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Linus Torvalds]

On Mon, Sep 7, 2015 at 9:56 PM, Dave Airlie  wrote:
>
> i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
> commits in a 20 commit tree would be bad.

I think it's about size of the commits. If it's 59 clean oneliner
fixes, I don't think it's a big deal. If it's 59 patches that add new
functionality, that's a different issue. The size of the base tree is
almost entirely irrelevant in that situation. Fixes are ok, new
features are not.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Airlie]

On 8 September 2015 at 14:04, Stephen Rothwell  wrote:
> Hi Dave,
>
> On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie  wrote:
>>
>> Is this to be a regular thing? because I know I'd prefer to merge
>> fixes than wait for -rc1 to be an accurate copy of linux-next.
>
> It happens when I can (almost) keep up with Linus' merge rate (often I
> can't).  It is not an issue and I agree that fixes should just be done
> as/when needed.  That is why I say "not judging, just noting" - I
> generally don't have the time to figure out if each and every unseen
> commit is a fix or new feature and/or if it has some possibility of
> interacting with some other tree in a way that a few days in linux-next
> may have flushed out.
>
> So, if you are happy with what you are doing (and you don't irritate
> Linus), then I am happy (as long as you don't cause unnecessary extra
> conflicts in linux-next :-)).
>

Maybe you could heuristic it by ratio new commits or new lines vs the
total size of the -next tree.

i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
commits in a 20 commit tree would be bad.

Though not sure how you'd tune it!

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Stephen Rothwell]

Hi Dave,

On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie  wrote:
>
> Is this to be a regular thing? because I know I'd prefer to merge
> fixes than wait for -rc1 to be an accurate copy of linux-next.

It happens when I can (almost) keep up with Linus' merge rate (often I
can't).  It is not an issue and I agree that fixes should just be done
as/when needed.  That is why I say "not judging, just noting" - I
generally don't have the time to figure out if each and every unseen
commit is a fix or new feature and/or if it has some possibility of
interacting with some other tree in a way that a few days in linux-next
may have flushed out.

So, if you are happy with what you are doing (and you don't irritate
Linus), then I am happy (as long as you don't cause unnecessary extra
conflicts in linux-next :-)).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Airlie]

On 8 September 2015 at 12:03, Stephen Rothwell  wrote:
> Hi Linus,
>
> On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie  wrote:
>>
>> This is the main pull request for the drm for 4.3. Nouveau is probably the 
>> biggest
>> amount of changes in here, since it missed 4.2. Highlights below, along with 
>> the usual
>> bunch of fixes. There are a few minor conflicts with your tree but nothing
>> you can't handle. All stuff outside drm should have applicable acks.
>>
>> The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
>>
>>   Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)
>>
>> are available in the git repository at:
>>
>>   git://people.freedesktop.org/~airlied/linux drm-next
>>
>> for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098:
>>
>>   Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux 
>> into drm-next (2015-09-05 07:46:09 +1000)
>
> This contains 59 commits added since Sept 1 and 56 of those are only
> appearing in today's linux-next.  Not judging, just noting.

Is this to be a regular thing? because I know I'd prefer to merge
fixes than wait for -rc1 to be an accurate copy of linux-next.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Stephen Rothwell]

Hi Linus,

On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie  wrote:
>
> This is the main pull request for the drm for 4.3. Nouveau is probably the 
> biggest
> amount of changes in here, since it missed 4.2. Highlights below, along with 
> the usual
> bunch of fixes. There are a few minor conflicts with your tree but nothing 
> you can't handle. All stuff outside drm should have applicable acks.
> 
> The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
> 
>   Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-next
> 
> for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098:
> 
>   Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux 
> into drm-next (2015-09-05 07:46:09 +1000)

This contains 59 commits added since Sept 1 and 56 of those are only
appearing in today's linux-next.  Not judging, just noting.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Jones]

On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
 > 
 > Hi Linus,
 > 
 > This is the main pull request for the drm for 4.3. Nouveau is probably the 
 > biggest
 > amount of changes in here, since it missed 4.2. Highlights below, along with 
 > the usual
 > bunch of fixes. There are a few minor conflicts with your tree but nothing 
 > you can't handle. All stuff outside drm should have applicable acks.
 > 
 > Highlights:
 > 
 > ...
 > i915:
 >  Skylake support enabled by default
 >  legacy modesetting using atomic infrastructure
 >  Skylake fixes
 >  GEN9 workarounds

Since this merge, I'm seeing this twice during boot..


[ cut here ]
WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
assert_planes_disabled+0xdf/0x140()
plane A assertion failure, should be disabled but not
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
Workqueue: events_unbound async_run_entry_fn
 0561 88050392b6f8 8d7dccce 88050392b740
 88050392b730 8d079ee2 880500a6 
   8805008e99c8 88050392b790
Call Trace:
 [] dump_stack+0x4e/0x79
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_fmt+0x4c/0x50
 [] assert_planes_disabled+0xdf/0x140
 [] intel_disable_pipe+0x4b/0x2c0
 [] haswell_crtc_disable+0x8a/0x2e0
 [] intel_atomic_commit+0xff/0x1320
 [] ? drm_atomic_check_only+0x21e/0x550
 [] drm_atomic_commit+0x37/0x60
 [] drm_atomic_helper_set_config+0x1c5/0x430
 [] drm_mode_set_config_internal+0x65/0x110
 [] restore_fbdev_mode+0xbe/0xe0
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 [] drm_fb_helper_set_par+0x2d/0x50
 [] intel_fbdev_set_par+0x1a/0x60
 [] fbcon_init+0x545/0x5d0
 [] visual_init+0xca/0x130
 [] do_bind_con_driver+0x1c5/0x3b0
 [] do_take_over_console+0x149/0x1a0
 [] do_fbcon_takeover+0x57/0xb0
 [] fbcon_event_notify+0x66c/0x760
 [] notifier_call_chain+0x3e/0xb0
 [] __blocking_notifier_call_chain+0x4d/0x70
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x1e7/0x300
 [] drm_fb_helper_initial_config+0x252/0x3e0
 [] intel_fbdev_initial_config+0x1b/0x20
 [] async_run_entry_fn+0x4a/0x140
 [] process_one_work+0x1fd/0x670
 [] ? process_one_work+0x16c/0x670
 [] worker_thread+0x4e/0x450
 [] ? process_one_work+0x670/0x670
 [] kthread+0x101/0x120
 [] ? kthread_create_on_node+0x250/0x250
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x250/0x250
---[ end trace 54cab2e0c772d5d9 ]---


00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 Processor 
Integrated Graphics Controller (rev 06)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Airlie]

On 8 September 2015 at 14:04, Stephen Rothwell  wrote:
> Hi Dave,
>
> On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie  wrote:
>>
>> Is this to be a regular thing? because I know I'd prefer to merge
>> fixes than wait for -rc1 to be an accurate copy of linux-next.
>
> It happens when I can (almost) keep up with Linus' merge rate (often I
> can't).  It is not an issue and I agree that fixes should just be done
> as/when needed.  That is why I say "not judging, just noting" - I
> generally don't have the time to figure out if each and every unseen
> commit is a fix or new feature and/or if it has some possibility of
> interacting with some other tree in a way that a few days in linux-next
> may have flushed out.
>
> So, if you are happy with what you are doing (and you don't irritate
> Linus), then I am happy (as long as you don't cause unnecessary extra
> conflicts in linux-next :-)).
>

Maybe you could heuristic it by ratio new commits or new lines vs the
total size of the -next tree.

i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
commits in a 20 commit tree would be bad.

Though not sure how you'd tune it!

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Stephen Rothwell]

Hi Dave,

On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie  wrote:
>
> Is this to be a regular thing? because I know I'd prefer to merge
> fixes than wait for -rc1 to be an accurate copy of linux-next.

It happens when I can (almost) keep up with Linus' merge rate (often I
can't).  It is not an issue and I agree that fixes should just be done
as/when needed.  That is why I say "not judging, just noting" - I
generally don't have the time to figure out if each and every unseen
commit is a fix or new feature and/or if it has some possibility of
interacting with some other tree in a way that a few days in linux-next
may have flushed out.

So, if you are happy with what you are doing (and you don't irritate
Linus), then I am happy (as long as you don't cause unnecessary extra
conflicts in linux-next :-)).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Stephen Rothwell]

Hi Linus,

On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie  wrote:
>
> This is the main pull request for the drm for 4.3. Nouveau is probably the 
> biggest
> amount of changes in here, since it missed 4.2. Highlights below, along with 
> the usual
> bunch of fixes. There are a few minor conflicts with your tree but nothing 
> you can't handle. All stuff outside drm should have applicable acks.
> 
> The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
> 
>   Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-next
> 
> for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098:
> 
>   Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux 
> into drm-next (2015-09-05 07:46:09 +1000)

This contains 59 commits added since Sept 1 and 56 of those are only
appearing in today's linux-next.  Not judging, just noting.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Airlie]

On 8 September 2015 at 12:03, Stephen Rothwell  wrote:
> Hi Linus,
>
> On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie  wrote:
>>
>> This is the main pull request for the drm for 4.3. Nouveau is probably the 
>> biggest
>> amount of changes in here, since it missed 4.2. Highlights below, along with 
>> the usual
>> bunch of fixes. There are a few minor conflicts with your tree but nothing
>> you can't handle. All stuff outside drm should have applicable acks.
>>
>> The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
>>
>>   Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)
>>
>> are available in the git repository at:
>>
>>   git://people.freedesktop.org/~airlied/linux drm-next
>>
>> for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098:
>>
>>   Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux 
>> into drm-next (2015-09-05 07:46:09 +1000)
>
> This contains 59 commits added since Sept 1 and 56 of those are only
> appearing in today's linux-next.  Not judging, just noting.

Is this to be a regular thing? because I know I'd prefer to merge
fixes than wait for -rc1 to be an accurate copy of linux-next.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm for 4.3

[Dave Jones]

On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
 > 
 > Hi Linus,
 > 
 > This is the main pull request for the drm for 4.3. Nouveau is probably the 
 > biggest
 > amount of changes in here, since it missed 4.2. Highlights below, along with 
 > the usual
 > bunch of fixes. There are a few minor conflicts with your tree but nothing 
 > you can't handle. All stuff outside drm should have applicable acks.
 > 
 > Highlights:
 > 
 > ...
 > i915:
 >  Skylake support enabled by default
 >  legacy modesetting using atomic infrastructure
 >  Skylake fixes
 >  GEN9 workarounds

Since this merge, I'm seeing this twice during boot..


[ cut here ]
WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
assert_planes_disabled+0xdf/0x140()
plane A assertion failure, should be disabled but not
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
Workqueue: events_unbound async_run_entry_fn
 0561 88050392b6f8 8d7dccce 88050392b740
 88050392b730 8d079ee2 880500a6 
   8805008e99c8 88050392b790
Call Trace:
 [] dump_stack+0x4e/0x79
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_fmt+0x4c/0x50
 [] assert_planes_disabled+0xdf/0x140
 [] intel_disable_pipe+0x4b/0x2c0
 [] haswell_crtc_disable+0x8a/0x2e0
 [] intel_atomic_commit+0xff/0x1320
 [] ? drm_atomic_check_only+0x21e/0x550
 [] drm_atomic_commit+0x37/0x60
 [] drm_atomic_helper_set_config+0x1c5/0x430
 [] drm_mode_set_config_internal+0x65/0x110
 [] restore_fbdev_mode+0xbe/0xe0
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 [] drm_fb_helper_set_par+0x2d/0x50
 [] intel_fbdev_set_par+0x1a/0x60
 [] fbcon_init+0x545/0x5d0
 [] visual_init+0xca/0x130
 [] do_bind_con_driver+0x1c5/0x3b0
 [] do_take_over_console+0x149/0x1a0
 [] do_fbcon_takeover+0x57/0xb0
 [] fbcon_event_notify+0x66c/0x760
 [] notifier_call_chain+0x3e/0xb0
 [] __blocking_notifier_call_chain+0x4d/0x70
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x1e7/0x300
 [] drm_fb_helper_initial_config+0x252/0x3e0
 [] intel_fbdev_initial_config+0x1b/0x20
 [] async_run_entry_fn+0x4a/0x140
 [] process_one_work+0x1fd/0x670
 [] ? process_one_work+0x16c/0x670
 [] worker_thread+0x4e/0x450
 [] ? process_one_work+0x670/0x670
 [] kthread+0x101/0x120
 [] ? kthread_create_on_node+0x250/0x250
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x250/0x250
---[ end trace 54cab2e0c772d5d9 ]---


00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 Processor 
Integrated Graphics Controller (rev 06)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/