drm/fbdev-helper: Explain how to debug console_lock fun
diff mbox

Message ID 1453449225-10954-1-git-send-email-daniel.vetter@ffwll.ch
State New
Headers show

Commit Message

Daniel Vetter Jan. 22, 2016, 7:53 a.m. UTC
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(+)

Comments

Carlos Palminha Jan. 22, 2016, 11:50 a.m. UTC | #1
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... :(

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 Jan. 22, 2016, 4:45 p.m. UTC | #2
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.
> >   */
> >
Laurent Pinchart Jan. 24, 2016, 8:33 p.m. UTC | #3
Hi Daniel,

Thank you for the patch.

On Friday 22 January 2016 08:53:45 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

No need to start the sentence with "And", s/And due/Due/ will do.

> 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

Same here.

> will
> + * be sent out to consoles, not even serial console. Which means when your

Similarly, s/Which means when/This means that if/

> + * 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

s/And any/Any/

Apart from that,

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Very useful addition to the documentation, I got bitten by this more than 
once. I wonder whether we could make this information even easier to find.

> 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 Jan. 25, 2016, 7:34 a.m. UTC | #4
On Sun, Jan 24, 2016 at 10:33:57PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> Thank you for the patch.
> 
> On Friday 22 January 2016 08:53:45 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
> 
> No need to start the sentence with "And", s/And due/Due/ will do.
> 
> > 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
> 
> Same here.
> 
> > will
> > + * be sent out to consoles, not even serial console. Which means when your
> 
> Similarly, s/Which means when/This means that if/
> 
> > + * 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
> 
> s/And any/Any/
> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks for the review, added your changes and merged the patch.

> Very useful addition to the documentation, I got bitten by this more than 
> once. I wonder whether we could make this information even easier to find.

I figured most likely when debugging hangs you will notice eventually that
the hang is in this function and then stumble over the kerneldoc.
Everywhere else it will probably get ignored. That's why I placed it here.
-Daniel

Patch
diff mbox

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.
  */