On 25/08/15 22:24, Rob Clark wrote:
On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter daniel.vetter@ffwll.ch 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@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
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?
Tomi