|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Trying fbcon in dom1,but take_over_console fails...
> > 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...).
Do you actually need fbcon? You don't need it to run X in most setups.
[If you want the printk's to come out on the console, use the KERN_ALERT prefix]
Ian
> >
> > 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|