From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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(); }
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@lists.freedesktop.org
Acked-by: David Rientjes rientjes@google.com
On Mon, 17 Oct 2011, David Rientjes wrote:
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@lists.freedesktop.org
Acked-by: David Rientjes rientjes@google.com
Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux.
David Rientjes (rientjes@google.com) wrote:
On Mon, 17 Oct 2011, David Rientjes wrote:
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@lists.freedesktop.org
Acked-by: David Rientjes rientjes@google.com
Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux.
The last status I have is Andrew pulling it into mmotm on 10/18/11.
Subject: + drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout.patch added to -mm tree From: akpm@linux-foundation.org Date: Tue, 18 Oct 2011 15:42:46 -0700
The patch titled Subject: drm: avoid switching to text console if there is no panic timeout has been added to the -mm tree. Its filename is drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout.patch
Where is mmotm hosted these days?
Regards, Mandeep
On Thu, Nov 10, 2011 at 9:15 PM, Mandeep Singh Baines msb@chromium.org wrote:
David Rientjes (rientjes@google.com) wrote:
On Mon, 17 Oct 2011, David Rientjes wrote:
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@lists.freedesktop.org
Acked-by: David Rientjes rientjes@google.com
Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux.
I've just pulled it into my local drm-next, thanks for reminding me.
Dave.
On Thu, 10 Nov 2011 13:15:04 -0800 Mandeep Singh Baines msb@chromium.org wrote:
David Rientjes (rientjes@google.com) wrote:
On Mon, 17 Oct 2011, David Rientjes wrote:
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@lists.freedesktop.org
Acked-by: David Rientjes rientjes@google.com
Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux.
The last status I have is Andrew pulling it into mmotm on 10/18/11.
Subject: + drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout.patch added to -mm tree From: akpm@linux-foundation.org Date: Tue, 18 Oct 2011 15:42:46 -0700
The patch titled Subject: drm: avoid switching to text console if there is no panic timeout has been added to the -mm tree. Its filename is drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout.patch
I need to do another round of sending patches to maintainers.
It's a depressing exercise because the great majority of patches are simply ignored. Last time I even added "please don't ignore" to the email Subject: on the more important ones. Sigh.
Where is mmotm hosted these days?
On my disk, until kernel.org ftp access returns.
But I regularly email tarballs to Stephen, so it's all in linux-next. The mmotm tree is largely unneeded now - use linux-next to get at -mm patches.
On Mon, Oct 17, 2011 at 17:06, Mandeep Singh Baines msb@chromium.org wrote:
From: Hugh Dickins hughd@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.
Signed-off-by: Hugh Dickins hughd@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@chromium.org
Acked-by: Stéphane Marchesin marcheu@chromium.org
Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines msb@chromium.org wrote:
From: Hugh Dickins hughd@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
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 18, 2011 at 10:19 AM, Dave Young hidave.darkstar@gmail.com wrote:
On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines msb@chromium.org wrote:
From: Hugh Dickins hughd@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
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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@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
Dave Young (hidave.darkstar@gmail.com) wrote:
On Tue, Oct 18, 2011 at 10:19 AM, Dave Young hidave.darkstar@gmail.com wrote:
On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines msb@chromium.org wrote:
From: Hugh Dickins hughd@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@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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@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
On Wed, Oct 19, 2011 at 2:29 AM, Mandeep Singh Baines msb@chromium.org wrote:
Dave Young (hidave.darkstar@gmail.com) wrote:
On Tue, Oct 18, 2011 at 10:19 AM, Dave Young hidave.darkstar@gmail.com wrote:
On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines msb@chromium.org wrote:
From: Hugh Dickins hughd@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.
fair enough, thanks.
Regards, Mandeep
Signed-off-by: Hugh Dickins hughd@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@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Andrew Morton akpm@linux-foundation.org Cc: dri-devel@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@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
dri-devel@lists.freedesktop.org
-
Andrew Morton -
Dave Airlie -
Dave Young -
David Rientjes -
Mandeep Singh Baines -
Stéphane Marchesin