[Intel-gfx] [regression] [git pull] drm for 4.3
On 20 October 2015 at 07:54, Daniel Vetter wrote: > On Mon, Oct 19, 2015 at 04:19:08PM -0400, davej at 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.
[Intel-gfx] [regression] [git pull] drm for 4.3
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, davej at 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
[Intel-gfx] [regression] [git pull] drm for 4.3
On Mon, Oct 19, 2015 at 04:19:08PM -0400, davej at 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-devel at 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-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[regression] [git pull] drm for 4.3
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-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
---end quoted text---
[regression] [git pull] drm for 4.3
On Tue, Sep 29, 2015 at 09:07:22PM -0400, davej at codemonkey.org.uk wrote:
> On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
> > On Thu, 24 Sep 2015, "davej at codemonkey.org.uk" 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-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[regression] [git pull] drm for 4.3
On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
> On Thu, 24 Sep 2015, "davej at codemonkey.org.uk" 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 }
[regression] [git pull] drm for 4.3
On Thu, 24 Sep 2015, "davej at 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.fsf at intel.com [2] http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a > > Dave > -- Jani Nikula, Intel Open Source Technology Center
[regression] [git pull] drm for 4.3
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
[regression] [git pull] drm for 4.3
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.
[regression] [git pull] drm for 4.3
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
[regression] [git pull] drm for 4.3
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-gfx at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[regression] [git pull] drm for 4.3
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-gfx at lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > ___ > > dri-devel mailing list > > dri-devel at 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
