On Fri, Jan 22, 2016 at 11:50:06AM +0000, Carlos Palminha wrote: > Hi Daniel, > > Thanks for the tip. > I just enabled fb.lockless_register_fb=1 and still cannot see any debug > messages after the console_lock... :( If this works there shouldn't be any console_lock call from initial_config(). console_lock _always_ stops console output until the next console_unlock happens. Can you perhaps make a backtrace of where that console_lock happens? Maybe the patch broke meanwhile and there's another important callsite I missed. Also note that the lockless_register_fb patch only just landed this merge window, you need Linus' latest tree (or 4.5-rc1 once it's out there). Other option is to disable fbdev emulation like I describe below. -Daniel > > Regards, > C.Palminha > > On 22-01-2016 07:53, Daniel Vetter wrote: > >Every new KMS driver writer seems to run into this and wonder how > >exactly drm_fb_helper_initial_config can die doing nothing at all. > >Set up some big warnings signs around this newbie trap to avoid future > >frustration and wasting everyone's time. > > > >Cc: Carlos Palminha <CARLOS.PALMINHA@xxxxxxxxxxxx> > >Cc: Xinliang Liu <xinliang.liu@xxxxxxxxxx> > >Cc: laurent.pinchart@xxxxxxxxxxxxxxxx > >Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > >--- > > drivers/gpu/drm/drm_fb_helper.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > >diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > >index 1e103c4c6ee0..9bf84b227613 100644 > >--- a/drivers/gpu/drm/drm_fb_helper.c > >+++ b/drivers/gpu/drm/drm_fb_helper.c > >@@ -2091,6 +2091,28 @@ out: > > * drm_fb_helper_fill_fix() are provided as helpers to setup simple default > > * values for the fbdev info structure. > > * > >+ * HANG DEBUGGING: > >+ * > >+ * When you have fbcon support built-in or already loaded, this function will do > >+ * a full modeset to setup the fbdev console. And due to locking misdesign in > >+ * the VT/fbdev subsystem that entire modeset sequence has to be done while > >+ * holding console_lock. And until console_unlock is called no dmesg lines will > >+ * be sent out to consoles, not even serial console. Which means when your > >+ * driver crashes, you will see absolutely nothing else but a system stuck in > >+ * this function, with no further output. And any kind of printk() you place > >+ * within your own driver or in the drm core modeset code will also never show > >+ * up. > >+ * > >+ * Standard debug practice is to run the fbcon setup without taking the > >+ * console_lock as a hack, to be able to see backtraces and crashes on the > >+ * serial line. This can be done by setting the fb.lockless_register_fb=1 kernel > >+ * cmdline option. > >+ * > >+ * The other option is to just disable fbdev emulation since very likely the > >+ * first modest from userspace will crash in the same way, and is even easier to > >+ * debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0 > >+ * kernel cmdline option. > >+ * > > * RETURNS: > > * Zero if everything went ok, nonzero otherwise. > > */ > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
