Re: [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun

[Daniel Vetter <daniel@ffwll.ch>]

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@synopsys.com>
> >Cc: Xinliang Liu <xinliang.liu@linaro.org>
> >Cc: laurent.pinchart@ideasonboard.com
> >Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >---
> >  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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel