On Tue, Sep 01, 2015 at 11:12:11AM -0400, Rob Clark wrote: > On Tue, Sep 1, 2015 at 10:41 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > > > > > On 01/09/15 17:34, Rob Clark wrote: > >> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > >>> > >>> > >>> On 25/08/15 22:24, Rob Clark wrote: > >>>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > >>>>> When the usual fbcon legacy options are enabled we have > >>>>> ->register_framebuffer > >>>>> ->fb notifier chain calls into fbcon > >>>>> ->fbcon sets up console on new fbi > >>>>> ->fbi->set_par > >>>>> ->drm_fb_helper_set_par exercises full kms api > >>>>> > >>>>> And because of locking inversion hilarity all of register_framebuffer > >>>>> is done with the console lock held. Which means that the first time on > >>>>> driver load we exercise _all_ the kms code (all probe paths and > >>>>> modeset paths for everything connected) is under the console lock. > >>>>> That means if anything goes belly-up in that big pile of code nothing > >>>>> ever reaches logfiles (and the machine is dead). > >>>>> > >>>>> Usual tactic to debug that is to temporarily remove those console_lock > >>>>> calls to be able to capture backtraces. I'm fed up writing this patch > >>>>> and recompiling kernels. Hence this patch here to add an unsafe, > >>>>> kernel-taining option to do this at runtime. > >>>>> > >>>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@xxxxxxxxxxxx> > >>>>> Cc: Tomi Valkeinen <tomi.valkeinen@xxxxxx> > >>>>> Cc: linux-fbdev@xxxxxxxxxxxxxxx > >>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > >>>> > >>>> This one was causing me some problems, if I tried to enable > >>>> lockless_register_fb. It *looks* like it should work, so I'm not > >>>> quite sure what the deal is. But I'm 110% fan of getting something > >>>> like this working, because console_lock is pretty much the bane of kms > >>>> developer's existence.. > >>>> > >>>> I'll have to debug further on a system where I can see more than the > >>>> bottom three lines of the second to last backtrace.. > >>> > >>> Any idea if anyone has ever looked at properly fixing this? > >> > >> I hadn't had a chance to look at it further yet.. I think Daniel > >> claimed it worked for him, but he was probably on intel-next, where I > >> was on drm-next at the time which seemed to be having some unrelated > >> i915 issues (when I was trying to debug atomic fb-helper patches). So > >> can't really say that the issue I had was actually related to this > >> patch. I'll try again later this week or next, when hopefully i915 in > >> drm-next is in better shape.. > > > > Oh, I didn't mean this patch, but the whole console lock in general. > > I've also banged my head to a wall because of it =). > > oh, not sure.. every time I've started looking closer at > console/console_lock I run away screaming.. I guess if it were > possible to push the lock down further so only drivers that needed the > lock (presumably serial/net/etc) could take it, that would be nice.. > but not sure I am that brave.. console_lock is pretty much unfixable without rewriting half of fbdev. Which I don't expect to ever happen. For the curious look at all the commits changing locking in fbdev over the past few years. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
