Re: [git pull] drm fixes

From: Linus Torvalds
Date: Sun Mar 01 2015 - 00:40:54 EST


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