[git pull] drm fixes

[git pull] drm fixes

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5045 bytes --]


Hi Linus,

just general fixes pull, radeon, i915, atmel, tegra, amdkfd
and one core fix.

Dave.

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 21689a440bdc90650b7ee3803ec11cfabd21409e:

  Merge branch 'drm-atmel-hlcdc-fixes' of git://github.com/bbrezillon/linux-at91 into drm-fixes (2015-02-27 10:31:40 +1000)

----------------------------------------------------------------

Alex Deucher (6):
      drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh
      drm/radeon: disable mclk switching with 120hz+ monitors
      drm/radeon: dump full IB if we hit a packet error
      drm/radeon: fix 1 RB harvest config setup for TN/RL
      drm/radeon: fix atom aux payload size check for writes (v2)
      drm/radeon: only enable DP audio if the monitor supports it

Boris Brezillon (2):
      drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when disabling it
      drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probe

Chris Wilson (1):
      drm/i915: Check obj->vma_list under the struct_mutex

Christian König (2):
      drm/radeon: enable SRBM timeout interrupt on SI
      drm/radeon: enable SRBM timeout interrupt on EG/NI

Daniel Vetter (2):
      drm: Fix deadlock due to getconnector locking changes
      drm/i915: Align initial plane backing objects correctly

Dave Airlie (5):
      Merge tag 'drm/tegra/for-3.20-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux into drm-fixes
      Merge tag 'drm-amdkfd-fixes-2015-02-23' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes
      Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      Merge tag 'drm-intel-fixes-2015-02-26' of git://anongit.freedesktop.org/drm-intel into drm-fixes
      Merge branch 'drm-atmel-hlcdc-fixes' of git://github.com/bbrezillon/linux-at91 into drm-fixes

Imre Deak (1):
      drm/i915: avoid processing spurious/shared interrupts in low-power states

Jani Nikula (2):
      drm/i915/skl: handle all pixel formats in skylake_update_primary_plane()
      drm/i915: Dell Chromebook 11 has PWM backlight

Leo Liu (1):
      drm/radeon: enable SRBM timeout interrupt on CIK v2

Nathan-J. Hirschauer (1):
      drm/radeon: enable native backlight control on old macs

Nick Hoath (1):
      drm/i915: Fix a use after free, and unbalanced refcounting

Nicolas Ferre (1):
      drm: atmel-hlcdc: remove clock polarity from crtc driver

Oded Gabbay (2):
      drm/amdkfd: Initialize only amdkfd's assigned pipelines
      drm/amdkfd: don't set get_pipes_num() as inline

Rodrigo Vivi (2):
      drm/i915/bdw: PCI IDs ending in 0xb are ULT.
      drm/i915: Fix frontbuffer false positve.

Thierry Reding (4):
      drm/tegra: hdmi: Explicitly set clock rate
      drm/tegra: dc: Reset state's active_changed field
      drm/tegra: dc: Wire up CRTC parent of atomic state
      drm/tegra: dc: Move more code into ->init()

 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 10 ++-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  8 +--
 .../drm/amd/amdkfd/kfd_device_queue_manager_cik.c  |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c     |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c       |  2 -
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c    |  3 +-
 drivers/gpu/drm/drm_crtc.c                         |  3 +-
 drivers/gpu/drm/i915/i915_drv.h                    | 15 +++-
 drivers/gpu/drm/i915/i915_gem.c                    |  3 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c             |  6 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c             |  7 +-
 drivers/gpu/drm/i915/i915_irq.c                    | 22 ++++++
 drivers/gpu/drm/i915/intel_display.c               | 33 ++++++---
 drivers/gpu/drm/i915/intel_lrc.c                   |  8 +--
 drivers/gpu/drm/radeon/atombios_dp.c               |  7 ++
 drivers/gpu/drm/radeon/atombios_encoders.c         | 21 ++++--
 drivers/gpu/drm/radeon/cik.c                       |  8 +++
 drivers/gpu/drm/radeon/cikd.h                      |  4 ++
 drivers/gpu/drm/radeon/evergreen.c                 |  7 ++
 drivers/gpu/drm/radeon/evergreend.h                |  4 ++
 drivers/gpu/drm/radeon/ni.c                        | 10 +--
 drivers/gpu/drm/radeon/nid.h                       |  4 ++
 drivers/gpu/drm/radeon/r600_dpm.c                  |  2 +-
 drivers/gpu/drm/radeon/radeon_cs.c                 | 16 ++++-
 drivers/gpu/drm/radeon/radeon_encoders.c           |  3 +
 drivers/gpu/drm/radeon/radeon_pm.c                 |  6 ++
 drivers/gpu/drm/radeon/si.c                        | 22 ++++--
 drivers/gpu/drm/radeon/sid.h                       |  4 ++
 drivers/gpu/drm/tegra/dc.c                         | 79 +++++++++++-----------
 drivers/gpu/drm/tegra/hdmi.c                       |  8 +++
 include/drm/i915_pciids.h                          |  4 +-
 31 files changed, 235 insertions(+), 98 deletions(-)

Re: [git pull] drm fixes

[Linus Torvalds]

Hmm. I haven't updated the old Mac Mini I have in a *long* time, but
today I decided to try.

And it causes problems in drm.

I'm not sure how new these problems are, I think the previous kernel I
booted on this machine was 3.16. But I thought I'd better report them
as-is, because bisection on this thing takes *forever*, and it's quite
possible that you or one of the i915 guys goes "ahh, of course", so no
point in wasting time on bisection unless absolutely required.

Anyway, I have two warnings, and then had to do a work-around to avoid an oops.

Warning #1:

    ...
    fbcon: inteldrmfb (fb0) is primary device
    random: nonblocking pool is initialized
    [drm] Setting output timings on SDVOB failed
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 15 at drivers/gpu/drm/i915/i915_gem.c:4524
i915_gem_free_object+0x22d/0x250()
    WARN_ON(obj->frontbuffer_bits)
    CPU: 1 PID: 15 Comm: kworker/u4:1 Tainted: G        W
4.0.0-rc1-00129-g6380ad5-dirty #3
    Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
    Workqueue: events_unbound async_run_entry_fn
    Call Trace:
      dump_stack+0x41/0x52
      warn_slowpath_common+0x7f/0xb0
      warn_slowpath_fmt+0x2e/0x30
      i915_gem_free_object+0x22d/0x250
      drm_gem_object_free+0x1a/0x20
      intel_user_framebuffer_destroy+0x5d/0x80
      drm_framebuffer_free+0x43/0x60
      drm_framebuffer_unreference+0x28/0x60
      drm_mode_set_config_internal+0x8e/0xc0
      restore_fbdev_mode+0xc2/0xf0
      drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
      drm_fb_helper_set_par+0x1d/0x40
      intel_fbdev_set_par+0x18/0x60
      fbcon_init+0x4e2/0x530
      do_bind_con_driver+0x15e/0x330
      do_take_over_console+0xd5/0x160
      do_fbcon_takeover+0x5d/0xc0
      fbcon_event_notify+0x5dd/0x760
      notifier_call_chain+0x41/0x60
      __blocking_notifier_call_chain+0x46/0x60
      blocking_notifier_call_chain+0x1a/0x20
      fb_notifier_call_chain+0x11/0x20
      register_framebuffer+0x1f2/0x2f0
      drm_fb_helper_initial_config+0x2aa/0x370
      intel_fbdev_initial_config+0x14/0x20
      async_run_entry_fn+0x31/0xd0
      process_one_work+0xee/0x2b0
      worker_thread+0x39/0x400
      kthread+0xac/0xd0
      ret_from_kernel_thread+0x21/0x30
    ---[ end trace e533d8d502f4f45e ]---
    Console: switching to colour frame buffer device 210x65
    ...

but things seemed to work despite it. The more scary warning is #2:

    ...
    dracut: Starting plymouth daemon
    usb 5-1: new full-speed USB device number 2 using uhci_hcd
    setfont (1129) used greatest stack depth: 6448 bytes left
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 1127 at include/linux/kref.h:47
drm_framebuffer_reference+0x39/0x70()
    CPU: 1 PID: 1127 Comm: plymouthd Tainted: G        W
4.0.0-rc1-00129-g6380ad5-dirty #3
    Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
    Call Trace:
      dump_stack+0x41/0x52
      warn_slowpath_common+0x7f/0xb0
      warn_slowpath_null+0x1d/0x20
      drm_framebuffer_reference+0x39/0x70
      intel_plane_duplicate_state+0x36/0x70
      drm_plane_helper_update+0x24/0xc0
      __intel_set_mode+0x71c/0x9c0
      intel_set_mode+0x6b/0x90
      intel_get_load_detect_pipe+0x332/0x470
      intel_tv_detect+0x84/0x4e0
      drm_helper_probe_single_connector_modes_merge_bits+0x1a3/0x440
      drm_helper_probe_single_connector_modes+0x12/0x20
      drm_mode_getconnector+0x2e7/0x320
      drm_ioctl+0x1e5/0x560
      do_vfs_ioctl+0x71/0x590
      SyS_ioctl+0x92/0xa0
      syscall_call+0x7/0x7
    ---[ end trace e533d8d502f4f460 ]---
    usb 5-1: New USB device found, idVendor=05ac, idProduct=1000
    usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    ...

which is scary because it implies some bad reference counting problem.
And in fact, that warning was followed by a NULL pointer oops, which I
worked around with this crazy patch:

    diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
    index 6b6b07f..28527ac 100644
    --- a/drivers/gpu/drm/drm_crtc.c
    +++ b/drivers/gpu/drm/drm_crtc.c
    @@ -452,7 +452,8 @@ static void drm_framebuffer_free(struct kref *kref)
            }
            mutex_unlock(&dev->mode_config.fb_lock);

    -       fb->funcs->destroy(fb);
    +       if (fb->funcs)
    +               fb->funcs->destroy(fb);
     }

     static struct drm_framebuffer *__drm_framebuffer_lookup(struct
drm_device *dev,

because "fb->funcs" was NULL. I assume it was NULL because some fb
freeing had cleared them already due to the kref going down to zero.

Any ideas? This is an ancient box with ancient user land, and not
getting a lot of testing. But it *used* to work.

                         Linus

Re: [git pull] drm fixes

[Linus Torvalds]

On Sat, Feb 28, 2015 at 9:40 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'm not sure how new these problems are, I think the previous kernel I
> booted on this machine was 3.16.

Hmm. 3.19 works fine, even if it ends up spewing

    WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
drm_wait_one_vblank+0x125/0x130()
    vblank not available on crtc 1, ret=-22

a lot. But it doesn't have the problems I saw with current -git.

So it's new to this merge window.

I'll see how painful it is to bisect it,

           Linus

Re: [git pull] drm fixes

[Linus Torvalds]

On Sat, Feb 28, 2015 at 10:08 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll see how painful it is to bisect it,

Not surprisingly, it went right for the drm merge.

Commit 8c334ce8f0fe ("Merge branch 'timers-core-for-linus'..") is
good, while the next merge commit 796e1c55717e ("Merge branch
'drm-next' ..") is bad and doesn't boot.

I'll try to narrow it down at least a *bit* more, even if it's a
painfully slow machine.

           Linus

Re: [git pull] drm fixes

[Linus Torvalds]

On Sat, Feb 28, 2015 at 11:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll try to narrow it down at least a *bit* more, even if it's a
> painfully slow machine.

It was brought in by either

  Merge tag 'topic/atomic-core-2015-01-05'

or

  Merge tag 'topic/core-stuff-2014-12-19'

with the atomic stuff being the prime suspect (b46004b70367 is good,
so is 4b08eae52f2f and dafffda023b0).

The compiles should be going faster now that I'm getting closer, so
I'll have a tighter bisect soon. Knock wood.

           Linus

Re: [git pull] drm fixes

[Linus Torvalds]

On Sun, Mar 1, 2015 at 12:35 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The compiles should be going faster now that I'm getting closer, so
> I'll have a tighter bisect soon. Knock wood.

Grr.

I found:

  ccfc08655d5fd5076828f45fb09194c070f2f63a is the first bad commit

but that boot failure is apparently fixed by 2caa80e72b57.

So my bisect seems to be worthless, because there were two independent
boot failures, and it found the known one.

Back to the drawing board.

            Linus

Re: [git pull] drm fixes

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Back to the drawing board.

Ok, many hours later, but I found it.

The bisection was a disaster, having to work around other bugs in this
area, but it ended up getting "close enough" that I figured out what
went wrong.

The "intel_plane_duplicate_state()" is horribly horribly buggy. It
looks at the state->fb pointer, but it may have been free'd already.

This workaround "works for me", but it's really still very
questionable, because while the "kref_get_unless_zero()" works
correctly when the last reference has been dropped, I'm not sure that
there is any guarantee that the whole allocation even exists any more,
so I think the *correct* thing to do would be to clear state->fb when
dropping the kref. But this was the smallest working patch I could
come up with. Somebody who actually knows the code should start
looking at the places that do drm_framebuffer_unreference(), and
actually clear that pointer instead.

Added Matt Roper and Ander Conselvan de Oliveira to the discussion,
since they are the ones git says are involved with the original broken
intel_plane_duplicate_state().

Anyway, attached is

 (a) the patch with a big comment

 (b) the warnings I get on that machine that show where this problem
triggers (and another warning earlier).

Comments? I'm sure this probably only triggers with *old* X servers
that don't do all the modern dri stuff.

                               Linus

[-- Attachment #2: 0001-Workaround-for-drm-bug.patch --]
[-- Type: text/x-patch, Size: 1424 bytes --]

From c182b15c3abee75cdc9d9564b6ab826403690f4e Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@localhost.localdomain>
Date: Sat, 28 Feb 2015 21:44:48 -0800
Subject: [PATCH] Workaround for drm bug

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 9e6f727..72714d3 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -85,8 +85,23 @@ intel_plane_duplicate_state(struct drm_plane *plane)
 		return NULL;
 
 	state = &intel_state->base;
-	if (state->fb)
-		drm_framebuffer_reference(state->fb);
+
+	/*
+	 * We cannot do drm_framebuffer_reference(), because the reference
+	 * may already have been dropped.
+	 *
+	 * So we do what drm_framebuffer_lookup() does, namely do a
+	 * kref_get_unless_zero(). Even that is somewhat questionable,
+	 * in that maybe the 'fb' already got free'd. So warn loudly
+	 * about this.
+	 *
+	 * Maybe the base.fb should be cleared by whatever drops the
+	 * reference?
+	 */
+	if (state->fb && !kref_get_unless_zero(&state->fb->refcount)) {
+		state->fb = NULL;
+		WARN_ONCE(1, "intel_plane_duplicate_state got plane with dead frame buffer");
+	}
 
 	return state;
 }
-- 
2.3.1.167.g7f4ba4b


[-- Attachment #3: drm-bug-dmesg --]
[-- Type: application/octet-stream, Size: 6501 bytes --]

...
[    0.898565] random: nonblocking pool is initialized
[    0.932621] [drm] Setting output timings on SDVOB failed
[    1.082274] ------------[ cut here ]------------
[    1.082283] WARNING: CPU: 0 PID: 15 at drivers/gpu/drm/i915/i915_gem.c:4524 i915_gem_free_object+0x22d/0x250()
[    1.082291] WARN_ON(obj->frontbuffer_bits)
[    1.082291] CPU: 0 PID: 15 Comm: kworker/u4:1 Tainted: G        W       4.0.0-rc1-00154-g7c7766e #39
[    1.082293] Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS     MM11.88Z.0055.B03.0604071521 04/07/06
[    1.082299] Workqueue: events_unbound async_run_entry_fn
[    1.082304]  00000000 00000000 f68cfb64 c166d337 c17ee3c4 f68cfb94 c103e3bf c17ee764
[    1.082309]  f68cfbc0 0000000f c17ee3c4 000011ac c12fe52d c12fe52d f69e0d00 00000000
[    1.082313]  f69e0d30 f68cfbac c103e43e 00000009 f68cfba4 c17ee764 f68cfbc0 f68cfbd8
[    1.082314] Call Trace:
[    1.082321]  [<c166d337>] dump_stack+0x41/0x52
[    1.082328]  [<c103e3bf>] warn_slowpath_common+0x7f/0xb0
[    1.082331]  [<c12fe52d>] ? i915_gem_free_object+0x22d/0x250
[    1.082334]  [<c12fe52d>] ? i915_gem_free_object+0x22d/0x250
[    1.082337]  [<c103e43e>] warn_slowpath_fmt+0x2e/0x30
[    1.082340]  [<c12fe52d>] i915_gem_free_object+0x22d/0x250
[    1.082344]  [<c166ed04>] ? mutex_lock+0x14/0x40
[    1.082348]  [<c12bafea>] drm_gem_object_free+0x1a/0x20
[    1.082353]  [<c1326d1d>] intel_user_framebuffer_destroy+0x5d/0x80
[    1.082356]  [<c166ed04>] ? mutex_lock+0x14/0x40
[    1.082360]  [<c12c3f33>] drm_framebuffer_free+0x43/0x60
[    1.082365]  [<c12c4588>] drm_framebuffer_unreference+0x28/0x60
[    1.082369]  [<c12c5c7e>] drm_mode_set_config_internal+0x8e/0xc0
[    1.082371]  [<c12b4e32>] restore_fbdev_mode+0xc2/0xf0
[    1.082375]  [<c12d3276>] ? __drm_modeset_lock_all+0xa6/0xe0
[    1.082379]  [<c12b7314>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
[    1.082382]  [<c12b737d>] drm_fb_helper_set_par+0x1d/0x40
[    1.082386]  [<c13452c8>] intel_fbdev_set_par+0x18/0x60
[    1.082390]  [<c1232b72>] fbcon_init+0x4e2/0x530
[    1.082395]  [<c115c230>] ? __kernfs_create_file+0x60/0x90
[    1.082400]  [<c129068e>] do_bind_con_driver+0x15e/0x330
[    1.082403]  [<c115cac7>] ? sysfs_create_file_ns+0x27/0x30
[    1.082406]  [<c136ecbf>] ? device_create_file+0x2f/0xa0
[    1.082411]  [<c1291a15>] do_take_over_console+0xd5/0x160
[    1.082414]  [<c1232c1d>] do_fbcon_takeover+0x5d/0xc0
[    1.082418]  [<c123757d>] fbcon_event_notify+0x5dd/0x760
[    1.082421]  [<c115c8fc>] ? sysfs_add_file_mode_ns+0x6c/0x1e0
[    1.082424]  [<c1054fe1>] notifier_call_chain+0x41/0x60
[    1.082427]  [<c10552b6>] __blocking_notifier_call_chain+0x46/0x60
[    1.082430]  [<c10552ea>] blocking_notifier_call_chain+0x1a/0x20
[    1.082432]  [<c123c501>] fb_notifier_call_chain+0x11/0x20
[    1.082435]  [<c123ebf2>] register_framebuffer+0x1f2/0x2f0
[    1.082439]  [<c12b713a>] drm_fb_helper_initial_config+0x2aa/0x370
[    1.082443]  [<c1345d14>] intel_fbdev_initial_config+0x14/0x20
[    1.082445]  [<c10565a1>] async_run_entry_fn+0x31/0xd0
[    1.082452]  [<c104f6c9>] ? pwq_dec_nr_in_flight+0x39/0x90
[    1.082455]  [<c104f80e>] process_one_work+0xee/0x2b0
[    1.082458]  [<c104fa39>] worker_thread+0x39/0x400
[    1.082461]  [<c105427c>] kthread+0xac/0xd0
[    1.082464]  [<c104fa00>] ? process_scheduled_works+0x30/0x30
[    1.082467]  [<c1670781>] ret_from_kernel_thread+0x21/0x30
[    1.082470]  [<c10541d0>] ? __kthread_parkme+0x60/0x60
[    1.082472] ---[ end trace 6309eba3c7a2324a ]---
[    1.094040] Console: switching to colour frame buffer device 210x65
...
[    2.903705] setfont (1128) used greatest stack depth: 6448 bytes left
[    2.915551] ------------[ cut here ]------------
[    2.917985] WARNING: CPU: 1 PID: 1126 at drivers/gpu/drm/i915/intel_atomic_plane.c:103 intel_plane_duplicate_state+0xc9/0xe0()
[    2.920518] intel_plane_duplicate_state got plane with dead frame buffer
[    2.920580] CPU: 1 PID: 1126 Comm: plymouthd Tainted: G        W       4.0.0-rc1-00154-g7c7766e #39
[    2.925701] Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS     MM11.88Z.0055.B03.0604071521 04/07/06
[    2.928344]  00000000 00000000 f628ba4c c166d337 c17f5fd0 f628ba7c c103e3bf c17f5ffc
[    2.931048]  f628baa8 00000466 c17f5fd0 00000067 c1348ae9 c1348ae9 f6b47f04 f6ba5480
[    2.933771]  f6b47380 f628ba94 c103e43e 00000009 f628ba8c c17f5ffc f628baa8 f628bab4
[    2.936491] Call Trace:
[    2.939141]  [<c166d337>] dump_stack+0x41/0x52
[    2.941776]  [<c103e3bf>] warn_slowpath_common+0x7f/0xb0
[    2.944445]  [<c1348ae9>] ? intel_plane_duplicate_state+0xc9/0xe0
[    2.947117]  [<c1348ae9>] ? intel_plane_duplicate_state+0xc9/0xe0
[    2.949800]  [<c103e43e>] warn_slowpath_fmt+0x2e/0x30
[    2.952480]  [<c1348ae9>] intel_plane_duplicate_state+0xc9/0xe0
[    2.955192]  [<c12ae154>] drm_plane_helper_update+0x24/0xc0
[    2.957927]  [<c1330d5c>] __intel_set_mode+0x71c/0x9c0
[    2.960635]  [<c13366cb>] intel_set_mode+0x6b/0x90
[    2.963342]  [<c1336b12>] intel_get_load_detect_pipe+0x332/0x470
[    2.966026]  [<c11fffff>] ? sg_last+0x2f/0x40
[    2.968698]  [<c11fb85a>] ? snprintf+0x1a/0x20
[    2.971334]  [<c12caf24>] ? drm_mode_set_name+0x44/0x50
[    2.973968]  [<c1367b24>] intel_tv_detect+0x84/0x4e0
[    2.976599]  [<c105fed3>] ? update_cfs_rq_blocked_load+0x123/0x170
[    2.979249]  [<c12ad573>] drm_helper_probe_single_connector_modes_merge_bits+0x1a3/0x440
[    2.981936]  [<c166ed04>] ? mutex_lock+0x14/0x40
[    2.993074]  [<c12ad842>] drm_helper_probe_single_connector_modes+0x12/0x20
[    2.995760]  [<c12c7db7>] drm_mode_getconnector+0x2e7/0x320
[    2.998431]  [<c1038d72>] ? kmap_atomic_prot+0x42/0x110
[    3.001086]  [<c12bc6f5>] drm_ioctl+0x1e5/0x560
[    3.003725]  [<c12c7ad0>] ? get_properties+0xd0/0xd0
[    3.006376]  [<c10ea55b>] ? page_add_new_anon_rmap+0x5b/0x70
[    3.009000]  [<c11a3e3a>] ? avc_has_perm+0x2a/0x110
[    3.011614]  [<c10e25a1>] ? handle_mm_fault+0xcf1/0xea0
[    3.014189]  [<c12bc510>] ? drm_setversion+0x170/0x170
[    3.016766]  [<c110fd21>] do_vfs_ioctl+0x71/0x590
[    3.019327]  [<c11a8f3c>] ? inode_has_perm.clone.37+0x2c/0x40
[    3.021877]  [<c11a8fe1>] ? file_has_perm+0x91/0xa0
[    3.024430]  [<c11aa7e2>] ? selinux_file_ioctl+0x42/0xe0
[    3.026978]  [<c11102d2>] SyS_ioctl+0x92/0xa0
[    3.029532]  [<c1670912>] syscall_call+0x7/0x7
[    3.032058] ---[ end trace 6309eba3c7a2324c ]---
[    3.102207] usb 1-6.1: new full-speed USB device number 5 using ehci-pci
..

Re: [git pull] drm fixes

[Daniel Vetter]

On Sun, Mar 01, 2015 at 05:59:53PM -0800, Linus Torvalds wrote:
> On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Back to the drawing board.
> 
> Ok, many hours later, but I found it.
> 
> The bisection was a disaster, having to work around other bugs in this
> area, but it ended up getting "close enough" that I figured out what
> went wrong.

Sorry for all the bisect work. Ville dug as far as the load detect being
unhappy due to atomic last week. But since I general don't real mail on
w/e I've only seen this thread now.

> The "intel_plane_duplicate_state()" is horribly horribly buggy. It
> looks at the state->fb pointer, but it may have been free'd already.
> 
> This workaround "works for me", but it's really still very
> questionable, because while the "kref_get_unless_zero()" works
> correctly when the last reference has been dropped, I'm not sure that
> there is any guarantee that the whole allocation even exists any more,
> so I think the *correct* thing to do would be to clear state->fb when
> dropping the kref. But this was the smallest working patch I could
> come up with. Somebody who actually knows the code should start
> looking at the places that do drm_framebuffer_unreference(), and
> actually clear that pointer instead.
> 
> Added Matt Roper and Ander Conselvan de Oliveira to the discussion,
> since they are the ones git says are involved with the original broken
> intel_plane_duplicate_state().
> 
> Anyway, attached is
> 
>  (a) the patch with a big comment
> 
>  (b) the warnings I get on that machine that show where this problem
> triggers (and another warning earlier).
> 
> Comments? I'm sure this probably only triggers with *old* X servers
> that don't do all the modern dri stuff.

It's not old X servers but old machines which don't have hotplug
interrupts (or still have tv-out, which doesn't have hpd support
anywhere).

I'll dig into this now just fyi the rules about how plane->state should be
handled:
- you need plane->lock
- it's invariant once assigned, updates should only be done with a
  duplicate_state(), update state you want to change and the going through
  the atomic commit machinery
- drm_plane_state->fb should always be a full reference

But switching to atomic amounts to a full rewrite of the drm core and
drivers (semantics for modeset updates are totally different). So there's
lots of glue and ducttape going on to keep up the illusion for both old
code and partially transitioned driver. It's all a bit wobbly atm and
don't loook too closely at some of the hacks we have.

And can you please attach a bactrace of the WARN in your patch, just to
double-check you blow up at the same spot?

Thanks, Daniel

>                                Linus

> From c182b15c3abee75cdc9d9564b6ab826403690f4e Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@localhost.localdomain>
> Date: Sat, 28 Feb 2015 21:44:48 -0800
> Subject: [PATCH] Workaround for drm bug
> 
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 9e6f727..72714d3 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -85,8 +85,23 @@ intel_plane_duplicate_state(struct drm_plane *plane)
>  		return NULL;
>  
>  	state = &intel_state->base;
> -	if (state->fb)
> -		drm_framebuffer_reference(state->fb);
> +
> +	/*
> +	 * We cannot do drm_framebuffer_reference(), because the reference
> +	 * may already have been dropped.
> +	 *
> +	 * So we do what drm_framebuffer_lookup() does, namely do a
> +	 * kref_get_unless_zero(). Even that is somewhat questionable,
> +	 * in that maybe the 'fb' already got free'd. So warn loudly
> +	 * about this.
> +	 *
> +	 * Maybe the base.fb should be cleared by whatever drops the
> +	 * reference?
> +	 */
> +	if (state->fb && !kref_get_unless_zero(&state->fb->refcount)) {
> +		state->fb = NULL;
> +		WARN_ONCE(1, "intel_plane_duplicate_state got plane with dead frame buffer");
> +	}
>  
>  	return state;
>  }
> -- 
> 2.3.1.167.g7f4ba4b
> 


> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [git pull] drm fixes

[Paul Bolle]

On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> Hmm. 3.19 works fine, even if it ends up spewing
> 
>     WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> drm_wait_one_vblank+0x125/0x130()
>     vblank not available on crtc 1, ret=-22
> 
> a lot.

For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
in http://lkml.kernel.org/r/20150131211609.GA3710@yulia-desktop .

Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
commit will end up in v3.19-stable in due time.


Paul Bolle

Re: [git pull] drm fixes

[Jani Nikula]

On Mon, 02 Mar 2015, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
>> Hmm. 3.19 works fine, even if it ends up spewing
>> 
>>     WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
>> drm_wait_one_vblank+0x125/0x130()
>>     vblank not available on crtc 1, ret=-22
>> 
>> a lot.
>
> For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
> in http://lkml.kernel.org/r/20150131211609.GA3710@yulia-desktop .
>
> Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
> encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
> commit will end up in v3.19-stable in due time.

Yes; the commit lacked cc: stable, I just requested a backport moments
before your mail [1].

BR,
Jani.


[1] http://mid.gmane.org/874mq3oif5.fsf@intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Mon, Mar 02, 2015 at 10:44:16AM +0100, Paul Bolle wrote:
> On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> > Hmm. 3.19 works fine, even if it ends up spewing
> > 
> >     WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> > drm_wait_one_vblank+0x125/0x130()
> >     vblank not available on crtc 1, ret=-22
> > 
> > a lot.
> 
> For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
> in http://lkml.kernel.org/r/20150131211609.GA3710@yulia-desktop .
> 
> Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
> encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
> commit will end up in v3.19-stable in due time.

Yeah we've forgotten to tag it as stable (it missed 3.19 by a notch and
we didn't add teh tag when moving it to the 3.20^W4.0 branch) but Jani
just sent out the mail for that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> And can you please attach a bactrace of the WARN in your patch, just to
> double-check you blow up at the same spot?

So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
addition to an unrelated(?) one from i915_gem_free_object()).

Or did you mean a backtrace of the oops when things go wrong, when my
patch is *not* applied? My first email had that with the kref.h
warning from drm_framebuffer_reference, which is otherwise the same
thing.

And after things go wrong, and the plane handling thing uses a
framebuffer that has already been freed, then the resulting oopses end
up being kind of random. Which was partly why it ended up beign so
hard to finally bisect, and I actually eventually gave up on it -
because sometimes things would just happen to work, sometimes things
would blow up and oops when X started (resulting in just a dead
machine), sometimes things would oops at bootup.

The most common oops was something going wrong when the framebuffer
was free'd for the second time, and it would cause a NULL pointer
dereference in drm_framebuffer_free() or one of the routines it called
(so often a NULL pointer dereference in
"mutex_lock(&dev->mode_config.fb_lock)" because "dev" was NULL, or the
call to "fb->funcs->destroy(fb)" would oops because "fb->funcs" was
NULL.

                         Linus

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Mon, Mar 2, 2015 at 5:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> And can you please attach a bactrace of the WARN in your patch, just to
>> double-check you blow up at the same spot?
>
> So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
> addition to an unrelated(?) one from i915_gem_free_object()).
>
> Or did you mean a backtrace of the oops when things go wrong, when my
> patch is *not* applied? My first email had that with the kref.h
> warning from drm_framebuffer_reference, which is otherwise the same
> thing.

I've mixed things up with the other reporter which was full of the
subsequent oopses. But after I've sorted out why drm-intel-next
doesn't blow up the same way I see the bug now. Still baffled that we
underrun the refcount apparently since the same pile of legacy code +
atomic glue is used for the old modeset ioctl. But obviously something
is different, so still digging.

The gem_free_object backtrace is a completely unrelated issue. Fix for
that is in drm-intel-fixes and on the way to you:

commit 62e537f8d568347bbe4e00d7803a838750cdc618
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Tue Feb 24 13:37:54 2015 -0800

    drm/i915: Fix frontbuffer false positve.

If that one doesn't help please scream ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> 
> <snip>
> 
> >> Xi Ruoyao (1):
> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> 
> Turns out to be that commit.
> 
> git bisect start 'drivers/gpu/drm/i915/'
> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> plane->state->fb stays in sync with plane->fb
> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> 
> Doing a straight revert on top of 4.0-rc5 makes things work again,
> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> there.

Can you please test the tip of drm-fixes:

commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Feb 27 12:58:13 2015 +0100

    drm: Fixup racy refcounting in plane_force_disable

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1

Because fumble that patch didn't make it to drm-fixes a while ago and
instead landed in drm-next.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>
>> <snip>
>>
>> >> Xi Ruoyao (1):
>> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Turns out to be that commit.
>>
>> git bisect start 'drivers/gpu/drm/i915/'
>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> plane->state->fb stays in sync with plane->fb
>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> there.
>
> Can you please test the tip of drm-fixes:
>
> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Fri Feb 27 12:58:13 2015 +0100
>
>     drm: Fixup racy refcounting in plane_force_disable
>
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>
> Because fumble that patch didn't make it to drm-fixes a while ago and
> instead landed in drm-next.

That seems to have helped with totally different issues a macbook I
have was seeing.  However, it still doesn't fix the issue with the
Celeron based NUC machine.

I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to.  The
NUC still won't boot without HDMI connected.  With HDMI connected I
still see the trace below.  If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported yesterday
which starts with the same backtrace.

I'll try building a kernel with 319c1d4 reverted + your patch.  I
suspect things will work fine with that combination because the two
issues are unrelated.

josh

[  +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
drm sdhci_acpi sdhci mmc_core video
[  +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
4.0.0-0.rc5.git1.1.fc23.x86_64 #1
[  +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.000003]  0000000000000000 00000000b82c27d6 ffff88003f98f688
ffffffff8177ada9
[  +0.000004]  0000000000000000 0000000000000000 ffff88003f98f6c8
ffffffff8109c78a
[  +0.000004]  ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
ffff88003fae0000
[  +0.000004] Call Trace:
[  +0.000010]  [<ffffffff8177ada9>] dump_stack+0x45/0x57
[  +0.000005]  [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[  +0.000004]  [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[  +0.000012]  [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
[  +0.000016]  [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[  +0.000048]  [<ffffffffa014e8c5>]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[  +0.000015]  [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
[  +0.000031]  [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
[  +0.000027]  [<ffffffffa0128f5b>] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[  +0.000034]  [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
[  +0.000005]  [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
[  +0.000006]  [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
[  +0.000004]  [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
[  +0.000006]  [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
[  +0.000004]  [<ffffffff814cde27>] ? get_device+0x17/0x30
[  +0.000005]  [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
[  +0.000005]  [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
[  +0.000004]  [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
[  +0.000012]  [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
[  +0.000011]  [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
[  +0.000022]  [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
[  +0.000006]  [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
[  +0.000005]  [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[  +0.000004]  [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
[  +0.000005]  [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
[  +0.000004]  [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
[  +0.000004]  [<ffffffff814d3120>] ? __device_attach+0x40/0x40
[  +0.000004]  [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
[  +0.000004]  [<ffffffff814d27ee>] driver_attach+0x1e/0x20
[  +0.000004]  [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
[  +0.000004]  [<ffffffff814d39b4>] driver_register+0x64/0xf0
[  +0.000004]  [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
[  +0.000012]  [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
[  +0.000004]  [<ffffffffa01f4000>] ? 0xffffffffa01f4000
[  +0.000022]  [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
[  +0.000006]  [<ffffffff81002148>] do_one_initcall+0xd8/0x210
[  +0.000005]  [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
[  +0.000004]  [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
[  +0.000004]  [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
[  +0.000005]  [<ffffffff81120c4b>] load_module+0x20ab/0x2520
[  +0.000004]  [<ffffffff8111c550>] ? store_uevent+0x70/0x70
[  +0.000005]  [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
[  +0.000006]  [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
[  +0.000006]  [<ffffffff81781509>] system_call_fastpath+0x12/0x17
[  +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
[  +0.022245] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>
> >> <snip>
> >>
> >> >> Xi Ruoyao (1):
> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Turns out to be that commit.
> >>
> >> git bisect start 'drivers/gpu/drm/i915/'
> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >> plane->state->fb stays in sync with plane->fb
> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >> there.
> >
> > Can you please test the tip of drm-fixes:
> >
> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Fri Feb 27 12:58:13 2015 +0100
> >
> >     drm: Fixup racy refcounting in plane_force_disable
> >
> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >
> > Because fumble that patch didn't make it to drm-fixes a while ago and
> > instead landed in drm-next.
> 
> That seems to have helped with totally different issues a macbook I
> have was seeing.  However, it still doesn't fix the issue with the
> Celeron based NUC machine.
> 
> I built a kernel based on Linus' latest tree as of this morning,
> without reverting 319c1d4 and adding the commit you pointed to.  The
> NUC still won't boot without HDMI connected.  With HDMI connected I
> still see the trace below.  If I do the blacklist and then insmod
> dance with HDMI unplugged it shows the same spew I reported yesterday
> which starts with the same backtrace.
> 
> I'll try building a kernel with 319c1d4 reverted + your patch.  I
> suspect things will work fine with that combination because the two
> issues are unrelated.

Can you please boot with drm.debug=0xff for the below case and grab
complete dmesg? There'll be a lot of crap in the logs, you might need to
blow up the logbuf size massively. But that log should contain everything
I need to figure out where that framebuffer we're blowing up on is going.

Thanks, Daniel
> 
> josh
> 
> [  +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [  +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
> drm sdhci_acpi sdhci mmc_core video
> [  +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
> 4.0.0-0.rc5.git1.1.fc23.x86_64 #1
> [  +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [  +0.000003]  0000000000000000 00000000b82c27d6 ffff88003f98f688
> ffffffff8177ada9
> [  +0.000004]  0000000000000000 0000000000000000 ffff88003f98f6c8
> ffffffff8109c78a
> [  +0.000004]  ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
> ffff88003fae0000
> [  +0.000004] Call Trace:
> [  +0.000010]  [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [  +0.000005]  [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [  +0.000004]  [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [  +0.000012]  [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
> [  +0.000016]  [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
> [  +0.000048]  [<ffffffffa014e8c5>]
> i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
> [  +0.000015]  [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
> [  +0.000031]  [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
> [  +0.000027]  [<ffffffffa0128f5b>] ?
> valleyview_irq_postinstall+0x3b/0x50 [i915]
> [  +0.000034]  [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
> [  +0.000005]  [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
> [  +0.000006]  [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
> [  +0.000004]  [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
> [  +0.000006]  [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
> [  +0.000004]  [<ffffffff814cde27>] ? get_device+0x17/0x30
> [  +0.000005]  [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
> [  +0.000005]  [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
> [  +0.000004]  [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
> [  +0.000012]  [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
> [  +0.000011]  [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
> [  +0.000022]  [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
> [  +0.000006]  [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
> [  +0.000005]  [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
> [  +0.000004]  [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
> [  +0.000005]  [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
> [  +0.000004]  [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
> [  +0.000004]  [<ffffffff814d3120>] ? __device_attach+0x40/0x40
> [  +0.000004]  [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
> [  +0.000004]  [<ffffffff814d27ee>] driver_attach+0x1e/0x20
> [  +0.000004]  [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
> [  +0.000004]  [<ffffffff814d39b4>] driver_register+0x64/0xf0
> [  +0.000004]  [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
> [  +0.000012]  [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
> [  +0.000004]  [<ffffffffa01f4000>] ? 0xffffffffa01f4000
> [  +0.000022]  [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
> [  +0.000006]  [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> [  +0.000005]  [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
> [  +0.000004]  [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
> [  +0.000004]  [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
> [  +0.000005]  [<ffffffff81120c4b>] load_module+0x20ab/0x2520
> [  +0.000004]  [<ffffffff8111c550>] ? store_uevent+0x70/0x70
> [  +0.000005]  [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
> [  +0.000006]  [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
> [  +0.000006]  [<ffffffff81781509>] system_call_fastpath+0x12/0x17
> [  +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
> [  +0.022245] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >>
>> >> <snip>
>> >>
>> >> >> Xi Ruoyao (1):
>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Turns out to be that commit.
>> >>
>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >> plane->state->fb stays in sync with plane->fb
>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >> there.
>> >
>> > Can you please test the tip of drm-fixes:
>> >
>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> >
>> >     drm: Fixup racy refcounting in plane_force_disable
>> >
>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >
>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > instead landed in drm-next.
>>
>> That seems to have helped with totally different issues a macbook I
>> have was seeing.  However, it still doesn't fix the issue with the
>> Celeron based NUC machine.
>>
>> I built a kernel based on Linus' latest tree as of this morning,
>> without reverting 319c1d4 and adding the commit you pointed to.  The
>> NUC still won't boot without HDMI connected.  With HDMI connected I
>> still see the trace below.  If I do the blacklist and then insmod
>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> which starts with the same backtrace.
>>
>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>> suspect things will work fine with that combination because the two
>> issues are unrelated.
>
> Can you please boot with drm.debug=0xff for the below case and grab
> complete dmesg? There'll be a lot of crap in the logs, you might need to
> blow up the logbuf size massively. But that log should contain everything
> I need to figure out where that framebuffer we're blowing up on is going.

I provided both with HDMI attached and without (via insmod).  If you
want them emailed directly let me know, but they were large.

Boot with drm.debug=0xff and HDMI connected:

https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt

Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:

https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

josh

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>
>>> >> <snip>
>>> >>
>>> >> >> Xi Ruoyao (1):
>>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Turns out to be that commit.
>>> >>
>>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >> plane->state->fb stays in sync with plane->fb
>>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >> there.
>>> >
>>> > Can you please test the tip of drm-fixes:
>>> >
>>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>>> >
>>> >     drm: Fixup racy refcounting in plane_force_disable
>>> >
>>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >
>>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> > instead landed in drm-next.
>>>
>>> That seems to have helped with totally different issues a macbook I
>>> have was seeing.  However, it still doesn't fix the issue with the
>>> Celeron based NUC machine.
>>>
>>> I built a kernel based on Linus' latest tree as of this morning,
>>> without reverting 319c1d4 and adding the commit you pointed to.  The
>>> NUC still won't boot without HDMI connected.  With HDMI connected I
>>> still see the trace below.  If I do the blacklist and then insmod
>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> which starts with the same backtrace.
>>>
>>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>>> suspect things will work fine with that combination because the two
>>> issues are unrelated.
>>
>> Can you please boot with drm.debug=0xff for the below case and grab
>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> blow up the logbuf size massively. But that log should contain everything
>> I need to figure out where that framebuffer we're blowing up on is going.
>
> I provided both with HDMI attached and without (via insmod).  If you
> want them emailed directly let me know, but they were large.
>
> Boot with drm.debug=0xff and HDMI connected:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>
> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> manual insmod after boot:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

Here's one more from the macbook I mentioned.  It's showing the same
kref.h splat:

https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

josh

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>
> >>> >> <snip>
> >>> >>
> >>> >> >> Xi Ruoyao (1):
> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Turns out to be that commit.
> >>> >>
> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >> there.
> >>> >
> >>> > Can you please test the tip of drm-fixes:
> >>> >
> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
> >>> >
> >>> >     drm: Fixup racy refcounting in plane_force_disable
> >>> >
> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >
> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> > instead landed in drm-next.
> >>>
> >>> That seems to have helped with totally different issues a macbook I
> >>> have was seeing.  However, it still doesn't fix the issue with the
> >>> Celeron based NUC machine.
> >>>
> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
> >>> still see the trace below.  If I do the blacklist and then insmod
> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> which starts with the same backtrace.
> >>>
> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
> >>> suspect things will work fine with that combination because the two
> >>> issues are unrelated.
> >>
> >> Can you please boot with drm.debug=0xff for the below case and grab
> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >> blow up the logbuf size massively. But that log should contain everything
> >> I need to figure out where that framebuffer we're blowing up on is going.
> >
> > I provided both with HDMI attached and without (via insmod).  If you
> > want them emailed directly let me know, but they were large.
> >
> > Boot with drm.debug=0xff and HDMI connected:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >
> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> > manual insmod after boot:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> 
> Here's one more from the macbook I mentioned.  It's showing the same
> kref.h splat:
> 
> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

Ok there's at least one fixup for which we've failed to apply when porting
the fb refcounting fix from -next. Can you please cherry-pick

commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Thu Feb 5 18:30:20 2015 +0000

    drm/i915: Don't try to reference the fb in get_initial_plane_config()

>From linux-next?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >>> >>
>> >>> >> <snip>
>> >>> >>
>> >>> >> >> Xi Ruoyao (1):
>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>> >>
>> >>> >> Turns out to be that commit.
>> >>> >>
>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >>> >> plane->state->fb stays in sync with plane->fb
>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>> >>
>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >>> >> there.
>> >>> >
>> >>> > Can you please test the tip of drm-fixes:
>> >>> >
>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> >>> >
>> >>> >     drm: Fixup racy refcounting in plane_force_disable
>> >>> >
>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> >
>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> >>> > instead landed in drm-next.
>> >>>
>> >>> That seems to have helped with totally different issues a macbook I
>> >>> have was seeing.  However, it still doesn't fix the issue with the
>> >>> Celeron based NUC machine.
>> >>>
>> >>> I built a kernel based on Linus' latest tree as of this morning,
>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
>> >>> still see the trace below.  If I do the blacklist and then insmod
>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> >>> which starts with the same backtrace.
>> >>>
>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>> >>> suspect things will work fine with that combination because the two
>> >>> issues are unrelated.
>> >>
>> >> Can you please boot with drm.debug=0xff for the below case and grab
>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> >> blow up the logbuf size massively. But that log should contain everything
>> >> I need to figure out where that framebuffer we're blowing up on is going.
>> >
>> > I provided both with HDMI attached and without (via insmod).  If you
>> > want them emailed directly let me know, but they were large.
>> >
>> > Boot with drm.debug=0xff and HDMI connected:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>> >
>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>> > manual insmod after boot:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>
>> Here's one more from the macbook I mentioned.  It's showing the same
>> kref.h splat:
>>
>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>
> Ok there's at least one fixup for which we've failed to apply when porting
> the fb refcounting fix from -next. Can you please cherry-pick
>
> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date:   Thu Feb 5 18:30:20 2015 +0000
>
>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> From linux-next?

Yes, building now.  Will let you know as soon as I test it on both machines.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>> >>
>>> >>> >> <snip>
>>> >>> >>
>>> >>> >> >> Xi Ruoyao (1):
>>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Turns out to be that commit.
>>> >>> >>
>>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >>> >> plane->state->fb stays in sync with plane->fb
>>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >>> >> there.
>>> >>> >
>>> >>> > Can you please test the tip of drm-fixes:
>>> >>> >
>>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>>> >>> >
>>> >>> >     drm: Fixup racy refcounting in plane_force_disable
>>> >>> >
>>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> >
>>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> >>> > instead landed in drm-next.
>>> >>>
>>> >>> That seems to have helped with totally different issues a macbook I
>>> >>> have was seeing.  However, it still doesn't fix the issue with the
>>> >>> Celeron based NUC machine.
>>> >>>
>>> >>> I built a kernel based on Linus' latest tree as of this morning,
>>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
>>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
>>> >>> still see the trace below.  If I do the blacklist and then insmod
>>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> >>> which starts with the same backtrace.
>>> >>>
>>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>>> >>> suspect things will work fine with that combination because the two
>>> >>> issues are unrelated.
>>> >>
>>> >> Can you please boot with drm.debug=0xff for the below case and grab
>>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>> >> blow up the logbuf size massively. But that log should contain everything
>>> >> I need to figure out where that framebuffer we're blowing up on is going.
>>> >
>>> > I provided both with HDMI attached and without (via insmod).  If you
>>> > want them emailed directly let me know, but they were large.
>>> >
>>> > Boot with drm.debug=0xff and HDMI connected:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>> >
>>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>> > manual insmod after boot:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>
>>> Here's one more from the macbook I mentioned.  It's showing the same
>>> kref.h splat:
>>>
>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>
>> Ok there's at least one fixup for which we've failed to apply when porting
>> the fb refcounting fix from -next. Can you please cherry-pick
>>
>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> Author: Damien Lespiau <damien.lespiau@intel.com>
>> Date:   Thu Feb 5 18:30:20 2015 +0000
>>
>>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>
>> From linux-next?
>
> Yes, building now.  Will let you know as soon as I test it on both machines.

OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless.  I still see the backtrace below on both
the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
the NUC here:

https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt

Getting better at least :).

josh

[  +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[  +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
bit banging on pin 2
[  +0.012442] fbcon: inteldrmfb (fb0) is primary device
[  +0.000103] ------------[ cut here ]------------
[  +0.000024] WARNING: CPU: 1 PID: 109 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[  +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
sdhci_pci sdhci mmc_core video
[  +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
4.0.0-0.rc5.git1.3.fc23.x86_64 #1
[  +0.000001] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[  +0.000005] Workqueue: events_unbound async_run_entry_fn
[  +0.000003]  0000000000000000 00000000cbdcc84e ffff8802628bb868
ffffffff8177ada9
[  +0.000002]  0000000000000000 0000000000000000 ffff8802628bb8a8
ffffffff8109c78a
[  +0.000002]  ffff88026154c940 0000000000000048 ffff880262b1e600
ffff88026229e2a0
[  +0.000001] Call Trace:
[  +0.000007]  [<ffffffff8177ada9>] dump_stack+0x45/0x57
[  +0.000003]  [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[  +0.000003]  [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[  +0.000014]  [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
[  +0.000005]  [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[  +0.000013]  [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
[  +0.000008]  [<ffffffffa00c371d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[  +0.000013]  [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[  +0.000006]  [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[  +0.000006]  [<ffffffffa00c75c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[  +0.000006]  [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[  +0.000042]  [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[  +0.000005]  [<ffffffff8140c328>] fbcon_init+0x578/0x600
[  +0.000005]  [<ffffffff8148ceac>] visual_init+0xbc/0x120
[  +0.000004]  [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
[  +0.000007]  [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
[  +0.000013]  [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
[  +0.000003]  [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
[  +0.000005]  [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
[  +0.000003]  [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
[  +0.000002]  [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
[  +0.000003]  [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
[  +0.000013]  [<ffffffff81415184>] register_framebuffer+0x214/0x360
[  +0.000007]  [<ffffffffa00c78d4>]
drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
[  +0.000004]  [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
[  +0.000034]  [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
[  +0.000002]  [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
[  +0.000002]  [<ffffffff810b552c>] process_one_work+0x14c/0x400
[  +0.000002]  [<ffffffff810b5fb3>] worker_thread+0x53/0x470
[  +0.000003]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[  +0.000002]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[  +0.000002]  [<ffffffff810bb1f8>] kthread+0xd8/0xf0
[  +0.000004]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[  +0.000004]  [<ffffffff81781458>] ret_from_fork+0x58/0x90
[  +0.000003]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[  +0.000002] ---[ end trace a73ba186968c6ec8 ]---

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> >     drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing.  However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
> >>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
> >>> >>> still see the trace below.  If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod).  If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned.  It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> >>
> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now.  Will let you know as soon as I test it on both machines.
> 
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless.  I still see the backtrace below on both
> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> the NUC here:
> 
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> 
> Getting better at least :).

Ok thanks for testing. I'll look at that one tomorrow, wasted too much
time with trying to resurrect a few machines that should have matched the
common parts of what goes wrong here.

Jani, can you please cherry-pick the above commit to -fixes?

One more question: Is the frontbuffer_bits splat now also gone? That was
the one I have no clue about, but since somewhere around 4.0-rc it started
poppping up in a few places ... Thus far it was always the canary for some
other bug though.

Thanks, Daniel

> 
> josh
> 
> [  +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> [  +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
> bit banging on pin 2
> [  +0.012442] fbcon: inteldrmfb (fb0) is primary device
> [  +0.000103] ------------[ cut here ]------------
> [  +0.000024] WARNING: CPU: 1 PID: 109 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [  +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
> sdhci_pci sdhci mmc_core video
> [  +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
> 4.0.0-0.rc5.git1.3.fc23.x86_64 #1
> [  +0.000001] Hardware name: Apple Inc.
> MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
> MBP102.88Z.0106.B03.1211161133 11/16/2012
> [  +0.000005] Workqueue: events_unbound async_run_entry_fn
> [  +0.000003]  0000000000000000 00000000cbdcc84e ffff8802628bb868
> ffffffff8177ada9
> [  +0.000002]  0000000000000000 0000000000000000 ffff8802628bb8a8
> ffffffff8109c78a
> [  +0.000002]  ffff88026154c940 0000000000000048 ffff880262b1e600
> ffff88026229e2a0
> [  +0.000001] Call Trace:
> [  +0.000007]  [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [  +0.000003]  [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [  +0.000003]  [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [  +0.000014]  [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
> [  +0.000005]  [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [  +0.000013]  [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
> [  +0.000008]  [<ffffffffa00c371d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [  +0.000013]  [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [  +0.000006]  [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [  +0.000006]  [<ffffffffa00c75c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [  +0.000006]  [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [  +0.000042]  [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [  +0.000005]  [<ffffffff8140c328>] fbcon_init+0x578/0x600
> [  +0.000005]  [<ffffffff8148ceac>] visual_init+0xbc/0x120
> [  +0.000004]  [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
> [  +0.000007]  [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
> [  +0.000013]  [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
> [  +0.000003]  [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
> [  +0.000005]  [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
> [  +0.000003]  [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
> [  +0.000002]  [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
> [  +0.000003]  [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
> [  +0.000013]  [<ffffffff81415184>] register_framebuffer+0x214/0x360
> [  +0.000007]  [<ffffffffa00c78d4>]
> drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> [  +0.000004]  [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
> [  +0.000034]  [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> [  +0.000002]  [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
> [  +0.000002]  [<ffffffff810b552c>] process_one_work+0x14c/0x400
> [  +0.000002]  [<ffffffff810b5fb3>] worker_thread+0x53/0x470
> [  +0.000003]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [  +0.000002]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [  +0.000002]  [<ffffffff810bb1f8>] kthread+0xd8/0xf0
> [  +0.000004]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [  +0.000004]  [<ffffffff81781458>] ret_from_fork+0x58/0x90
> [  +0.000003]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [  +0.000002] ---[ end trace a73ba186968c6ec8 ]---

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> > >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> > >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> > >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > >>> >>> >>
> > >>> >>> >> <snip>
> > >>> >>> >>
> > >>> >>> >> >> Xi Ruoyao (1):
> > >>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> > >>> >>> >>
> > >>> >>> >> Turns out to be that commit.
> > >>> >>> >>
> > >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> > >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> > >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> > >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> > >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> > >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> > >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> > >>> >>> >> plane->state->fb stays in sync with plane->fb
> > >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> > >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> > >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> > >>> >>> >>
> > >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> > >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> > >>> >>> >> there.
> > >>> >>> >
> > >>> >>> > Can you please test the tip of drm-fixes:
> > >>> >>> >
> > >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > >>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
> > >>> >>> >
> > >>> >>> >     drm: Fixup racy refcounting in plane_force_disable
> > >>> >>> >
> > >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > >>> >>> >
> > >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> > >>> >>> > instead landed in drm-next.
> > >>> >>>
> > >>> >>> That seems to have helped with totally different issues a macbook I
> > >>> >>> have was seeing.  However, it still doesn't fix the issue with the
> > >>> >>> Celeron based NUC machine.
> > >>> >>>
> > >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> > >>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
> > >>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
> > >>> >>> still see the trace below.  If I do the blacklist and then insmod
> > >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> > >>> >>> which starts with the same backtrace.
> > >>> >>>
> > >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
> > >>> >>> suspect things will work fine with that combination because the two
> > >>> >>> issues are unrelated.
> > >>> >>
> > >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> > >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> > >>> >> blow up the logbuf size massively. But that log should contain everything
> > >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> > >>> >
> > >>> > I provided both with HDMI attached and without (via insmod).  If you
> > >>> > want them emailed directly let me know, but they were large.
> > >>> >
> > >>> > Boot with drm.debug=0xff and HDMI connected:
> > >>> >
> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> > >>> >
> > >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> > >>> > manual insmod after boot:
> > >>> >
> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> > >>>
> > >>> Here's one more from the macbook I mentioned.  It's showing the same
> > >>> kref.h splat:
> > >>>
> > >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> > >>
> > >> Ok there's at least one fixup for which we've failed to apply when porting
> > >> the fb refcounting fix from -next. Can you please cherry-pick
> > >>
> > >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> > >> Author: Damien Lespiau <damien.lespiau@intel.com>
> > >> Date:   Thu Feb 5 18:30:20 2015 +0000
> > >>
> > >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> > >>
> > >> From linux-next?
> > >
> > > Yes, building now.  Will let you know as soon as I test it on both machines.
> > 
> > OK, with that commit applied I no longer get the kref.h splat and the
> > NUC machine boots headless.  I still see the backtrace below on both
> > the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> > the NUC here:
> > 
> > https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> > 
> > Getting better at least :).
> 
> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
> time with trying to resurrect a few machines that should have matched the
> common parts of what goes wrong here.
> 
> Jani, can you please cherry-pick the above commit to -fixes?

Actually add Jani this time around ...
-Daniel

> 
> One more question: Is the frontbuffer_bits splat now also gone? That was
> the one I have no clue about, but since somewhere around 4.0-rc it started
> poppping up in a few places ... Thus far it was always the canary for some
> other bug though.
> 
> Thanks, Daniel
> 
> > 
> > josh
> > 
> > [  +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> > [  +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
> > bit banging on pin 2
> > [  +0.012442] fbcon: inteldrmfb (fb0) is primary device
> > [  +0.000103] ------------[ cut here ]------------
> > [  +0.000024] WARNING: CPU: 1 PID: 109 at
> > drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> > [drm]()
> > [  +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
> > sdhci_pci sdhci mmc_core video
> > [  +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
> > 4.0.0-0.rc5.git1.3.fc23.x86_64 #1
> > [  +0.000001] Hardware name: Apple Inc.
> > MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
> > MBP102.88Z.0106.B03.1211161133 11/16/2012
> > [  +0.000005] Workqueue: events_unbound async_run_entry_fn
> > [  +0.000003]  0000000000000000 00000000cbdcc84e ffff8802628bb868
> > ffffffff8177ada9
> > [  +0.000002]  0000000000000000 0000000000000000 ffff8802628bb8a8
> > ffffffff8109c78a
> > [  +0.000002]  ffff88026154c940 0000000000000048 ffff880262b1e600
> > ffff88026229e2a0
> > [  +0.000001] Call Trace:
> > [  +0.000007]  [<ffffffff8177ada9>] dump_stack+0x45/0x57
> > [  +0.000003]  [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> > [  +0.000003]  [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> > [  +0.000014]  [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
> > [  +0.000005]  [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> > [  +0.000013]  [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
> > [  +0.000008]  [<ffffffffa00c371d>]
> > drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> > [  +0.000013]  [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> > [  +0.000006]  [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
> > [drm_kms_helper]
> > [  +0.000006]  [<ffffffffa00c75c9>]
> > drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> > [  +0.000006]  [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
> > [drm_kms_helper]
> > [  +0.000042]  [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
> > [  +0.000005]  [<ffffffff8140c328>] fbcon_init+0x578/0x600
> > [  +0.000005]  [<ffffffff8148ceac>] visual_init+0xbc/0x120
> > [  +0.000004]  [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
> > [  +0.000007]  [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
> > [  +0.000013]  [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
> > [  +0.000003]  [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
> > [  +0.000005]  [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
> > [  +0.000003]  [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
> > [  +0.000002]  [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
> > [  +0.000003]  [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
> > [  +0.000013]  [<ffffffff81415184>] register_framebuffer+0x214/0x360
> > [  +0.000007]  [<ffffffffa00c78d4>]
> > drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> > [  +0.000004]  [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
> > [  +0.000034]  [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> > [  +0.000002]  [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
> > [  +0.000002]  [<ffffffff810b552c>] process_one_work+0x14c/0x400
> > [  +0.000002]  [<ffffffff810b5fb3>] worker_thread+0x53/0x470
> > [  +0.000003]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> > [  +0.000002]  [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> > [  +0.000002]  [<ffffffff810bb1f8>] kthread+0xd8/0xf0
> > [  +0.000004]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> > [  +0.000004]  [<ffffffff81781458>] ret_from_fork+0x58/0x90
> > [  +0.000003]  [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> > [  +0.000002] ---[ end trace a73ba186968c6ec8 ]---
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> > >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> > >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> > >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > >>> >>> >>
>> > >>> >>> >> <snip>
>> > >>> >>> >>
>> > >>> >>> >> >> Xi Ruoyao (1):
>> > >>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Turns out to be that commit.
>> > >>> >>> >>
>> > >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> > >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> > >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> > >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> > >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> > >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> > >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> > >>> >>> >> plane->state->fb stays in sync with plane->fb
>> > >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> > >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> > >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> > >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> > >>> >>> >> there.
>> > >>> >>> >
>> > >>> >>> > Can you please test the tip of drm-fixes:
>> > >>> >>> >
>> > >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > >>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> > >>> >>> >
>> > >>> >>> >     drm: Fixup racy refcounting in plane_force_disable
>> > >>> >>> >
>> > >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> >
>> > >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > >>> >>> > instead landed in drm-next.
>> > >>> >>>
>> > >>> >>> That seems to have helped with totally different issues a macbook I
>> > >>> >>> have was seeing.  However, it still doesn't fix the issue with the
>> > >>> >>> Celeron based NUC machine.
>> > >>> >>>
>> > >>> >>> I built a kernel based on Linus' latest tree as of this morning,
>> > >>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
>> > >>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
>> > >>> >>> still see the trace below.  If I do the blacklist and then insmod
>> > >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> > >>> >>> which starts with the same backtrace.
>> > >>> >>>
>> > >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>> > >>> >>> suspect things will work fine with that combination because the two
>> > >>> >>> issues are unrelated.
>> > >>> >>
>> > >>> >> Can you please boot with drm.debug=0xff for the below case and grab
>> > >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> > >>> >> blow up the logbuf size massively. But that log should contain everything
>> > >>> >> I need to figure out where that framebuffer we're blowing up on is going.
>> > >>> >
>> > >>> > I provided both with HDMI attached and without (via insmod).  If you
>> > >>> > want them emailed directly let me know, but they were large.
>> > >>> >
>> > >>> > Boot with drm.debug=0xff and HDMI connected:
>> > >>> >
>> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>> > >>> >
>> > >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>> > >>> > manual insmod after boot:
>> > >>> >
>> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>> > >>>
>> > >>> Here's one more from the macbook I mentioned.  It's showing the same
>> > >>> kref.h splat:
>> > >>>
>> > >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>> > >>
>> > >> Ok there's at least one fixup for which we've failed to apply when porting
>> > >> the fb refcounting fix from -next. Can you please cherry-pick
>> > >>
>> > >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> > >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> > >> Date:   Thu Feb 5 18:30:20 2015 +0000
>> > >>
>> > >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> > >>
>> > >> From linux-next?
>> > >
>> > > Yes, building now.  Will let you know as soon as I test it on both machines.
>> >
>> > OK, with that commit applied I no longer get the kref.h splat and the
>> > NUC machine boots headless.  I still see the backtrace below on both
>> > the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> > the NUC here:
>> >
>> > https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >
>> > Getting better at least :).
>>
>> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
>> time with trying to resurrect a few machines that should have matched the
>> common parts of what goes wrong here.
>>
>> Jani, can you please cherry-pick the above commit to -fixes?
>
> Actually add Jani this time around ...
> -Daniel
>
>>
>> One more question: Is the frontbuffer_bits splat now also gone? That was
>> the one I have no clue about, but since somewhere around 4.0-rc it started
>> poppping up in a few places ... Thus far it was always the canary for some
>> other bug though.

As far as I can tell, it's gone.  I don't see it on any of my i915
machines running the kernel with those two patches.  I'll keep an eye
out for it as we work through 4.0-rcX.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

On 03/25/2015 at 12:54 AM, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>>>> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>>>>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>>>>>>>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>>> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>>>>>>>>>>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> <snip>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Xi Ruoyao (1):
>>>>>>>>>>>>>>        drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> Turns out to be that commit.
>>>>>>>>>>>>
>>>>>>>>>>>> git bisect start 'drivers/gpu/drm/i915/'
>>>>>>>>>>>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>>>>>>>>>>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>>>>>>>>>>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>>>>>>>>>>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>>>>>>>>>>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>>>>>>>>>>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>>>>>>>>>>> plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>>>>>>>>>>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>>>>>>>>>>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>>
>>>>>>>>>>>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>>>>>>>>>>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>>>>>>>>>>> there.
>>>>>>>>>>> Can you please test the tip of drm-fixes:
>>>>>>>>>>>
>>>>>>>>>>> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>>>>>> Date:   Fri Feb 27 12:58:13 2015 +0100
>>>>>>>>>>>
>>>>>>>>>>>      drm: Fixup racy refcounting in plane_force_disable
>>>>>>>>>>>
>>>>>>>>>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>>
>>>>>>>>>>> Because fumble that patch didn't make it to drm-fixes a while ago and
>>>>>>>>>>> instead landed in drm-next.
>>>>>>>>>> That seems to have helped with totally different issues a macbook I
>>>>>>>>>> have was seeing.  However, it still doesn't fix the issue with the
>>>>>>>>>> Celeron based NUC machine.
>>>>>>>>>>
>>>>>>>>>> I built a kernel based on Linus' latest tree as of this morning,
>>>>>>>>>> without reverting 319c1d4 and adding the commit you pointed to.  The
>>>>>>>>>> NUC still won't boot without HDMI connected.  With HDMI connected I
>>>>>>>>>> still see the trace below.  If I do the blacklist and then insmod
>>>>>>>>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>>>>>>>>> which starts with the same backtrace.
>>>>>>>>>>
>>>>>>>>>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>>>>>>>>>> suspect things will work fine with that combination because the two
>>>>>>>>>> issues are unrelated.
>>>>>>>>> Can you please boot with drm.debug=0xff for the below case and grab
>>>>>>>>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>>>>>>>> blow up the logbuf size massively. But that log should contain everything
>>>>>>>>> I need to figure out where that framebuffer we're blowing up on is going.
>>>>>>>> I provided both with HDMI attached and without (via insmod).  If you
>>>>>>>> want them emailed directly let me know, but they were large.
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff and HDMI connected:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>>>>>>> manual insmod after boot:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>>>>> Here's one more from the macbook I mentioned.  It's showing the same
>>>>>>> kref.h splat:
>>>>>>>
>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>>>>> Ok there's at least one fixup for which we've failed to apply when porting
>>>>>> the fb refcounting fix from -next. Can you please cherry-pick
>>>>>>
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date:   Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>>      drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>>  From linux-next?
>>>>> Yes, building now.  Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless.  I still see the backtrace below on both
>>>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
>>> time with trying to resurrect a few machines that should have matched the
>>> common parts of what goes wrong here.
>>>
>>> Jani, can you please cherry-pick the above commit to -fixes?
>> Actually add Jani this time around ...
>> -Daniel
>>
>>> One more question: Is the frontbuffer_bits splat now also gone? That was
>>> the one I have no clue about, but since somewhere around 4.0-rc it started
>>> poppping up in a few places ... Thus far it was always the canary for some
>>> other bug though.
> As far as I can tell, it's gone.  I don't see it on any of my i915
> machines running the kernel with those two patches.  I'll keep an eye
> out for it as we work through 4.0-rcX.
>
> josh
It's fortunately my computer didn't stuck. But it's unfortuantely
my patch causing so much trouble. I should've research commit
in linux-next more before applying it to mainline.

I found many WARNINGs in kernel log after Josh reported this bug.
I will try Damien's solution.

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >>       drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> >     drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing.  However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
> >>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
> >>> >>> still see the trace below.  If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod).  If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned.  It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> >>
> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now.  Will let you know as soon as I test it on both machines.
> 
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless.  I still see the backtrace below on both
> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> the NUC here:
> 
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> 
> Getting better at least :).

On top of what you currently have please also cherry-pick

commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Thu Feb 5 19:24:25 2015 +0000

    drm/i915: Fix atomic state when reusing the firmware fb

from -next. Let's hope this terminates eventually ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> Date:   Thu Feb 5 18:30:20 2015 +0000
>> >>
>> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>
>> >> From linux-next?
>> >
>> > Yes, building now.  Will let you know as soon as I test it on both machines.
>>
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless.  I still see the backtrace below on both
>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> the NUC here:
>>
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date:   Thu Feb 5 19:24:25 2015 +0000
>
>     drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)

Hm.  That one doesn't apply cleanly.  I think because it needs:

>From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu, 5 Feb 2015 17:22:18 +0000
Subject: drm/i915: Store the initial framebuffer in initial_plane_config

first.  Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?

josh

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> >> >>
> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >>
> >> >> From linux-next?
> >> >
> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
> >>
> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> NUC machine boots headless.  I still see the backtrace below on both
> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> >> the NUC here:
> >>
> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>
> >> Getting better at least :).
> >
> > On top of what you currently have please also cherry-pick
> >
> > commit fb9981aa675eb7b398849915364916fd98833cfa
> > Author: Damien Lespiau <damien.lespiau@intel.com>
> > Date:   Thu Feb 5 19:24:25 2015 +0000
> >
> >     drm/i915: Fix atomic state when reusing the firmware fb
> >
> > from -next. Let's hope this terminates eventually ;-)
> 
> Hm.  That one doesn't apply cleanly.  I think because it needs:
> 
> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> From: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu, 5 Feb 2015 17:22:18 +0000
> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> 
> first.  Do you want me to grab both, or should I try and figure out
> how to backport fb9981aa67 without it?

Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
-Daniel


diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 		return;
 
 	if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+		intel_crtc->base.primary->state->crtc = &intel_crtc->base;
 		update_state_fb(intel_crtc->base.primary);
 		return;
 	}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
 			drm_framebuffer_reference(c->primary->fb);
 			intel_crtc->base.primary->fb = c->primary->fb;
+			intel_crtc->base.primary->state->crtc = &intel_crtc->base;
 			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
 			break;
 		}
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date:   Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>>      drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>>  From linux-next?
>>>>> Yes, building now.  Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless.  I still see the backtrace below on both
>>>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> On top of what you currently have please also cherry-pick
>>>
>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> Date:   Thu Feb 5 19:24:25 2015 +0000
>>>
>>>      drm/i915: Fix atomic state when reusing the firmware fb
>>>
>>> from -next. Let's hope this terminates eventually ;-)
>> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>
>>  From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first.  Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>   		return;
>   
>   	if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> +		intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>   		update_state_fb(intel_crtc->base.primary);
>   		return;
>   	}
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>   
>   			drm_framebuffer_reference(c->primary->fb);
>   			intel_crtc->base.primary->fb = c->primary->fb;
> +			intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>   			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>   			break;
>   		}
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.

So, Daniel and Stephen please check it and end this mess...

It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
>
> On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
>> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>>> Date:   Thu Feb 5 18:30:20 2015 +0000
>>>>>>>
>>>>>>>      drm/i915: Don't try to reference the fb in 
>>>>>>> get_initial_plane_config()
>>>>>>>
>>>>>>>  From linux-next?
>>>>>> Yes, building now.  Will let you know as soon as I test it on 
>>>>>> both machines.
>>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>>> NUC machine boots headless.  I still see the backtrace below on both
>>>>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff 
>>>>> from
>>>>> the NUC here:
>>>>>
>>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>>
>>>>> Getting better at least :).
>>>> On top of what you currently have please also cherry-pick
>>>>
>>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>> Date:   Thu Feb 5 19:24:25 2015 +0000
>>>>
>>>>      drm/i915: Fix atomic state when reusing the firmware fb
>>>>
>>>> from -next. Let's hope this terminates eventually ;-)
>>> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>>
>>>  From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> From: Damien Lespiau <damien.lespiau@intel.com>
>>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> Subject: drm/i915: Store the initial framebuffer in 
>>> initial_plane_config
>>>
>>> first.  Do you want me to grab both, or should I try and figure out
>>> how to backport fb9981aa67 without it?
>> Oops missed that. The active ingredient is setting 
>> crtc->primary->state->crtc like this:
>> -Daniel
>>
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1c12262029fb..bfc14a6046ea 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc 
>> *intel_crtc,
>>           return;
>>         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> +        intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>           update_state_fb(intel_crtc->base.primary);
>>           return;
>>       }
>> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc 
>> *intel_crtc,
>>                 drm_framebuffer_reference(c->primary->fb);
>>               intel_crtc->base.primary->fb = c->primary->fb;
>> +            intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>               obj->frontbuffer_bits |= 
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>               break;
>>           }
> I found a bad thing. My buggy code also affects linux-next now because of
> the manual merge on 2014-03-16.
>
> So, Daniel and Stephen please check it and end this mess...
>
I reviewed linux-next. Stephen has dealed with it correctly.
> It's annoying to see my code caused so much trouble. I didn't test my 
> code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.
I am very upset because of my error now (>_<). I think the only thing I can
help now is view linux-next and find all commits about my 319c1d420a0b,
since my commit is a cheery-picking from linux-next.

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Jani Nikula]

On Wed, 25 Mar 2015, Xi Ruoyao <xry111@outlook.com> wrote:
> It's annoying to see my code caused so much trouble. I didn't test my code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.

Don't worry about it. It's our fail, not yours.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [git pull] drm fixes

[Takashi Iwai]

At Wed, 25 Mar 2015 15:00:08 +0100,
Daniel Vetter wrote:
> 
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> > On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> > >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> > >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> > >> >>
> > >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> > >> >>
> > >> >> From linux-next?
> > >> >
> > >> > Yes, building now.  Will let you know as soon as I test it on both machines.
> > >>
> > >> OK, with that commit applied I no longer get the kref.h splat and the
> > >> NUC machine boots headless.  I still see the backtrace below on both
> > >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> > >> the NUC here:
> > >>
> > >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> > >>
> > >> Getting better at least :).
> > >
> > > On top of what you currently have please also cherry-pick
> > >
> > > commit fb9981aa675eb7b398849915364916fd98833cfa
> > > Author: Damien Lespiau <damien.lespiau@intel.com>
> > > Date:   Thu Feb 5 19:24:25 2015 +0000
> > >
> > >     drm/i915: Fix atomic state when reusing the firmware fb
> > >
> > > from -next. Let's hope this terminates eventually ;-)
> > 
> > Hm.  That one doesn't apply cleanly.  I think because it needs:
> > 
> > From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> > From: Damien Lespiau <damien.lespiau@intel.com>
> > Date: Thu, 5 Feb 2015 17:22:18 +0000
> > Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> > 
> > first.  Do you want me to grab both, or should I try and figure out
> > how to backport fb9981aa67 without it?
> 
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:

As I wrote in another mail, I can confirm that cherry-picking of three
commits (and manual compile fixes) fixed the problem on my machine.


Takashi

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
>> >> >>
>> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >> >>
>> >> >> From linux-next?
>> >> >
>> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
>> >>
>> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> NUC machine boots headless.  I still see the backtrace below on both
>> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> >> the NUC here:
>> >>
>> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>
>> >> Getting better at least :).
>> >
>> > On top of what you currently have please also cherry-pick
>> >
>> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> > Date:   Thu Feb 5 19:24:25 2015 +0000
>> >
>> >     drm/i915: Fix atomic state when reusing the firmware fb
>> >
>> > from -next. Let's hope this terminates eventually ;-)
>>
>> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>
>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first.  Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
>
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>                 return;
>
>         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>                 update_state_fb(intel_crtc->base.primary);
>                 return;
>         }
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
>                         drm_framebuffer_reference(c->primary->fb);
>                         intel_crtc->base.primary->fb = c->primary->fb;
> +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>                         break;
>                 }

Hm.  So I used your patch above.  The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.

However, the NUC is back to not booting without HDMI plugged in.  I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:

https://jwboyer.fedorapeople.org/pub/vetters.txt

The frontbuffer splat is back now.

I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).

Not sure what to make of this one.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> >> >> >>
> >> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >> >>
> >> >> >> From linux-next?
> >> >> >
> >> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
> >> >>
> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> >> NUC machine boots headless.  I still see the backtrace below on both
> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> >> >> the NUC here:
> >> >>
> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >> >>
> >> >> Getting better at least :).
> >> >
> >> > On top of what you currently have please also cherry-pick
> >> >
> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >> > Date:   Thu Feb 5 19:24:25 2015 +0000
> >> >
> >> >     drm/i915: Fix atomic state when reusing the firmware fb
> >> >
> >> > from -next. Let's hope this terminates eventually ;-)
> >>
> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
> >>
> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>
> >> first.  Do you want me to grab both, or should I try and figure out
> >> how to backport fb9981aa67 without it?
> >
> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> > -Daniel
> >
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 1c12262029fb..bfc14a6046ea 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >                 return;
> >
> >         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> > +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >                 update_state_fb(intel_crtc->base.primary);
> >                 return;
> >         }
> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >
> >                         drm_framebuffer_reference(c->primary->fb);
> >                         intel_crtc->base.primary->fb = c->primary->fb;
> > +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> >                         break;
> >                 }
> 
> Hm.  So I used your patch above.  The macbook boots fine and all the
> oops/WARNS are gone except the audio one that was unrelated and
> present before all of this.
> 
> However, the NUC is back to not booting without HDMI plugged in.  I
> did the drm.debug=0xff+blacklist/insmod trick again and put the
> results up here:
> 
> https://jwboyer.fedorapeople.org/pub/vetters.txt
> 
> The frontbuffer splat is back now.
> 
> I confirmed multiple times that the NUC boots fine with the kernel
> that doesn't include the above patch but has the other two included
> (albeit with the drm_atomic WARN still).
> 
> Not sure what to make of this one.

Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.

Does that machine die the same way in drm-intel-nightly/linux-next?

I'll try to figure out meanwhile what's amiss here ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
>> >> >> >>
>> >> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >> >> >>
>> >> >> >> From linux-next?
>> >> >> >
>> >> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
>> >> >>
>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> >> NUC machine boots headless.  I still see the backtrace below on both
>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> >> >> the NUC here:
>> >> >>
>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >> >>
>> >> >> Getting better at least :).
>> >> >
>> >> > On top of what you currently have please also cherry-pick
>> >> >
>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> > Date:   Thu Feb 5 19:24:25 2015 +0000
>> >> >
>> >> >     drm/i915: Fix atomic state when reusing the firmware fb
>> >> >
>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>
>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>> >>
>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>
>> >> first.  Do you want me to grab both, or should I try and figure out
>> >> how to backport fb9981aa67 without it?
>> >
>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> > -Daniel
>> >
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> > index 1c12262029fb..bfc14a6046ea 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >                 return;
>> >
>> >         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> > +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >                 update_state_fb(intel_crtc->base.primary);
>> >                 return;
>> >         }
>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >
>> >                         drm_framebuffer_reference(c->primary->fb);
>> >                         intel_crtc->base.primary->fb = c->primary->fb;
>> > +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> >                         break;
>> >                 }
>>
>> Hm.  So I used your patch above.  The macbook boots fine and all the
>> oops/WARNS are gone except the audio one that was unrelated and
>> present before all of this.
>>
>> However, the NUC is back to not booting without HDMI plugged in.  I
>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> results up here:
>>
>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>
>> The frontbuffer splat is back now.
>>
>> I confirmed multiple times that the NUC boots fine with the kernel
>> that doesn't include the above patch but has the other two included
>> (albeit with the drm_atomic WARN still).
>>
>> Not sure what to make of this one.
>
> Yeah that fail looks like we're freeing an fb that's still in use.
> Hilarity happens and since that happens under console_lock at boot-up your
> machine dies.
>
> Does that machine die the same way in drm-intel-nightly/linux-next?

I'll try that a bit later today.  Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build.  The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more.  I'll let you know if that fixes
anything.  Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
>>> >> >> >>
>>> >> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>> >> >> >>
>>> >> >> >> From linux-next?
>>> >> >> >
>>> >> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
>>> >> >>
>>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>>> >> >> NUC machine boots headless.  I still see the backtrace below on both
>>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>>> >> >> the NUC here:
>>> >> >>
>>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>> >> >>
>>> >> >> Getting better at least :).
>>> >> >
>>> >> > On top of what you currently have please also cherry-pick
>>> >> >
>>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> > Date:   Thu Feb 5 19:24:25 2015 +0000
>>> >> >
>>> >> >     drm/i915: Fix atomic state when reusing the firmware fb
>>> >> >
>>> >> > from -next. Let's hope this terminates eventually ;-)
>>> >>
>>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>> >>
>>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>> >>
>>> >> first.  Do you want me to grab both, or should I try and figure out
>>> >> how to backport fb9981aa67 without it?
>>> >
>>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>>> > -Daniel
>>> >
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> > index 1c12262029fb..bfc14a6046ea 100644
>>> > --- a/drivers/gpu/drm/i915/intel_display.c
>>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> >                 return;
>>> >
>>> >         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>>> > +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> >                 update_state_fb(intel_crtc->base.primary);
>>> >                 return;
>>> >         }
>>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> >
>>> >                         drm_framebuffer_reference(c->primary->fb);
>>> >                         intel_crtc->base.primary->fb = c->primary->fb;
>>> > +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> >                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> >                         break;
>>> >                 }
>>>
>>> Hm.  So I used your patch above.  The macbook boots fine and all the
>>> oops/WARNS are gone except the audio one that was unrelated and
>>> present before all of this.
>>>
>>> However, the NUC is back to not booting without HDMI plugged in.  I
>>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>>> results up here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>>
>>> The frontbuffer splat is back now.
>>>
>>> I confirmed multiple times that the NUC boots fine with the kernel
>>> that doesn't include the above patch but has the other two included
>>> (albeit with the drm_atomic WARN still).
>>>
>>> Not sure what to make of this one.
>>
>> Yeah that fail looks like we're freeing an fb that's still in use.
>> Hilarity happens and since that happens under console_lock at boot-up your
>> machine dies.
>>
>> Does that machine die the same way in drm-intel-nightly/linux-next?
>
> I'll try that a bit later today.  Out of sheer curiosity, I folded
> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> update) into the patch above and kicked off a build.  The theory is
> that we're picking up a bunch of other changes right in that range of
> commits, why not try one more.  I'll let you know if that fixes
> anything.  Otherwise, I'll try building drm-intel-nightly and/or
> linux-next after that.

The drm-intel-nightly build finished first.  It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel.  Confused.  Full log here:

https://jwboyer.fedorapeople.org/pub/intel-nightly.txt

I don't have much hope for my other build.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
> >>> >> >> >>
> >>> >> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>> >> >> >>
> >>> >> >> >> From linux-next?
> >>> >> >> >
> >>> >> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
> >>> >> >>
> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >>> >> >> NUC machine boots headless.  I still see the backtrace below on both
> >>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
> >>> >> >> the NUC here:
> >>> >> >>
> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>> >> >>
> >>> >> >> Getting better at least :).
> >>> >> >
> >>> >> > On top of what you currently have please also cherry-pick
> >>> >> >
> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> > Date:   Thu Feb 5 19:24:25 2015 +0000
> >>> >> >
> >>> >> >     drm/i915: Fix atomic state when reusing the firmware fb
> >>> >> >
> >>> >> > from -next. Let's hope this terminates eventually ;-)
> >>> >>
> >>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
> >>> >>
> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>> >>
> >>> >> first.  Do you want me to grab both, or should I try and figure out
> >>> >> how to backport fb9981aa67 without it?
> >>> >
> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> >>> > -Daniel
> >>> >
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>> > index 1c12262029fb..bfc14a6046ea 100644
> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> >                 return;
> >>> >
> >>> >         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> >>> > +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> >                 update_state_fb(intel_crtc->base.primary);
> >>> >                 return;
> >>> >         }
> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> >
> >>> >                         drm_framebuffer_reference(c->primary->fb);
> >>> >                         intel_crtc->base.primary->fb = c->primary->fb;
> >>> > +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> >                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> >>> >                         break;
> >>> >                 }
> >>>
> >>> Hm.  So I used your patch above.  The macbook boots fine and all the
> >>> oops/WARNS are gone except the audio one that was unrelated and
> >>> present before all of this.
> >>>
> >>> However, the NUC is back to not booting without HDMI plugged in.  I
> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
> >>> results up here:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
> >>>
> >>> The frontbuffer splat is back now.
> >>>
> >>> I confirmed multiple times that the NUC boots fine with the kernel
> >>> that doesn't include the above patch but has the other two included
> >>> (albeit with the drm_atomic WARN still).
> >>>
> >>> Not sure what to make of this one.
> >>
> >> Yeah that fail looks like we're freeing an fb that's still in use.
> >> Hilarity happens and since that happens under console_lock at boot-up your
> >> machine dies.
> >>
> >> Does that machine die the same way in drm-intel-nightly/linux-next?
> >
> > I'll try that a bit later today.  Out of sheer curiosity, I folded
> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> > update) into the patch above and kicked off a build.  The theory is
> > that we're picking up a bunch of other changes right in that range of
> > commits, why not try one more.  I'll let you know if that fixes
> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
> > linux-next after that.
> 
> The drm-intel-nightly build finished first.  It boots without HDMI
> plugged in, but it has pretty much the same splats as the previous
> kernel.  Confused.  Full log here:
> 
> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
> 
> I don't have much hope for my other build.

Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
to primary->...

Thanks, Daniel

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
 		primary->fb = &plane_config->fb->base;
 		primary->state->crtc = &intel_crtc->base;
+		primary->crtc = &intel_crtc->base;
 		update_state_fb(primary);
 
 		return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 			drm_framebuffer_reference(c->primary->fb);
 			primary->fb = c->primary->fb;
 			primary->state->crtc = &intel_crtc->base;
+			primary->crtc = &intel_crtc->base;
 			update_state_fb(intel_crtc->base.primary);
 			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
 			break;
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +0000
>> >>> >> >> >>
>> >>> >> >> >>     drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>> >> >> >>
>> >>> >> >> >> From linux-next?
>> >>> >> >> >
>> >>> >> >> > Yes, building now.  Will let you know as soon as I test it on both machines.
>> >>> >> >>
>> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >>> >> >> NUC machine boots headless.  I still see the backtrace below on both
>> >>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> >>> >> >> the NUC here:
>> >>> >> >>
>> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>> >> >>
>> >>> >> >> Getting better at least :).
>> >>> >> >
>> >>> >> > On top of what you currently have please also cherry-pick
>> >>> >> >
>> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> > Date:   Thu Feb 5 19:24:25 2015 +0000
>> >>> >> >
>> >>> >> >     drm/i915: Fix atomic state when reusing the firmware fb
>> >>> >> >
>> >>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>> >>
>> >>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>> >>> >>
>> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>> >>
>> >>> >> first.  Do you want me to grab both, or should I try and figure out
>> >>> >> how to backport fb9981aa67 without it?
>> >>> >
>> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> >>> > -Daniel
>> >>> >
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> >>> > index 1c12262029fb..bfc14a6046ea 100644
>> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> >                 return;
>> >>> >
>> >>> >         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> >>> > +               intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> >                 update_state_fb(intel_crtc->base.primary);
>> >>> >                 return;
>> >>> >         }
>> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> >
>> >>> >                         drm_framebuffer_reference(c->primary->fb);
>> >>> >                         intel_crtc->base.primary->fb = c->primary->fb;
>> >>> > +                       intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> >                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> >>> >                         break;
>> >>> >                 }
>> >>>
>> >>> Hm.  So I used your patch above.  The macbook boots fine and all the
>> >>> oops/WARNS are gone except the audio one that was unrelated and
>> >>> present before all of this.
>> >>>
>> >>> However, the NUC is back to not booting without HDMI plugged in.  I
>> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> >>> results up here:
>> >>>
>> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>> >>>
>> >>> The frontbuffer splat is back now.
>> >>>
>> >>> I confirmed multiple times that the NUC boots fine with the kernel
>> >>> that doesn't include the above patch but has the other two included
>> >>> (albeit with the drm_atomic WARN still).
>> >>>
>> >>> Not sure what to make of this one.
>> >>
>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>> >> Hilarity happens and since that happens under console_lock at boot-up your
>> >> machine dies.
>> >>
>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>> >
>> > I'll try that a bit later today.  Out of sheer curiosity, I folded
>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>> > update) into the patch above and kicked off a build.  The theory is
>> > that we're picking up a bunch of other changes right in that range of
>> > commits, why not try one more.  I'll let you know if that fixes
>> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
>> > linux-next after that.
>>
>> The drm-intel-nightly build finished first.  It boots without HDMI
>> plugged in, but it has pretty much the same splats as the previous
>> kernel.  Confused.  Full log here:
>>
>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>
>> I don't have much hope for my other build.
>
> Yeah that's at least good news for the theory I've been cooking meanwhile.
> Can you try the below diff (on top of next/nightly)? For the current
> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
> to primary->...
>
> Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
>                 primary->fb = &plane_config->fb->base;
>                 primary->state->crtc = &intel_crtc->base;
> +               primary->crtc = &intel_crtc->base;
>                 update_state_fb(primary);
>
>                 return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>                         drm_framebuffer_reference(c->primary->fb);
>                         primary->fb = c->primary->fb;
>                         primary->state->crtc = &intel_crtc->base;
> +                       primary->crtc = &intel_crtc->base;
>                         update_state_fb(intel_crtc->base.primary);
>                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>                         break;

Hey, that seems to do the trick on the NUC machine.  Boots without
HDMI connected and there are no backtraces.  Nice!

Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then.  Will be a bit for it to build.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>>> >> Hilarity happens and since that happens under console_lock at boot-up your
>>> >> machine dies.
>>> >>
>>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>>> >
>>> > I'll try that a bit later today.  Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build.  The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more.  I'll let you know if that fixes
>>> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel.  Confused.  Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>>                 primary->fb = &plane_config->fb->base;
>>                 primary->state->crtc = &intel_crtc->base;
>> +               primary->crtc = &intel_crtc->base;
>>                 update_state_fb(primary);
>>
>>                 return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>                         drm_framebuffer_reference(c->primary->fb);
>>                         primary->fb = c->primary->fb;
>>                         primary->state->crtc = &intel_crtc->base;
>> +                       primary->crtc = &intel_crtc->base;
>>                         update_state_fb(intel_crtc->base.primary);
>>                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>                         break;
>
>Hey, that seems to do the trick on the NUC machine.  Boots without
>HDMI connected and there are no backtraces.  Nice!
>
>Let me go and munge it around for a backport on top of -rc5 with the
>rest of the pile and see if both the macbook and NUC machines work
>then.  Will be a bit for it to build.

OK, that helped on all my machines I have.  No backtraces and they all
boot again as I would expect.  For the record, here is what I have on
top of -rc5:

drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch

and this patch:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 		return;
 
 	if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+		intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+		intel_crtc->base.primary->crtc = &intel_crtc->base;
 		update_state_fb(intel_crtc->base.primary);
 		return;
 	}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
 			drm_framebuffer_reference(c->primary->fb);
 			intel_crtc->base.primary->fb = c->primary->fb;
+			intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+			intel_crtc->base.primary->crtc = &intel_crtc->base;
 			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
 			break;
 		}

which is a mash-up of:

"drm/i915: Fix atomic state when reusing the firmware fb"

and

"drm/i915: Fixup legacy plane->crtc link for initial fb config"

which you just sent out.

I think that covers everything.

josh

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

在 03/26/2015 03:40 AM, Josh Boyer 写道:
> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>> Yeah that fail looks like we're freeing an fb that's still in use.
>>>>>> Hilarity happens and since that happens under console_lock at boot-up your
>>>>>> machine dies.
>>>>>>
>>>>>> Does that machine die the same way in drm-intel-nightly/linux-next?
>>>>> I'll try that a bit later today.  Out of sheer curiosity, I folded
>>>>> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>>>> update) into the patch above and kicked off a build.  The theory is
>>>>> that we're picking up a bunch of other changes right in that range of
>>>>> commits, why not try one more.  I'll let you know if that fixes
>>>>> anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>>>> linux-next after that.
>>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>>> plugged in, but it has pretty much the same splats as the previous
>>>> kernel.  Confused.  Full log here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>>
>>>> I don't have much hope for my other build.
>>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>>> Can you try the below diff (on top of next/nightly)? For the current
>>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>>> to primary->...
>>>
>>> Thanks, Daniel
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index ceb2e61b4c91..cb508542c6ab 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>>
>>>                  primary->fb = &plane_config->fb->base;
>>>                  primary->state->crtc = &intel_crtc->base;
>>> +               primary->crtc = &intel_crtc->base;
>>>                  update_state_fb(primary);
>>>
>>>                  return;
>>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>>                          drm_framebuffer_reference(c->primary->fb);
>>>                          primary->fb = c->primary->fb;
>>>                          primary->state->crtc = &intel_crtc->base;
>>> +                       primary->crtc = &intel_crtc->base;
>>>                          update_state_fb(intel_crtc->base.primary);
>>>                          obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>>                          break;
>> Hey, that seems to do the trick on the NUC machine.  Boots without
>> HDMI connected and there are no backtraces.  Nice!
>>
>> Let me go and munge it around for a backport on top of -rc5 with the
>> rest of the pile and see if both the macbook and NUC machines work
>> then.  Will be a bit for it to build.
> OK, that helped on all my machines I have.  No backtraces and they all
> boot again as I would expect.  For the record, here is what I have on
> top of -rc5:
>
> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>
> and this patch:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 177714a9d778..778e7fa41c17 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>   		return;
>   
>   	if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> +		intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> +		intel_crtc->base.primary->crtc = &intel_crtc->base;
>   		update_state_fb(intel_crtc->base.primary);
>   		return;
>   	}
> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>   
>   			drm_framebuffer_reference(c->primary->fb);
>   			intel_crtc->base.primary->fb = c->primary->fb;
> +			intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> +			intel_crtc->base.primary->crtc = &intel_crtc->base;
>   			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>   			break;
>   		}
>
> which is a mash-up of:
>
> "drm/i915: Fix atomic state when reusing the firmware fb"
>
> and
>
> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>
> which you just sent out.
>
> I think that covers everything.
>
> josh
I've got an HDMI device from the laboratory. I'll help to test the solution.

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
>
>
> 在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
>> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>>> Yeah that fail looks like we're freeing an fb that's still in use.
>>>>>>> Hilarity happens and since that happens under console_lock at 
>>>>>>> boot-up your
>>>>>>> machine dies.
>>>>>>>
>>>>>>> Does that machine die the same way in drm-intel-nightly/linux-next?
>>>>>> I'll try that a bit later today.  Out of sheer curiosity, I folded
>>>>>> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>>>>> update) into the patch above and kicked off a build. The theory is
>>>>>> that we're picking up a bunch of other changes right in that 
>>>>>> range of
>>>>>> commits, why not try one more.  I'll let you know if that fixes
>>>>>> anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>>>>> linux-next after that.
>>>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>>>> plugged in, but it has pretty much the same splats as the previous
>>>>> kernel.  Confused.  Full log here:
>>>>>
>>>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>>>
>>>>> I don't have much hope for my other build.
>>>> Yeah that's at least good news for the theory I've been cooking 
>>>> meanwhile.
>>>> Can you try the below diff (on top of next/nightly)? For the current
>>>> cherry-pick pile on top of 4.0-rc you'd need to prepend 
>>>> intel_crtc->base.
>>>> to primary->...
>>>>
>>>> Thanks, Daniel
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>> index ceb2e61b4c91..cb508542c6ab 100644
>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc 
>>>> *intel_crtc,
>>>>
>>>>                  primary->fb = &plane_config->fb->base;
>>>>                  primary->state->crtc = &intel_crtc->base;
>>>> +               primary->crtc = &intel_crtc->base;
>>>>                  update_state_fb(primary);
>>>>
>>>>                  return;
>>>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc 
>>>> *intel_crtc,
>>>> drm_framebuffer_reference(c->primary->fb);
>>>>                          primary->fb = c->primary->fb;
>>>>                          primary->state->crtc = &intel_crtc->base;
>>>> +                       primary->crtc = &intel_crtc->base;
>>>> update_state_fb(intel_crtc->base.primary);
>>>>                          obj->frontbuffer_bits |= 
>>>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>>>                          break;
>>> Hey, that seems to do the trick on the NUC machine.  Boots without
>>> HDMI connected and there are no backtraces.  Nice!
>>>
>>> Let me go and munge it around for a backport on top of -rc5 with the
>>> rest of the pile and see if both the macbook and NUC machines work
>>> then.  Will be a bit for it to build.
>> OK, that helped on all my machines I have.  No backtraces and they all
>> boot again as I would expect.  For the record, here is what I have on
>> top of -rc5:
>>
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 177714a9d778..778e7fa41c17 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc 
>> *intel_crtc,
>>           return;
>>         if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> +        intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> +        intel_crtc->base.primary->crtc = &intel_crtc->base;
>>           update_state_fb(intel_crtc->base.primary);
>>           return;
>>       }
>> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc 
>> *intel_crtc,
>>                 drm_framebuffer_reference(c->primary->fb);
>>               intel_crtc->base.primary->fb = c->primary->fb;
>> +            intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> +            intel_crtc->base.primary->crtc = &intel_crtc->base;
>>               obj->frontbuffer_bits |= 
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>               break;
>>           }
>>
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the 
> solution.
>
At least, my machine boots well and there is no WARNINGs
in kernel log. I will do more tests.

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Xi Ruoyao]

On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has been managled by Thunderbird.
(BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?)
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the 
> solution.
>
I confirm that after applying those 3 patches, my machine boots fine mutiple
times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about
drm/i915 in kernel log. So I think these patches have successfully 
solved the
problem, although maybe I am the one who makes some mistakes again......

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China

Re: [Intel-gfx] [git pull] drm fixes

[Jani Nikula]

On Wed, 25 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless.  I still see the backtrace below on both
>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> the NUC here:
>> 
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> 
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date:   Thu Feb 5 19:24:25 2015 +0000
>
>     drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)

For posterity, I've picked this up for drm-intel-fixes. Thanks for all
the testing.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [git pull] drm fixes

[Jani Nikula]

On Wed, 25 Mar 2015, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>>> > I'll try that a bit later today.  Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build.  The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more.  I'll let you know if that fixes
>>> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel.  Confused.  Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>>                 primary->fb = &plane_config->fb->base;
>>                 primary->state->crtc = &intel_crtc->base;
>> +               primary->crtc = &intel_crtc->base;
>>                 update_state_fb(primary);
>>
>>                 return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>                         drm_framebuffer_reference(c->primary->fb);
>>                         primary->fb = c->primary->fb;
>>                         primary->state->crtc = &intel_crtc->base;
>> +                       primary->crtc = &intel_crtc->base;
>>                         update_state_fb(intel_crtc->base.primary);
>>                         obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>                         break;
>
> Hey, that seems to do the trick on the NUC machine.  Boots without
> HDMI connected and there are no backtraces.  Nice!

I've picked this [1] up for drm-intel-fixes as well. Thanks for the
testing.

BR,
Jani.


[1] http://mid.gmane.org/1427304638-7897-1-git-send-email-daniel.vetter@ffwll.ch



-- 
Jani Nikula, Intel Open Source Technology Center