The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Expose this setting via
/sys/class/graphics/fbcon/cursor_blink_ms
Values written to the interface set the approximate time interval in
milliseconds between cursor toggles, from 1 to 32767. Since the interval
is stored internally as a number of jiffies, the millisecond value read
from the interface may not exactly match the entered value.
An outstanding blink timer is reset after a new value is entered.
If the cursor blink is disabled, either via the 'cursor_blink' boolean
setting or some other mechanism, the 'cursor_blink_ms' setting may still
be modified. The new value will be used if the blink is reactivated.
Signed-off-by: Scot Doyle <redacted>
Normally, this would be set by ansi escape sequences, no? We can hide
cursor using them, set its appearance.. makes sense to change timing
value there, too....
Pavel
Hi Pavel, what about something like this? For example,
"echo -e '\033[16;500]' would set the blink interval to 500 milliseconds.
The duration is stored twice to avoid locking the console in
cursor_timer_handler().
@@ -104,6 +104,7 @@ struct vc_data {unsignedintvc_resize_user;/* resize request from user */unsignedintvc_bell_pitch;/* Console bell pitch */unsignedintvc_bell_duration;/* Console bell duration */+unsignedshortvc_cur_blink_ms;/* Cursor blink duration */structvc_data**vc_display_fg;/* [!] Ptr to var holding fg console for this display */structuni_pagedir*vc_uni_pagedir;structuni_pagedir**vc_uni_pagedir_loc;/* [!] Location of uni_pagedir variable for this console */
From: Pavel Machek <hidden> Date: 2015-02-26 22:02:50
On Wed 2015-02-25 23:32:00, Scot Doyle wrote:
On Wed, 25 Feb 2015, Pavel Machek wrote:
quoted
On Mon 2015-01-26 20:41:53, Scot Doyle wrote:
quoted
The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Expose this setting via
/sys/class/graphics/fbcon/cursor_blink_ms
Values written to the interface set the approximate time interval in
milliseconds between cursor toggles, from 1 to 32767. Since the interval
is stored internally as a number of jiffies, the millisecond value read
from the interface may not exactly match the entered value.
An outstanding blink timer is reset after a new value is entered.
If the cursor blink is disabled, either via the 'cursor_blink' boolean
setting or some other mechanism, the 'cursor_blink_ms' setting may still
be modified. The new value will be used if the blink is reactivated.
Signed-off-by: Scot Doyle <redacted>
Normally, this would be set by ansi escape sequences, no? We can hide
cursor using them, set its appearance.. makes sense to change timing
value there, too....
Pavel
Hi Pavel, what about something like this? For example,
"echo -e '\033[16;500]' would set the blink interval to 500 milliseconds.
The duration is stored twice to avoid locking the console in
cursor_timer_handler().
Yes, I'd say this matches the existing code better.
Acked-by: Pavel Machek <redacted>
+ case 16: /* set cursor blink duration in msec */
+ if (vc->vc_npar >= 1 && vc->vc_par[1] > 0 &&
+ vc->vc_par[1] <= USHRT_MAX)
+ vc->vc_cur_blink_ms = vc->vc_par[1];
+ else
Greg, the first patch of this series is for the tty tree.
Tomi, the second patch of this series is for your tree, but it depends on
the first patch. Also, will you remove these two previously queued patches?
"fbcon: store cursor blink interval in fbcon_ops"
"fbcon: expose cursor blink interval via sysfs"
Michael, I plan to send a documentation patch if these are accepted.
This patch series adds an escape sequence to specify the current console's
cursor blink interval. The default interval is set to fbcon's currently
hardcoded 200 msecs.
Scot Doyle (2):
vt: add cursor blink interval escape sequence
fbcon: use the cursor blink interval provided by vt
drivers/tty/vt/vt.c | 9 +++++++++
drivers/video/console/fbcon.c | 10 +++++-----
drivers/video/console/fbcon.h | 1 +
include/linux/console_struct.h | 1 +
4 files changed, 16 insertions(+), 5 deletions(-)
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
---
drivers/tty/vt/vt.c | 9 +++++++++
include/linux/console_struct.h | 1 +
2 files changed, 10 insertions(+)
@@ -104,6 +104,7 @@ struct vc_data {unsignedintvc_resize_user;/* resize request from user */unsignedintvc_bell_pitch;/* Console bell pitch */unsignedintvc_bell_duration;/* Console bell duration */+unsignedshortvc_cur_blink_ms;/* Cursor blink duration */structvc_data**vc_display_fg;/* [!] Ptr to var holding fg console for this display */structuni_pagedir*vc_uni_pagedir;structuni_pagedir**vc_uni_pagedir_loc;/* [!] Location of uni_pagedir variable for this console */
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
---
drivers/video/console/fbcon.c | 10 +++++-----
drivers/video/console/fbcon.h | 1 +
2 files changed, 6 insertions(+), 5 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2015-03-02 11:15:56
On 27/02/15 21:10, Scot Doyle wrote:
Greg, the first patch of this series is for the tty tree.
Tomi, the second patch of this series is for your tree, but it depends on
the first patch. Also, will you remove these two previously queued patches?
"fbcon: store cursor blink interval in fbcon_ops"
"fbcon: expose cursor blink interval via sysfs"
I have dropped those two patches from fbdev tree.
I don't know much about the console side, so I can't comment anything on
that.
Tomi
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
Hi Greg, sorry about your backlog. Is it too soon for a ping?
@@ -104,6 +104,7 @@ struct vc_data {unsignedintvc_resize_user;/* resize request from user */unsignedintvc_bell_pitch;/* Console bell pitch */unsignedintvc_bell_duration;/* Console bell duration */+unsignedshortvc_cur_blink_ms;/* Cursor blink duration */structvc_data**vc_display_fg;/* [!] Ptr to var holding fg console for this display */structuni_pagedir*vc_uni_pagedir;structuni_pagedir**vc_uni_pagedir_loc;/* [!] Location of uni_pagedir variable for this console */
On Fri, Feb 27, 2015 at 07:13:48PM +0000, Scot Doyle wrote:
quoted hunk
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
---
drivers/tty/vt/vt.c | 9 +++++++++
include/linux/console_struct.h | 1 +
2 files changed, 10 insertions(+)
@@ -1590,6 +1591,13 @@ static void setterm_command(struct vc_data *vc)case15:/* activate the previous console */set_console(last_console);break;+case16:/* set cursor blink duration in msec */
Where is this now documented? Is this a "standard" ASCII command
somewhere? Adding new userspace apis have to be documented properly.
Without that, I can't take this series, sorry.
greg k-h
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
---
drivers/tty/vt/vt.c | 9 +++++++++
include/linux/console_struct.h | 1 +
2 files changed, 10 insertions(+)
@@ -104,6 +104,7 @@ struct vc_data {unsignedintvc_resize_user;/* resize request from user */unsignedintvc_bell_pitch;/* Console bell pitch */unsignedintvc_bell_duration;/* Console bell duration */+unsignedshortvc_cur_blink_ms;/* Cursor blink duration */structvc_data**vc_display_fg;/* [!] Ptr to var holding fg console for this display */structuni_pagedir*vc_uni_pagedir;structuni_pagedir**vc_uni_pagedir_loc;/* [!] Location of uni_pagedir variable for this console */
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
---
drivers/video/console/fbcon.c | 10 +++++-----
drivers/video/console/fbcon.h | 1 +
2 files changed, 6 insertions(+), 5 deletions(-)
@@ -70,6 +70,7 @@ struct fbcon_ops {structfb_cursorcursor_state;structdisplay*p;intcurrcon;/* Current VC. */+intcur_blink_jiffies;intcursor_flash;intcursor_reset;intblank_state;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <redacted>
---
man4/console_codes.4 | 1 +
1 file changed, 1 insertion(+)
@@ -377,6 +377,7 @@ ESC [ 15 ] T{ Bring the previous console to the front (since Linux 2.6.0). T}+ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds. .TE .SSCharactersets The kernel knows about 4 translations of bytes into console-screen
From: Mike Frysinger <hidden> Date: 2015-03-28 00:35:11
On 26 Mar 2015 13:54, Scot Doyle wrote:
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
if they want to be crazy, why not let them ? it's not like we generally prevent
the user from destroying their machine. i.e. just require the value to be > 0
(unless you want to let 0 disable things).
-mike
From: Pavel Machek <hidden> Date: 2015-03-28 07:50:32
On Fri 2015-03-27 20:35:03, Mike Frysinger wrote:
On 26 Mar 2015 13:54, Scot Doyle wrote:
quoted
Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.
if they want to be crazy, why not let them ? it's not like we generally prevent
the user from destroying their machine. i.e. just require the value to be > 0
(unless you want to let 0 disable things).
From: Pavel Machek <hidden> Date: 2015-03-28 07:51:13
On Thu 2015-03-26 13:57:44, Scot Doyle wrote:
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <redacted>
From: Pavel Machek <hidden> Date: 2015-03-28 07:54:53
On Thu 2015-03-26 13:51:04, Scot Doyle wrote:
v2: Add documentation to console_codes man page (man-pages repo)
This patch series adds an escape sequence to specify the current console's
cursor blink interval. The default interval is set to fbcon's currently
hardcoded 200 msecs.
On Sat, Mar 28, 2015 at 08:54:43AM +0100, Pavel Machek wrote:
On Thu 2015-03-26 13:51:04, Scot Doyle wrote:
quoted
v2: Add documentation to console_codes man page (man-pages repo)
This patch series adds an escape sequence to specify the current console's
cursor blink interval. The default interval is set to fbcon's currently
hardcoded 200 msecs.
Actually... Greg, can you import console_codes.4 into kernel tree somehow?
Is that file part of the manpages project? If so, it's fine where it
is, otherwise feel free to send a patch.
thanks,
greg k-h
From: Kevin Hilman <khilman@kernel.org> Date: 2015-05-19 21:15:52
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
Kevin
[1] http://storage.kernelci.org/next/next-20150519/arm-exynos_defconfig/lab-khilman/boot-exynos5800-peach-pi_rootfs:mmc.html
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
From: Kevin Hilman <khilman@kernel.org> Date: 2015-05-19 21:45:25
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted hunk
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Thierry
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
thanks,
greg k-h
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Thierry
Hi all, sorry for the trouble.
The timer delete was to prevent blink stutter when updating the interval.
Since the stutter isn't so noticable when changing from the default 200ms,
and since most people seem to prefer leaving the fbcon code alone if
possible, I agree with Thierry's approach.
Tested-by: Scot Doyle <redacted>
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote:
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
quoted
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
Attached.
Ugh, no, please resend it as a stand-alone patch, I can't easily apply
attachments.
thanks,
greg k-h
On Wed, May 20, 2015 at 09:26:38PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
quoted
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
Attached.
Ugh, no, please resend it as a stand-alone patch, I can't easily apply
attachments.
Really? Your MUA can't dissect multipart messages? Anyway, sent
separately for your convenience.
Thierry
On Thu, May 21, 2015 at 10:00:50AM +0200, Thierry Reding wrote:
On Wed, May 20, 2015 at 09:26:38PM -0700, Greg Kroah-Hartman wrote:
quoted
On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
quoted
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
Attached.
Ugh, no, please resend it as a stand-alone patch, I can't easily apply
attachments.
Really? Your MUA can't dissect multipart messages? Anyway, sent
separately for your convenience.
"git am" doesn't do that. I apply patches in huge chunks of mbox files.
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 21, 2015 at 07:00:31PM -0700, Greg Kroah-Hartman wrote:
On Thu, May 21, 2015 at 10:00:50AM +0200, Thierry Reding wrote:
quoted
On Wed, May 20, 2015 at 09:26:38PM -0700, Greg Kroah-Hartman wrote:
quoted
On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
quoted
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
quoted
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
quoted
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
[off-list ref] wrote:
quoted
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
quoted
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle [off-list ref] wrote:
quoted
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
Signed-off-by: Scot Doyle <redacted>
Acked-by: Pavel Machek <redacted>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <redacted>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
Attached.
Ugh, no, please resend it as a stand-alone patch, I can't easily apply
attachments.
Really? Your MUA can't dissect multipart messages? Anyway, sent
separately for your convenience.
"git am" doesn't do that. I apply patches in huge chunks of mbox files.
What I frequently end up doing is apply patches straight from mutt by
piping the mail or an attached patch to git am. I guess I had expected
that you'd have something similar to simplify applying patches.
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Thierry
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
Thierry
On Fri, May 22, 2015 at 1:49 PM, Thierry Reding
[off-list ref] wrote:
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
quoted
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
You can write your recipients to the "To:" header of the patch you
generated using git format-patch. git send-email will pick all
recipients thus specified up automatically. In later iterations you
can just copy the "To:" line.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 22 May 2015 13:49:58 Thierry Reding wrote:
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
quoted
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
You can have a line starting with 8<------ (the scissors symbol) after
your reply, and then paste the patch below.
I usually use 'git show --format=email | xclip' to copy the patch into
the X clipboard and paste it into the email window from there.
Arnd
On Fri, May 22, 2015 at 01:49:58PM +0200, Thierry Reding wrote:
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
quoted
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
Reply from the MUA and then just put the patch in the email body. If
you have a good MUA it should be trivial to do[1]
thanks,
greg k-h
1) mutt drops you to your editor, and then you can just read in the
patch file directly to that buffer.
On Fri, May 22, 2015 at 03:24:30PM +0200, Arnd Bergmann wrote:
On Friday 22 May 2015 13:49:58 Thierry Reding wrote:
quoted
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
quoted
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
You can have a line starting with 8<------ (the scissors symbol) after
your reply, and then paste the patch below.
I usually use 'git show --format=email | xclip' to copy the patch into
the X clipboard and paste it into the email window from there.
Cool, that's pretty useful. I should be able to do that without going
through the X clipboard with mutt/vim even.
Thanks,
Thierry
On Fri, May 22, 2015 at 07:32:05AM -0700, Greg Kroah-Hartman wrote:
On Fri, May 22, 2015 at 01:49:58PM +0200, Thierry Reding wrote:
quoted
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote:
quoted
On Friday 22 May 2015 12:00:03 Thierry Reding wrote:
quoted
quoted
Remember, if I have to hand-edit, or do something special with your
patch, I will not do it, you need to do it correctly to make
maintainer's lives easier, not harder, given that maintainers are the
limited resouce, not developers.
I understand. I'll make a mental note to never send you patches as
attachment again.
Better make that a general rule. My workflow is different from Greg's
but also doesn't cope well with attachments. A lot of people in turn
have problems quoting from an attachment when replying to the patch,
which happens to work for me.
Okay. Any hints on how to simplify sending out such patches with the
same list of recipients? I find it very annoying to have to manually
copy each recipient into the git send-email command-line, but I don't
know of a better way to do it. Replying to an email from the MUA will
at least do that automatically.
Reply from the MUA and then just put the patch in the email body. If
you have a good MUA it should be trivial to do[1]
thanks,
greg k-h
1) mutt drops you to your editor, and then you can just read in the
patch file directly to that buffer.
Indeed, that should work. As I understand it, I wouldn't even have to
further edit the email (except strip the reply) because git am prefers
headers in the patch to headers in the message (it certainly does that
for From:, so I suspect it would do it for Date: and Subject: as well).
Or if that doesn't work, Arnd's suggestion to use a scissors line is a
good alternative as well.
Thanks guys for the suggestions,
Thierry
vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().
I regularly execute criu tests on linux-next. For this, I use virtual
machine from the digitalocean clould. The current version of
linux-next hangs after a few seconds. I use git bisect to find the
commit where the problem is appeaed. And it looks like the problem is
in this patch.
When the kernel hangs, it doesn't report anything on the screen and
there is nothing suspicious in logs after reboot.
I will try to reproduce the problem in my local enviroment to get more
information.
There is my config file:
https://github.com/avagin/criu-jenkins-digitalocean/blob/d95d9e30a7da8755c47b290630bac7ee1fe7132d/jenkins-scripts/config
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I regularly execute criu tests on linux-next. For this, I use virtual
machine from the digitalocean clould. The current version of
linux-next hangs after a few seconds. I use git bisect to find the
commit where the problem is appeaed. And it looks like the problem is
in this patch.
I regularly execute criu tests on linux-next. For this, I use virtual
machine from the digitalocean clould. The current version of
linux-next hangs after a few seconds. I use git bisect to find the
commit where the problem is appeaed. And it looks like the problem is
in this patch.
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <redacted>
---
man4/console_codes.4 | 1 +
1 file changed, 1 insertion(+)
@@ -377,6 +377,7 @@ ESC [ 15 ] T{ Bring the previous console to the front (since Linux 2.6.0). T}+ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds. .TE .SSCharactersets The kernel knows about 4 translations of bytes into console-screen
--
2.1.0
Hi Michael,
Will you apply now that Linus has pulled the rest?
(see bd63364caa8df38bad2b25b11b2a1b849475cce5)
Thank you,
Scot
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Michael Kerrisk (man-pages) <hidden> Date: 2015-07-21 16:55:37
Hello Scot,
On 5 July 2015 at 19:41, Scot Doyle [off-list ref] wrote:
On Thu, 26 Mar 2015, Scot Doyle wrote:
quoted
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <redacted>
I've applied this, adding Pavel's Acked-by.
I also added some text to note that this appeared in Linux 4.2. Okay?
Cheers,
Michael
@@ -377,6 +377,7 @@ ESC [ 15 ] T{ Bring the previous console to the front (since Linux 2.6.0). T}+ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds. .TE .SSCharactersets The kernel knows about 4 translations of bytes into console-screen--
2.1.0
Hi Michael,
Will you apply now that Linus has pulled the rest?
(see bd63364caa8df38bad2b25b11b2a1b849475cce5)
Thank you,
Scot
On Tue, 21 Jul 2015, Michael Kerrisk (man-pages) wrote:
On 5 July 2015 at 19:41, Scot Doyle [off-list ref] wrote:
quoted
On Thu, 26 Mar 2015, Scot Doyle wrote:
quoted
Add a Console Private CSI sequence to specify the current console's
cursor blink interval. The interval is specified as a number of
milliseconds until the next cursor display state toggle, from 50 to
65535.
Signed-off-by: Scot Doyle <redacted>
I've applied this, adding Pavel's Acked-by.
I also added some text to note that this appeared in Linux 4.2. Okay?
Yes, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html