Xen devel - Apr 2005 - RE: Trying fbcon in dom1,but take_over_console fails...

> Since it has been some time, I have started by getting a 
> recent xen-unstable installed on my system, and I must say, 
> it looks really good! It seems very stable, and I can use 
> SMP. I have some problems getting X to work with the mga 
> driver in domain 0, but it works great with framebuffer 
> driver, so I can continue my work for now :-)
> 
> So, I''m moving on to trying to get X up in dom1. Unpatched X 
> won''t run in dom1 since Xen console is not true VT. So I 
> decided to give fbcon a try, expecting it to crash, but hey, 
> you never know ;-).
> Well, it does crash, from the oops it looks like the 
> take_over_console function (in linux/drivers/char/vt.c) can 
> not handle the request by fbcon.
> Would it be hard to get this to work? Anyone have tips on how 
> I can modify the Xen console to pass over control to fbcon so 
> that I have a true framebuffer console in my second domain? 
> This would be a great start to getting a X server up in dom1.
I suspect you''d be better off getting the xencons to register as ttyS0
(xencons=ttyS0) so that it doesn''t go anywhere near the console, and
compile in  VT, VT_CONSOLE and DUMMY_CONSOLE.

Please let us know how you get on.

Ian

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

Hi,
> I suspect you''d be better off getting the xencons to register as
ttyS0
> (xencons=ttyS0) so that it doesn''t go anywhere near the console,
and
> compile in  VT, VT_CONSOLE and DUMMY_CONSOLE.
Tried that, as well as disabling VGA_CONSOLE, but no improvements :-(:-(
however, when built as a module, it is somewhat easier to debug this
problem in fbcon, since dom1 is still running after it segfaults, and I can
still use dmesg to see the printk''s (strange that they don''t
appear on the
console...).
>
> Please let us know how you get on.
Ok, here''s what I found so far:

Using printk statements, I was able to find the culprit, it seems to be the
vc pointer which is not initialised properly.

Here''s the piece of code (from fbcon_startup):

        /* Setup default font */
        if (!p->fontdata) {
                if (!fontname[0] || !(font = find_font(fontname)))
                        font = get_default_font(info->var.xres,
                                                info->var.yres);

                DPRINTK("fbcon_startup: ca\n");

                vc->vc_font.width = font->width;
                vc->vc_font.height = font->height;
                vc->vc_font.data = p->fontdata = font->data;
                vc->vc_font.charcount = 256; /* FIXME  Need to support more 
fonts */

                DPRINTK("fbcon_startup: cb\n");

        }

And the oops occurs between the two DPRINTK''s...
So I added a check at startup:

static const char *fbcon_startup(void)
{
        const char *display_desc = "frame buffer device";
        struct display *p = &fb_display[fg_console];
        struct vc_data *vc = vc_cons[fg_console].d;
        struct font_desc *font = NULL;
        struct module *owner;
        struct fb_info *info = NULL;
        struct fbcon_ops *ops;
        int rows, cols;
        int irqres;

        DPRINTK("fbcon_startup... fg_console: %d, vc:
%d\n",fg_console,vc);

This prints 0 for the fg_console (not necessarely a problem) as well as vc... 
which is defenately a problem since it is dereferenced later!

Seems like the vc_cons is not setup right, I''ll have to take a look
into vt.c
I guess.
Could this be due to the missing ps/2 port on domU (since they are assigned to 
dom0)?

Will report back when I know more.


Regards,
Mark.

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