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 =). Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel