* [git pull] drm fixes
@ 2015-02-27 4:42 ` Dave Airlie
0 siblings, 0 replies; 31+ messages in thread
From: Dave Airlie @ 2015-02-27 4:42 UTC (permalink / raw)
To: torvalds; +Cc: DRI mailing list, linux-kernel
[-- 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(-)
^ permalink raw reply [flat|nested] 31+ messages in thread* [git pull] drm fixes @ 2015-02-27 4:42 ` Dave Airlie 0 siblings, 0 replies; 31+ messages in thread From: Dave Airlie @ 2015-02-27 4:42 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel, DRI mailing list [-- Attachment #1: Type: TEXT/PLAIN, Size: 5161 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(-) [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-02-27 4:42 ` Dave Airlie @ 2015-03-01 5:40 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 5:40 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-01 5:40 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 5:40 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 5:40 ` Linus Torvalds @ 2015-03-01 6:08 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 6:08 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-01 6:08 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 6:08 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 6:08 ` Linus Torvalds @ 2015-03-01 7:27 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 7:27 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-01 7:27 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 7:27 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 7:27 ` Linus Torvalds @ 2015-03-01 20:35 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 20:35 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-01 20:35 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 20:35 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 20:35 ` Linus Torvalds @ 2015-03-01 21:00 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 21:00 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-01 21:00 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-01 21:00 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 21:00 ` Linus Torvalds (?) @ 2015-03-02 1:59 ` Linus Torvalds 2015-03-02 9:04 ` Daniel Vetter -1 siblings, 1 reply; 31+ messages in thread From: Linus Torvalds @ 2015-03-02 1:59 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper, Ander Conselvan de Oliveira Cc: DRI mailing list, Linux Kernel Mailing List, intel-gfx [-- 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 .. ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-02 1:59 ` Linus Torvalds @ 2015-03-02 9:04 ` Daniel Vetter 0 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 9:04 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper, Ander Conselvan de Oliveira, intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-02 9:04 ` Daniel Vetter 0 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 9:04 UTC (permalink / raw) To: Linus Torvalds Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-02 9:04 ` Daniel Vetter @ 2015-03-02 16:53 ` Linus Torvalds -1 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-02 16:53 UTC (permalink / raw) To: Linus Torvalds, Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper, Ander Conselvan de Oliveira, intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-02 16:53 ` Linus Torvalds 0 siblings, 0 replies; 31+ messages in thread From: Linus Torvalds @ 2015-03-02 16:53 UTC (permalink / raw) To: Linus Torvalds, Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper, Ander Conselvan de Oliveira, intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes 2015-03-02 16:53 ` Linus Torvalds @ 2015-03-02 17:23 ` Daniel Vetter -1 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 17:23 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper, Ander Conselvan de Oliveira, intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes @ 2015-03-02 17:23 ` Daniel Vetter 0 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 17:23 UTC (permalink / raw) To: Linus Torvalds Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-01 6:08 ` Linus Torvalds @ 2015-03-02 9:44 ` Paul Bolle -1 siblings, 0 replies; 31+ messages in thread From: Paul Bolle @ 2015-03-02 9:44 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Jani Nikula, DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-02 9:44 ` Paul Bolle 0 siblings, 0 replies; 31+ messages in thread From: Paul Bolle @ 2015-03-02 9:44 UTC (permalink / raw) To: Linus Torvalds Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list, Daniel Vetter 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes 2015-03-02 9:44 ` Paul Bolle @ 2015-03-02 10:26 ` Jani Nikula -1 siblings, 0 replies; 31+ messages in thread From: Jani Nikula @ 2015-03-02 10:26 UTC (permalink / raw) To: Paul Bolle, Linus Torvalds Cc: Dave Airlie, Daniel Vetter, DRI mailing list, Linux Kernel Mailing List, intel-gfx 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-02 10:26 ` Jani Nikula 0 siblings, 0 replies; 31+ messages in thread From: Jani Nikula @ 2015-03-02 10:26 UTC (permalink / raw) To: Paul Bolle, Linus Torvalds Cc: Dave Airlie, Daniel Vetter, intel-gfx, Linux Kernel Mailing List, DRI mailing list 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes 2015-03-02 9:44 ` Paul Bolle @ 2015-03-02 10:33 ` Daniel Vetter -1 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 10:33 UTC (permalink / raw) To: Paul Bolle Cc: Linus Torvalds, Dave Airlie, intel-gfx, Linux Kernel Mailing List, DRI mailing list, 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [git pull] drm fixes @ 2015-03-02 10:33 ` Daniel Vetter 0 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-02 10:33 UTC (permalink / raw) To: Paul Bolle Cc: Dave Airlie, intel-gfx, Linux Kernel Mailing List, DRI mailing list, Daniel Vetter, Linus Torvalds 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-02 9:44 ` Paul Bolle ` (2 preceding siblings ...) (?) @ 2015-03-03 16:31 ` Daniel Vetter 2015-03-03 17:03 ` Linus Torvalds 2015-03-04 12:41 ` shuang.he -1 siblings, 2 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-03 16:31 UTC (permalink / raw) To: Intel Graphics Development Cc: Paul Bolle, Daniel Vetter, DRI Development, Daniel Vetter, Linus Torvalds This is a tricky story of the new atomic state handling and the legacy code fighting over each another. The bug at hand is an underrun of the framebuffer reference with subsequent hilarity caused by the load detect code. Which is peculiar since the the exact same code works fine as the implementation of the legacy setcrtc ioctl. Let's look at the ingredients: - Currently our code is a crazy mix of legacy modeset interfaces to set the parameters and half-baked atomic state tracking underneath. While this transition is going we're using the transitional plane helpers to update the atomic side (drm_plane_helper_disable/update and friends), i.e. plane->state->fb. Since the state structure owns the fb those functions take care of that themselves. The legacy state (specifically crtc->primary->fb) is still managed by the old code (and mostly by the drm core), with the fb reference counting done by callers (core drm for the ioctl or the i915 load detect code). The relevant commit is commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) - drm_plane_helper_disable has special code to handle multiple calls in a row - it checks plane->crtc == NULL and bails out. This is to match the proper atomic implementation which needs the crtc to get at the implied locking context atomic updates always need. See commit acf24a395c5a9290189b080383564437101d411c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 29 15:33:05 2014 +0200 drm/plane-helper: transitional atomic plane helpers - The universal plane code split out the implicit primary plane from the CRTC into it's own full-blown drm_plane object. As part of that the setcrtc ioctl (which updated both the crtc mode and primary plane) learned to set crtc->primary->crtc on modeset to make sure the plane->crtc assignments statate up to date in commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Apr 1 15:22:38 2014 -0700 drm: Add drm_crtc_init_with_planes() (v2) Unfortunately we've forgotten to update the load detect code. Which wasn't a problem since the load detect modeset is temporary and always undone before we drop the locks. - Finally there is a organically grown history (i.e. don't ask) around who sets the legacy plane->fb for the various driver entry points. Originally updating that was the drivers duty, but for almost all places we've moved that (plus updating the refcounts) into the core. Again the exception is the load detect code. Taking all together the following happens: - The load detect code doesn't set crtc->primary->crtc. This is only really an issue on crtcs never before used or when userspace explicitly disabled the primary plane. - The plane helper glue code short-circuits because of that and leaves a non-NULL fb behind in plane->state->fb and plane->fb. The state fb isn't a real problem (it's properly refcounted on its own), it's just the canary. - Load detect code drops the reference for that fb, but doesn't set plane->fb = NULL. This is ok since it's still living in that old world where drivers had to clear the pointer but the core/callers handled the refcounting. - On the next modeset the drm core notices plane->fb and takes care of refcounting it properly by doing another unref. This drops the refcount to zero, leaving state->plane now pointing at freed memory. - intel_plane_duplicate_state still assume it owns a reference to that very state->fb and bad things start to happen. Fix this all by applying the same duct-tape as for the legacy setcrtc ioctl code and set crtc->primary->crtc properly. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Rob Clark <robdclark@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index cc3305e30c1b..d116caf98a72 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8859,6 +8859,7 @@ retry: old->release_fb->funcs->destroy(old->release_fb); goto fail; } + crtc->primary->crtc = crtc; /* let the connector get through one full cycle before testing */ intel_wait_for_vblank(dev, intel_crtc->pipe); -- 2.1.4 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-03 16:31 ` [PATCH] drm/i915: Fix modeset state confusion in the load detect code Daniel Vetter @ 2015-03-03 17:03 ` Linus Torvalds 2015-03-03 17:11 ` Daniel Vetter 2015-03-04 12:41 ` shuang.he 1 sibling, 1 reply; 31+ messages in thread From: Linus Torvalds @ 2015-03-03 17:03 UTC (permalink / raw) To: Daniel Vetter Cc: Paul Bolle, Intel Graphics Development, DRI Development, Daniel Vetter On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > Fix this all by applying the same duct-tape as for the legacy setcrtc > ioctl code and set crtc->primary->crtc properly. Ack. Tests fine on the machine that showed issues for me. I'll apply it manually directly to my tree, since I want to release rc2 and I was holding that up in the hope this would get released (I hate releasing even early rc's with issues that I know about and that break machines I have access to). If it ends up in your tree too and I'll get a duplicate commit later, git will sort it all out, so it's fine. Thanks, Linus _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-03 17:03 ` Linus Torvalds @ 2015-03-03 17:11 ` Daniel Vetter 2015-03-03 17:12 ` Linus Torvalds 0 siblings, 1 reply; 31+ messages in thread From: Daniel Vetter @ 2015-03-03 17:11 UTC (permalink / raw) To: Linus Torvalds Cc: Paul Bolle, Daniel Vetter, Intel Graphics Development, DRI Development, Daniel Vetter On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote: > On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > Fix this all by applying the same duct-tape as for the legacy setcrtc > > ioctl code and set crtc->primary->crtc properly. > > Ack. Tests fine on the machine that showed issues for me. > > I'll apply it manually directly to my tree, since I want to release > rc2 and I was holding that up in the hope this would get released (I > hate releasing even early rc's with issues that I know about and that > break machines I have access to). Fine with me. If you haven't pushed out yet can you maybe clarify the commit message? The setcrtc step must be one that disables the crtc, only then will we (again) skip the book-keeping for plane->state->fb and unref to 0 in the drm core. If you directly switch to another fb/mode then we'll unref to 0 in the state duplicate and then blow up in the drm core when doing the unref for plane->old_fb. But since X generally disable everything before enabling the new config the previuos one is how we more likely blow up, and hence also why duplicate_state blows up. > If it ends up in your tree too and I'll get a duplicate commit later, > git will sort it all out, so it's fine. The revert and another patch to make the load detect code testable in an automated fashion on modern platfroms to avoid another occurence of this mess are fully independent of this one line. So no conflicts to be expected. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-03 17:11 ` Daniel Vetter @ 2015-03-03 17:12 ` Linus Torvalds 2015-03-03 17:19 ` Daniel Vetter 0 siblings, 1 reply; 31+ messages in thread From: Linus Torvalds @ 2015-03-03 17:12 UTC (permalink / raw) To: Daniel Vetter Cc: Paul Bolle, Daniel Vetter, Intel Graphics Development, DRI Development, Daniel Vetter On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > > Fine with me. If you haven't pushed out yet can you maybe clarify the > commit message? Oh well. I already applied and tagged it, so it's what it is.. Linus _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-03 17:12 ` Linus Torvalds @ 2015-03-03 17:19 ` Daniel Vetter 0 siblings, 0 replies; 31+ messages in thread From: Daniel Vetter @ 2015-03-03 17:19 UTC (permalink / raw) To: Linus Torvalds Cc: Paul Bolle, Daniel Vetter, Intel Graphics Development, DRI Development, Daniel Vetter On Tue, Mar 03, 2015 at 09:12:47AM -0800, Linus Torvalds wrote: > On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > Fine with me. If you haven't pushed out yet can you maybe clarify the > > commit message? > > Oh well. I already applied and tagged it, so it's what it is.. No biggie, the explanation is correct and just glosses a bit over that detail. In case someone hit this the other way round and fell all over plane->fb being freed instead of state->fb. But really unlikely - these old machines don't tend to run fancy non-X compositors ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] drm/i915: Fix modeset state confusion in the load detect code 2015-03-03 16:31 ` [PATCH] drm/i915: Fix modeset state confusion in the load detect code Daniel Vetter 2015-03-03 17:03 ` Linus Torvalds @ 2015-03-04 12:41 ` shuang.he 1 sibling, 0 replies; 31+ messages in thread From: shuang.he @ 2015-03-04 12:41 UTC (permalink / raw) To: shuang.he, ethan.gao, intel-gfx, daniel.vetter Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Task id: 5879 -------------------------------------Summary------------------------------------- Platform Delta drm-intel-nightly Series Applied PNV -6 278/278 272/278 ILK 308/308 308/308 SNB -1 284/284 283/284 IVB -1 380/380 379/380 BYT 294/294 294/294 HSW 387/387 387/387 BDW -1 316/316 315/316 -------------------------------------Detailed------------------------------------- Platform Test drm-intel-nightly Series Applied PNV igt_gem_userptr_blits_coherency-sync NO_RESULT(1)CRASH(8)NRUN(1)PASS(8) CRASH(1)NRUN(1) PNV igt_gem_userptr_blits_coherency-unsync FAIL(1)NO_RESULT(1)CRASH(6)PASS(7) CRASH(1)PASS(1) PNV igt_gem_userptr_blits_minor-unsync-interruptible DMESG_WARN(1)PASS(5) DMESG_WARN(1)PASS(1) PNV igt_gen3_render_linear_blits FAIL(6)NRUN(1)DMESG_WARN(1)PASS(9) FAIL(2) PNV igt_gen3_render_mixed_blits FAIL(9)PASS(9) FAIL(2) PNV igt_gem_fence_thrash_bo-write-verify-threaded-none FAIL(2)CRASH(4)PASS(7) CRASH(2) *SNB igt_gem_fence_thrash_bo-write-verify-y PASS(5) DMESG_WARN(1)PASS(1) *IVB igt_gem_storedw_batches_loop_secure-dispatch PASS(3) DMESG_WARN(1)PASS(1) *BDW igt_gem_gtt_hog PASS(19) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2015-03-04 12:41 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-27 4:42 [git pull] drm fixes Dave Airlie 2015-02-27 4:42 ` Dave Airlie 2015-03-01 5:40 ` Linus Torvalds 2015-03-01 5:40 ` Linus Torvalds 2015-03-01 6:08 ` Linus Torvalds 2015-03-01 6:08 ` Linus Torvalds 2015-03-01 7:27 ` Linus Torvalds 2015-03-01 7:27 ` Linus Torvalds 2015-03-01 20:35 ` Linus Torvalds 2015-03-01 20:35 ` Linus Torvalds 2015-03-01 21:00 ` Linus Torvalds 2015-03-01 21:00 ` Linus Torvalds 2015-03-02 1:59 ` Linus Torvalds 2015-03-02 9:04 ` Daniel Vetter 2015-03-02 9:04 ` Daniel Vetter 2015-03-02 16:53 ` Linus Torvalds 2015-03-02 16:53 ` Linus Torvalds 2015-03-02 17:23 ` [Intel-gfx] " Daniel Vetter 2015-03-02 17:23 ` Daniel Vetter 2015-03-02 9:44 ` Paul Bolle 2015-03-02 9:44 ` Paul Bolle 2015-03-02 10:26 ` Jani Nikula 2015-03-02 10:26 ` Jani Nikula 2015-03-02 10:33 ` [Intel-gfx] " Daniel Vetter 2015-03-02 10:33 ` Daniel Vetter 2015-03-03 16:31 ` [PATCH] drm/i915: Fix modeset state confusion in the load detect code Daniel Vetter 2015-03-03 17:03 ` Linus Torvalds 2015-03-03 17:11 ` Daniel Vetter 2015-03-03 17:12 ` Linus Torvalds 2015-03-03 17:19 ` Daniel Vetter 2015-03-04 12:41 ` shuang.he
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.