[PATCH] drm: avoid switching to text console if there is no panic timeout

[Mandeep Singh Baines]

Dave Young (hidave.darkstar at gmail.com) wrote:
> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young <hidave.darkstar at gmail.com> wrote:
> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines <msb at chromium.org> wrote:
> >> From: Hugh Dickins <hughd at chromium.org>
> >>
> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> >> we're going to reboot immediately, the user will not be able to see the
> >> messages anyway, and messing with the video mode may display artifacts,
> >> and certainly get into several layers of complexity (including mutexes and
> >> memory allocations) which we shall be much safer to avoid.
> >
> > There's one exception is use printk_delay
> 
> OTOH the complexity do exist also when timeout is set, IMHO it is worth
> 

Hi Dave,

I agree. The complexity is worth it if you want to see the panic trace
on the VT. But if you have the panic_timeout negative (i.e. reboot
immediately) than you're just add more risk/complexity to panic for no
benefit.


To avoid losing the panic traces, a reliable panic is critical.

In our app, we use panic_timeout=-1 and we use ramoops for capturing panic
traces. We want the panic path to be as simple as possible to avoid
wedging machines and to avoid losing panic traces. In our test lab,
if a machine gets wedged, a human needs to go and power cycle the machine
to bring it back online.

For user devices, we want to panic quickly and get the device back up
ASAP. Our reboot time is under 8 seconds so its less than 10 seconds before
you're back online and surfing the web. We also want to avoid displaying any
artifacts or traces to the user when panicking.

You bring up a good point about printk_delay. But I'm thinking if you're
using prink_delay you'd also want to set panic_timeout >= 0. Otherwise,
you'd reboot immediately after displaying the last line of output.

Regards,
Mandeep

> >
> >>
> >> Signed-off-by: Hugh Dickins <hughd at google.com>
> >> [ Edited commit message and modified to short-circuit panic_timeout < 0
> >>  instead of testing panic_timeout >= 0.  -Mandeep ]
> >> Signed-off-by: Mandeep Singh Baines <msb at chromium.org>
> >> Cc: Dave Airlie <airlied at redhat.com>
> >> Cc: Andrew Morton <akpm at linux-foundation.org>
> >> Cc: dri-devel at lists.freedesktop.org
> >> ---
> >>  drivers/gpu/drm/drm_fb_helper.c |    7 +++++++
> >>  1 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> >> index f7c6854..0e62c93 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -254,6 +254,13 @@ bool drm_fb_helper_force_kernel_mode(void)
> >>  int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
> >>                        void *panic_str)
> >>  {
> >> +       /*
> >> +        * It's a waste of time and effort to switch back to text console
> >> +        * if the kernel should reboot before panic messages can be seen.
> >> +        */
> >> +       if (panic_timeout < 0)
> >> +               return 0;
> >> +
> >>        printk(KERN_ERR "panic occurred, switching back to text console\n");
> >>        return drm_fb_helper_force_kernel_mode();
> >>  }
> >> --
> >> 1.7.3.1
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >
> >
> >
> > --
> > Regards
> > Dave
> >
> 
> 
> 
> -- 
> Regards
> Dave