Mark Hurenkamp
2005-Apr-05 01:05 UTC
[Xen-devel] Trying fbcon in dom1,but take_over_console fails...
Hi, I''ve been away for a while, busy with other things, but now I''m back where I left off: trying to get X up outside dom0. 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. By the way, I''m running this on a dual-head matrox machine (using G450PCI and G550AGP cards), so I''m really trying to get two consoles up here, one for each domain. Framebuffer fb0 and fb1 seem to work fine in both domains, however most applications that use them require a true VT :-( Any hints/tips/pointers are welcome! Mark. Here´s the oops: --------------------------------------------------------------- Oops: 0002 [#1] SMP Modules linked in: fbcon font bitblit matroxfb_crtc2 matroxfb_base matroxfb_DAC1064 matroxfb_accel cfbcopyarea cfbimgblt cfbfillrect matroxfb_g450 g450_pll matroxfb_misc usbcore CPU: 0 EIP: 0061:[<db90c02a>] Not tainted VLI EFLAGS: 00010282 (2.6.11-xen0u1) EIP is at fbcon_startup+0x15a/0x330 [fbcon] eax: 00000008 ebx: d8e98000 ecx: 000003e8 edx: d98fad20 esi: d808aba0 edi: d808ac30 ebp: 00000000 esp: d87fbf30 ds: 007b es: 007b ss: 0069 Process modprobe (pid: 4613, threadinfo=d87fa000 task=d81b0aa0) Stack: 00000280 000001e0 00000000 d98ef880 db911dc0 00000000 d87fa000 db911a80 d87fa000 c021d7d4 00000000 00000000 00000000 0000000e 00000000 00000011 ffffffff 00000000 d87fa000 08058138 d87fa000 db90b34a db9105c0 00000000 Call Trace: [<c021d7d4>] take_over_console+0x44/0x3d0 [<db90b34a>] fbcon_takeover+0x6a/0xb0 [fbcon] [<d98c4276>] init_module+0x56/0x63 [fbcon] [<c01354e7>] sys_init_module+0x167/0x200 [<c010981b>] syscall_call+0x7/0xb Code: 04 85 c9 75 43 80 3d 20 39 91 db 00 0f 84 04 01 00 00 c7 04 24 20 39 91 db e8 e3 cf fe fd 85 c0 89 c2 0f 84 ee 00 00 00 8b 42 08 <89> 45 5c 8b 42 0c 89 45 60 8b 42 10 8b 54 24 10 89 42 04 c7 45 Segmentation fault _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt
2005-Apr-08 10:32 UTC
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@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Deepak Manohar
2005-May-20 15:13 UTC
Re: [Xen-devel] Trying fbcon in dom1,but take_over_console fails...
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@cl.cam.ac.uk> 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel