[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uEAB+K=uqzrJvnDkTELnW+7qB-b6zsx_=Ua5skt6iC5mg@mail.gmail.com>
Date: Wed, 22 Jan 2014 09:44:56 +0100
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Dave Airlie <airlied@...ux.ie>, Dave Airlie <airlied@...il.com>,
Konstantin Khlebnikov <khlebnikov@...nvz.org>,
"Clark, Rob" <robdclark@...il.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/3] drm/fb-helper: don't sleep for screen unblank when an
oops is in progress
On Tue, Jan 21, 2014 at 11:34 PM, <akpm@...ux-foundation.org> wrote:
> From: Daniel Vetter <daniel.vetter@...ll.ch>
> 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@...ll.ch>
> Cc: Konstantin Khlebnikov <khlebnikov@...nvz.org>
> Cc: Dave Airlie <airlied@...il.com>
> Reviewed-by: Rob Clark <robdclark@...il.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
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 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists