[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Trying fbcon in dom1,but take_over_console fails...


  • To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
  • From: Deepak Manohar <mjdeepak@xxxxxxxxx>
  • Date: Fri, 20 May 2005 08:13:59 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Hurenkamp <mark.hurenkamp@xxxxxxxxx>
  • Delivery-date: Fri, 20 May 2005 15:13:27 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qOnFTX3yQkakhkBdg78+fjcO5oPUzBB/0zAfhVOYNKGgNnbe+u0jKETIir9WovL4l1HKMy/8CoIbqlLaM0FWxRQNwspP2Qtj3+B1VBEhG8y+X2pCeq1+QYL5E1q43Tq6DRBB6piKGBKlUSmv3Ts2hzpzCCDPf9TkCmhpuLMDmWk=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi Mark,

 Was any progress made on this? Were you able to get X to run in one
of the user domains?

 If not what is the status? Maybe you could give me some pointers on
what needs to be done?

Thanks
Deepak


On 4/8/05, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> wrote:
> 
> > > 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
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.