Re: [patch 1/3] drm/fb-helper: don't sleep for screen unblank when anoops is in progress

From: Daniel Vetter
Date: Wed Jan 22 2014 - 03:45:20 EST

On Tue, Jan 21, 2014 at 11:34 PM, <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> From: Daniel Vetter <daniel.vetter@xxxxxxxx>
> Subject: drm/fb-helper: don't sleep for screen unblank when an oops is in progress
> Otherwise the system will burn even brighter and worse, leave the user
> wondering what's going on exactly.
> Since we already have a panic handler which will (try) to restore the
> entire fbdev console mode, we can just bail out. Inspired by a patch from
> Konstantin Khlebnikov. The callchain leading to this, cut&pasted from
> Konstantin's original patch:
> callstack:
> panic()
> bust_spinlocks(1)
> unblank_screen()
> vc->vc_sw->con_blank()
> fbcon_blank()
> fb_blank()
> info->fbops->fb_blank()
> drm_fb_helper_blank()
> drm_fb_helper_dpms()
> drm_modeset_lock_all()
> mutex_lock(&dev->mode_config.mutex)
> Note that the entire locking in the fb helper around panic/sysrq and kdbg
> is ... non-existant. So we have a decent change of blowing up
> everything. But since reworking this ties in with funny concepts like the
> fbdev notifier chain or the impressive things which happen around
> console_lock while oopsing, I'll leave that as an exercise for braver
> souls than me.
> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> Cc: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxx>
> Cc: Dave Airlie <airlied@xxxxxxxxx>
> Reviewed-by: Rob Clark <robdclark@xxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>

We've merged this twic already in 1b1d5397058f06b and
928c2f0c006bf7f381f58 and then had to take out the superflous hunk
again in ecc7e6f3bb8ad56764

For some oddball reason git/patch _really_ gets confused here and
loves to readd that hunk a few more times (iirc one of my own trees
once even ended up with 3 copies ...). No idea what's going on, but we
can drop this on here ;-)

Or what exactly was the point of this patch submission, I didn't spot
a "dropped from -mm" or similar note, and it doesn't seem to be cc'ed
to lists.

Cheers, Daniel
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at