Skip to contentSkip to conversation

linux Potential clean up of console transition

RFC PATCH In review Bill Burns 3 participants 11 messages Dec 4, 2008 – Dec 11, 2008

lore
Share & tools
lore

Bill Burns

author
#0 lore raw

RFC PATCH 1/1 linux Potential clean up of console transition

When using a video monitor for the console there is an issue with the transition between Hypervisor output and dom0 output (this is at least true in 3.1.2/2.6.18 vintage systems).

What happens is that the screen is full of the (XEN) messages and then the dom0 kernel starts off at the top of the screen and over prints until the screen starts to scroll. It's not all that noticeable since the output tends to be blow right past the issue.

But when the "quiet" boot arg is used for the dom0 kernel it can be user space output that collides and that can pose a problem. Like when a prompt for an encrypted file system cannot be read due to the mess on the screen.

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

Bill

xen/console/console.c 2008-12-04 17:23:12.000000000 -0500 renamed from xen/console/console.c.orig 2008-10-21 15:26:25.000000000 -0400 +6 -0
@@ -192,6 +192,8 @@ static struct console kcons_info = {
 
 static int __init xen_console_init(void)
 {
+        int i;
+
        if (!is_running_on_xen())
                goto out;
 

@@ -230,6 +232,10 @@ static int __init xen_console_init(void)
 
        register_console(&kcons_info);
 
+        if (screen_info.orig_video_mode == 3) {
+                for (i = 0; i < screen_info.orig_video_lines; i++)
+                        printk(KERN_ERR "\n");
+        }
  out:
        return 0;
 }
#1 lore raw

While I dislike the overwriting too, I don't think this is the solution. I never found time to locate where the orig_{x,y} members of struct screen_info are (supposed to be) used, but I think that this would be a better way to solve the problem. This is in particular because your approach pushes off Xen messages that someone else might find useful in case of an early crash.

Jan

Quoted 1 line
Quoted 1 line
Quoted 1 line

Bill Burns <[email protected]> 04.12.08 23:22 >>>

When using a video monitor for the console there is an issue with the transition between Hypervisor output and dom0 output (this is at least true in 3.1.2/2.6.18 vintage systems).

What happens is that the screen is full of the (XEN) messages and then the dom0 kernel starts off at the top of the screen and over prints until the screen starts to scroll. It's not all that noticeable since the output tends to be blow right past the issue.

But when the "quiet" boot arg is used for the dom0 kernel it can be user space output that collides and that can pose a problem. Like when a prompt for an encrypted file system cannot be read due to the mess on the screen.

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

Bill

xen/console/console.c 2008-12-04 17:23:12.000000000 -0500 renamed from xen/console/console.c.orig 2008-10-21 15:26:25.000000000 -0400 +6 -0
@@ -192,6 +192,8 @@ static struct console kcons_info = {
 
 static int __init xen_console_init(void)
 {
+        int i;
+
        if (!is_running_on_xen())
                goto out;
 

@@ -230,6 +232,10 @@ static int __init xen_console_init(void)
 
        register_console(&kcons_info);
 
+        if (screen_info.orig_video_mode == 3) {
+                for (i = 0; i < screen_info.orig_video_lines; i++)
+                        printk(KERN_ERR "\n");
+        }
  out:
        return 0;
 }

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

author
#2 lore raw
Quoted 6 lines · Jan Beulich

While I dislike the overwriting too, I don't think this is the solution. I never found time to locate where the orig_{x,y} members of struct screen_info are (supposed to be) used, but I think that this would be a better way to solve the problem. This is in particular because your approach pushes off Xen messages that someone else might find useful in case of an early crash.

Seeing as how Keir has fixed this it's a moot point, but my patch did not scroll off the Hypervisor messages. Since the first screenfull of kernel messages would overwrite the HV messages, all my patch did was cause the over writing to be a screenfull of invisible newlines. So the visible effect was to move the cursor to the bottom of the screen. No HV messages scrolled off. Scrolling then started with the next output.
So it really looked like it should with dom0 picking up where the HV left off.

We had debated fixing it in the HV as well and punted as it was not clear how to do it just when "quiet" was asserted. But in retrospect, it should always be done, quiet or not.

Thanks for the feedback,
Bill

Quoted 60 lines

Jan

Quoted 1 line
Quoted 1 line
Quoted 1 line

Bill Burns <[email protected]> 04.12.08 23:22 >>>

When using a video monitor for the console there is an issue with the transition between Hypervisor output and dom0 output (this is at least true in 3.1.2/2.6.18 vintage systems).

What happens is that the screen is full of the (XEN) messages and then the dom0 kernel starts off at the top of the screen and over prints until the screen starts to scroll. It's not all that noticeable since the output tends to be blow right past the issue.

But when the "quiet" boot arg is used for the dom0 kernel it can be user space output that collides and that can pose a problem. Like when a prompt for an encrypted file system cannot be read due to the mess on the screen.

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

Bill

xen/console/console.c 2008-12-04 17:23:12.000000000 -0500 renamed from xen/console/console.c.orig 2008-10-21 15:26:25.000000000 -0400 +6 -0
@@ -192,6 +192,8 @@ static struct console kcons_info = {
 
 static int __init xen_console_init(void)
 {
+        int i;
+
        if (!is_running_on_xen())
                goto out;
 

@@ -230,6 +232,10 @@ static int __init xen_console_init(void)
 
        register_console(&kcons_info);
 
+        if (screen_info.orig_video_mode == 3) {
+                for (i = 0; i < screen_info.orig_video_lines; i++)
+                        printk(KERN_ERR "\n");
+        }
  out:
        return 0;
 }

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#3 lore raw
In reply to Bill Burns
Quoted 6 lines · Bill Burns

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

I think it's better for Xen to clear the screen when it relinquishes the console. I've checked in a patch to do that. It still leaves the screen uncleared if the 'keep vga' option is specified to Xen (that's the mode where Xen tries to share with dom0, for debugging purposes). In that mode it seems unwise to clear screen data when we don't have to.

Jan talked about orig_x and orig_y but we don't actually pass such data to dom0 for vesa consoles, so there's no trivial solution there. I think what we have now is fine, since debuggability is still available by specifying that Xen share the vga console with dom0.

-- Keir

author
#4 lore raw
Quoted 15 lines · Keir Fraser
Quoted 6 lines · Bill Burns

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

I think it's better for Xen to clear the screen when it relinquishes the console. I've checked in a patch to do that. It still leaves the screen uncleared if the 'keep vga' option is specified to Xen (that's the mode where Xen tries to share with dom0, for debugging purposes). In that mode it seems unwise to clear screen data when we don't have to.

Quoted 5 lines

Jan talked about orig_x and orig_y but we don't actually pass such data to dom0 for vesa consoles, so there's no trivial solution there. I think what we have now is fine, since debuggability is still available by specifying that Xen share the vga console with dom0.

Cool, thanks!

Bill

Quoted 8 lines

-- Keir

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

author
#5 lore raw
In reply to Keir Fraser
Quoted 15 lines · Keir Fraser
Quoted 6 lines · Bill Burns

Below is a crude little loop that could be used to avoid the issue by outputting newlines to push the beginning of dom0's output to the bottom of the screen. Other suggestions are welcome. Note is uses KERN_ERR since "quiet" blocks output at the default printk level.

I think it's better for Xen to clear the screen when it relinquishes the console. I've checked in a patch to do that. It still leaves the screen uncleared if the 'keep vga' option is specified to Xen (that's the mode where Xen tries to share with dom0, for debugging purposes). In that mode it seems unwise to clear screen data when we don't have to.

Quoted 5 lines

Jan talked about orig_x and orig_y but we don't actually pass such data to dom0 for vesa consoles, so there's no trivial solution there. I think what we have now is fine, since debuggability is still available by specifying that Xen share the vga console with dom0.

Hmm, looked at the patch and you did the work in vesa_endboot, which really only exists in x86_64. So this only solves the issue for that platform. I had been fiddling in vga_endboot to work around that when I was looking at a HV fix.

Bill

Quoted 8 lines

-- Keir

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#6 lore raw
Quoted 5 lines · Bill Burns

Hmm, looked at the patch and you did the work in vesa_endboot, which really only exists in x86_64. So this only solves the issue for that platform. I had been fiddling in vga_endboot to work around that when I was looking at a HV fix.

It's done in vga_endboot too, if in a standard text mode. The code is different in each case.

-- Keir

author
#7 lore raw
Quoted 9 lines · Keir Fraser
Quoted 4 lines · Bill Burns

Hmm, looked at the patch and you did the work in vesa_endboot, which really only exists in x86_64. So this only solves the issue for that platform. I had been fiddling in vga_endboot to work around that when I was looking at a HV fix.

It's done in vga_endboot too, if in a standard text mode. The code is different in each case.

Ahh, sorry, rather than looking at the entire patch, I had just looked at 1 file....

Thanks,
Bill

Quoted 4 lines

-- Keir

author
#8 lore raw
Quoted 7 lines · Bill Burns
Quoted 6 lines · Keir Fraser
Quoted 4 lines · Bill Burns

Hmm, looked at the patch and you did the work in vesa_endboot, which really only exists in x86_64. So this only solves the issue for that platform. I had been fiddling in vga_endboot to work around that when I was looking at a HV fix.

Quoted 8 lines
Quoted 2 lines

It's done in vga_endboot too, if in a standard text mode. The code is different in each case.

Ahh, sorry, rather than looking at the entire patch, I had just looked at 1 file....

Thanks,
Bill

Tested out the change on x86_64 and it does not work for me. The Xen messages remain on the console and with the quiet kernel arg the user space output just intermixes with it and it's unreadable. (Using quiet is key, as non-quiet outputs so fast it's not possible to see the issue).

Bill

Quoted 10 lines
Quoted 4 lines

-- Keir

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#9 lore raw
Quoted 6 lines · Bill Burns

Tested out the change on x86_64 and it does not work for me. The Xen messages remain on the console and with the quiet kernel arg the user space output just intermixes with it and it's unreadable. (Using quiet is key, as non-quiet outputs so fast it's not possible to see the issue).

I got a switch statement the wrong way round. Fixed in c/s 18890.

-- Keir

author
#10 lore raw
Quoted 11 lines · Keir Fraser
Quoted 6 lines · Bill Burns

Tested out the change on x86_64 and it does not work for me. The Xen messages remain on the console and with the quiet kernel arg the user space output just intermixes with it and it's unreadable. (Using quiet is key, as non-quiet outputs so fast it's not possible to see the issue).

I got a switch statement the wrong way round. Fixed in c/s 18890.

Yes, that nailed it. Works great.

Thanks,
Bill

Quoted 8 lines

-- Keir

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel