| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 24 Mar 2015 17:49:38 +0100 From: Daniel Vetter <daniel@...ll.ch> To: Josh Boyer <jwboyer@...oraproject.org>, Dave Airlie <airlied@...ux.ie>, Xi Ruoyao <xry111@...look.com>, Linus Torvalds <torvalds@...ux-foundation.org>, "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>, DRI mailing list <dri-devel@...ts.freedesktop.org>, Intel Graphics Development <intel-gfx@...ts.freedesktop.org> Cc: Jani Nikula <jani.nikula@...ux.intel.com> Subject: Re: [Intel-gfx] [git pull] drm fixes 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@...oraproject.org> wrote: > > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@...ll.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@...oraproject.org> wrote: > > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@...ll.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@...ll.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@...oraproject.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@...ll.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@...el.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists