From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751081AbbCAFke (ORCPT ); Sun, 1 Mar 2015 00:40:34 -0500 Received: from mail-ie0-f178.google.com ([209.85.223.178]:42867 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750833AbbCAFkc (ORCPT ); Sun, 1 Mar 2015 00:40:32 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 28 Feb 2015 21:40:31 -0800 X-Google-Sender-Auth: w8rhi4rcMFjypRIXJrX5aSuRJsk Message-ID: Subject: Re: [git pull] drm fixes From: Linus Torvalds To: Dave Airlie , Daniel Vetter , Jani Nikula Cc: DRI mailing list , Linux Kernel Mailing List , intel-gfx Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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