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.. BR, -R > Tomi > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
