From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
Date: Mon, 07 Dec 2015 17:32:42 +0000 [thread overview]
Message-ID: <5665C2BA.3010304@ti.com> (raw)
In-Reply-To: <1440510314-8633-4-git-send-email-daniel.vetter@ffwll.ch>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On 25/08/15 16:45, Daniel Vetter wrote:
> When the usual fbcon legacy options are enabled we have
> ->register_framebuffer
> ->fb notifier chain calls into fbcon
> ->fbcon sets up console on new fbi
> ->fbi->set_par
> ->drm_fb_helper_set_par exercises full kms api
>
> And because of locking inversion hilarity all of register_framebuffer
> is done with the console lock held. Which means that the first time on
> driver load we exercise _all_ the kms code (all probe paths and
> modeset paths for everything connected) is under the console lock.
> That means if anything goes belly-up in that big pile of code nothing
> ever reaches logfiles (and the machine is dead).
>
> Usual tactic to debug that is to temporarily remove those console_lock
> calls to be able to capture backtraces. I'm fed up writing this patch
> and recompiling kernels. Hence this patch here to add an unsafe,
> kernel-taining option to do this at runtime.
I think this was never merged. This was part 4 of 4, were there
dependencies or...? Should I apply this for 4.5?
But then... I think my issues with console lock have been later at
runtime, not at register. Maybe we need a module option to disable the
console lock altogether. I wonder how much havoc that might create, though.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
Date: Mon, 7 Dec 2015 19:32:42 +0200 [thread overview]
Message-ID: <5665C2BA.3010304@ti.com> (raw)
In-Reply-To: <1440510314-8633-4-git-send-email-daniel.vetter@ffwll.ch>
[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]
On 25/08/15 16:45, Daniel Vetter wrote:
> When the usual fbcon legacy options are enabled we have
> ->register_framebuffer
> ->fb notifier chain calls into fbcon
> ->fbcon sets up console on new fbi
> ->fbi->set_par
> ->drm_fb_helper_set_par exercises full kms api
>
> And because of locking inversion hilarity all of register_framebuffer
> is done with the console lock held. Which means that the first time on
> driver load we exercise _all_ the kms code (all probe paths and
> modeset paths for everything connected) is under the console lock.
> That means if anything goes belly-up in that big pile of code nothing
> ever reaches logfiles (and the machine is dead).
>
> Usual tactic to debug that is to temporarily remove those console_lock
> calls to be able to capture backtraces. I'm fed up writing this patch
> and recompiling kernels. Hence this patch here to add an unsafe,
> kernel-taining option to do this at runtime.
I think this was never merged. This was part 4 of 4, were there
dependencies or...? Should I apply this for 4.5?
But then... I think my issues with console lock have been later at
runtime, not at register. Maybe we need a module option to disable the
console lock altogether. I wonder how much havoc that might create, though.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-12-07 17:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 13:45 [PATCH 1/4] drm: Make drm_fb_unregister/remove accept NULL fb Daniel Vetter
2015-08-25 13:45 ` [PATCH 2/4] drm/fb-helper: Use -errno return in restore_mode_unlocked Daniel Vetter
2015-08-25 15:20 ` [PATCH] " Daniel Vetter
2015-08-25 19:20 ` Rob Clark
2015-08-26 11:36 ` Daniel Vetter
2015-08-29 19:04 ` shuang.he
2015-08-25 13:45 ` [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation Daniel Vetter
2015-08-26 5:12 ` Archit Taneja
2015-08-26 8:44 ` Archit Taneja
2015-08-26 11:34 ` Daniel Vetter
2015-08-26 11:37 ` Daniel Vetter
2015-08-26 12:29 ` Archit Taneja
2015-08-26 12:51 ` Daniel Vetter
2015-08-26 12:18 ` Archit Taneja
2015-08-25 13:45 ` [PATCH 4/4] fbdev: Debug knob to register without holding console_lock Daniel Vetter
2015-08-25 13:45 ` Daniel Vetter
2015-08-25 19:24 ` Rob Clark
2015-08-25 19:24 ` Rob Clark
2015-09-01 10:32 ` Tomi Valkeinen
2015-09-01 10:32 ` Tomi Valkeinen
2015-09-01 14:34 ` Rob Clark
2015-09-01 14:34 ` Rob Clark
2015-09-01 14:41 ` Tomi Valkeinen
2015-09-01 14:41 ` Tomi Valkeinen
2015-09-01 15:12 ` Rob Clark
2015-09-01 15:12 ` Rob Clark
2015-09-01 15:31 ` Daniel Vetter
2015-09-01 15:31 ` Daniel Vetter
2015-09-24 10:56 ` Tomi Valkeinen
2015-09-24 10:56 ` Tomi Valkeinen
2015-12-07 17:32 ` Tomi Valkeinen [this message]
2015-12-07 17:32 ` Tomi Valkeinen
2015-12-08 8:19 ` Daniel Vetter
2015-12-08 8:19 ` Daniel Vetter
2015-12-08 8:26 ` Tomi Valkeinen
2015-12-08 8:26 ` Tomi Valkeinen
2015-08-25 19:19 ` [PATCH 1/4] drm: Make drm_fb_unregister/remove accept NULL fb Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5665C2BA.3010304@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=plagnioj@jcrosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.