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. */
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.
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.
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.
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
dri-devel@lists.freedesktop.org
-
Carlos Palminha -
Daniel Vetter -
Daniel Vetter -
Laurent Pinchart