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