[PATCH, RFC] linux Potential clean up of console transition

[PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

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


--- drivers/xen/console/console.c.orig  2008-10-21 15:26:25.000000000 -0400
+++ drivers/xen/console/console.c       2008-12-04 17:23:12.000000000 -0500
@@ -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;
 }

Re: [PATCH,RFC] linux Potential clean up of console transition

[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.

Jan

>>> Bill Burns <bburns@redhat.com> 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


--- drivers/xen/console/console.c.orig  2008-10-21 15:26:25.000000000 -0400
+++ drivers/xen/console/console.c       2008-12-04 17:23:12.000000000 -0500
@@ -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
Xen-devel@lists.xensource.com 
http://lists.xensource.com/xen-devel

Re: [PATCH,RFC] linux Potential clean up of console transition

[Bill Burns]

Jan Beulich wrote:
> 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

> Jan
> 
>>>> Bill Burns <bburns@redhat.com> 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
> 
> 
> --- drivers/xen/console/console.c.orig  2008-10-21 15:26:25.000000000 -0400
> +++ drivers/xen/console/console.c       2008-12-04 17:23:12.000000000 -0500
> @@ -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
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel
> 

Re: [PATCH, RFC] linux Potential clean up of console transition

[Keir Fraser]

On 04/12/2008 22:22, "Bill Burns" <bburns@redhat.com> wrote:

> 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

Re: [PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

Keir Fraser wrote:
> On 04/12/2008 22:22, "Bill Burns" <bburns@redhat.com> wrote:
> 
>> 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.
> 

Cool, thanks!

 Bill


>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

Keir Fraser wrote:
> On 04/12/2008 22:22, "Bill Burns" <bburns@redhat.com> wrote:
> 
>> 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.
> 

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

>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH, RFC] linux Potential clean up of console transition

[Keir Fraser]

On 05/12/2008 12:40, "Bill Burns" <bburns@redhat.com> wrote:

> 
> 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

Re: [PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

Keir Fraser wrote:
> On 05/12/2008 12:40, "Bill Burns" <bburns@redhat.com> wrote:
> 
>> 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

> 
>  -- Keir
> 
> 

Re: [PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

Bill Burns wrote:
> Keir Fraser wrote:
>> On 05/12/2008 12:40, "Bill Burns" <bburns@redhat.com> wrote:
>>
>>> 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


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



> 
>>  -- Keir
>>
>>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH, RFC] linux Potential clean up of console transition

[Keir Fraser]

On 08/12/2008 15:53, "Bill Burns" <bburns@redhat.com> wrote:

> 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

Re: [PATCH, RFC] linux Potential clean up of console transition

[Bill Burns]

Keir Fraser wrote:
> On 08/12/2008 15:53, "Bill Burns" <bburns@redhat.com> wrote:
> 
>> 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


>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel