* [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun
@ 2016-01-22 7:53 Daniel Vetter
2016-01-22 9:42 ` ✗ Fi.CI.BAT: warning for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Daniel Vetter @ 2016-01-22 7:53 UTC (permalink / raw)
To: Intel Graphics Development
Cc: Xinliang Liu, Daniel Vetter, Carlos Palminha, DRI Development,
laurent.pinchart, Daniel Vetter
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.
*/
--
2.7.0.rc3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread* ✗ Fi.CI.BAT: warning for drm/fbdev-helper: Explain how to debug console_lock fun
2016-01-22 7:53 [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun Daniel Vetter
@ 2016-01-22 9:42 ` Patchwork
2016-01-22 11:50 ` [PATCH] " Carlos Palminha
2016-01-24 20:33 ` Laurent Pinchart
2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2016-01-22 9:42 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Summary ==
Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p)
bdw-nuci7 total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9
bdw-ultra total:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6
bsw-nuc-2 total:143 pass:119 dwarn:0 dfail:0 fail:0 skip:24
byt-nuc total:143 pass:128 dwarn:0 dfail:0 fail:0 skip:15
hsw-brixbox total:143 pass:136 dwarn:0 dfail:0 fail:0 skip:7
ilk-hp8440p total:143 pass:103 dwarn:2 dfail:0 fail:0 skip:38
ivb-t430s total:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6
skl-i5k-2 total:143 pass:134 dwarn:1 dfail:0 fail:0 skip:8
skl-i7k-2 total:143 pass:134 dwarn:1 dfail:0 fail:0 skip:8
snb-dellxps total:143 pass:129 dwarn:0 dfail:0 fail:0 skip:14
snb-x220t total:143 pass:129 dwarn:0 dfail:0 fail:1 skip:13
Results at /archive/results/CI_IGT_test/Patchwork_1245/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun
2016-01-22 7:53 [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun Daniel Vetter
2016-01-22 9:42 ` ✗ Fi.CI.BAT: warning for " Patchwork
@ 2016-01-22 11:50 ` Carlos Palminha
2016-01-22 16:45 ` Daniel Vetter
2016-01-24 20:33 ` Laurent Pinchart
2 siblings, 1 reply; 6+ messages in thread
From: Carlos Palminha @ 2016-01-22 11:50 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics Development
Cc: Daniel Vetter, Carlos Palminha, DRI Development, laurent.pinchart
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.
> */
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun
2016-01-22 11:50 ` [PATCH] " Carlos Palminha
@ 2016-01-22 16:45 ` Daniel Vetter
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2016-01-22 16:45 UTC (permalink / raw)
To: Carlos Palminha
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
laurent.pinchart, Daniel Vetter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun
2016-01-22 7:53 [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun Daniel Vetter
2016-01-22 9:42 ` ✗ Fi.CI.BAT: warning for " Patchwork
2016-01-22 11:50 ` [PATCH] " Carlos Palminha
@ 2016-01-24 20:33 ` Laurent Pinchart
2016-01-25 7:34 ` Daniel Vetter
2 siblings, 1 reply; 6+ messages in thread
From: Laurent Pinchart @ 2016-01-24 20:33 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Carlos Palminha,
DRI Development
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.
> */
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun
2016-01-24 20:33 ` Laurent Pinchart
@ 2016-01-25 7:34 ` Daniel Vetter
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2016-01-25 7:34 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Daniel Vetter, Intel Graphics Development, Carlos Palminha,
DRI Development, Daniel Vetter
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
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-25 7:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-22 7:53 [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun Daniel Vetter
2016-01-22 9:42 ` ✗ Fi.CI.BAT: warning for " Patchwork
2016-01-22 11:50 ` [PATCH] " Carlos Palminha
2016-01-22 16:45 ` Daniel Vetter
2016-01-24 20:33 ` Laurent Pinchart
2016-01-25 7:34 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox