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

[Bill Burns <bburns@xxxxxxxxxx>]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 
> http://lists.xensource.com/xen-devel
> 


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