RE: Trying fbcon in dom1,but take_over_console fails...

RE: Trying fbcon in dom1,but take_over_console fails...

[Ian Pratt]

 
> > 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
> 

Re: Trying fbcon in dom1,but take_over_console fails...

[Deepak Manohar]

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
>

Trying fbcon in dom1,but take_over_console fails...

[Mark Hurenkamp]

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

RE: Trying fbcon in dom1,but take_over_console fails...

[Ian Pratt]

 > 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

Re: Trying fbcon in dom1,but take_over_console fails...

[Mark Hurenkamp]

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.