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

Re: [Xen-ia64-devel] Console investigation.



Le Vendredi 09 DÃcembre 2005 16:38, Alex Williamson a Ãcrit :
> On Fri, 2005-12-09 at 16:58 +0200, Tristan Gingold wrote:
> > Hi,
> >
> > here are my first results.
> > Kernel is compiled with CONFIG_VT and without CONFIG_SERIAL_8250.
> >
> > On the first boot, I got error messages such as:
> > Warning: dev (ttyS-1) tty->count(7) != #fd's(1) in tty_open
>
>    I get similar results, except when I specify xencons=ttyS1, the dev
> listed in the error message is ttyS2.  However, I get the same results
> on x86_64, so I think we're uncovering a generic bug (or I don't
> understand how it's supposed to work).
Do you set CONFIG_VT on x86_64.  If yes, you may be lost.

> > The reason is that kcons_info.index is -1 (which is wrong), because kcons
> > is not the first console and its index field is set to -1.
> > Indeed, the first console is hpsim_cons, which has no tty.
>
>    Are you using a recent xen-ia64-unstable.hg pull?  We recently made
> the change that set the CON_BOOT flag on the hpsim_cons, which should
> make it automatically unregister itself.  Perhaps that explains the
> difference between our results.
Yes, my has CON_BOOT set.  But this flag is useless for this issue, since 
kcons_info.index may be set only when the console is registered.

[...]
> > So, why do we wan to set CONFIG_VT in dom0 or domU ?
>
>    I think you should be able to get domU to work in a similar way if
> you specify both "xencons=ttyS0" and "console=ttyS0".  Until there's a
> xen console with it's own unique device entries (so it doesn't compete
> with 8250 and VT), I think our generic solution might be to boot all
> domains with something like "xencons=ttySX console=ttySX" where X is a
> number greater than the number of device entries the 8250 driver
> registers.
I can compile with CONFIG_VT using the console_use_vt trick.  This patch is 
not that clean!

******************
diff -r 0255f48b757f linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c     Sun Dec  4 19:12:00 
2005
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c     Fri Dec  9 14:37:43 
2005
@@ -414,6 +414,16 @@
 #endif

 #ifdef CONFIG_VT
+# ifdef CONFIG_XEN
+       {
+               extern int running_on_xen;
+               if (running_on_xen) {
+                       /* Disable VT when running on XEN.  */
+                       extern int console_use_vt;
+                       console_use_vt = 0;
+               }
+       }
+# endif
        if (!conswitchp) {
 # if defined(CONFIG_DUMMY_CONSOLE)
                conswitchp = &dummy_con;
*******************


>  I think that will allow us to have both drivers compiled
> into the kernel, however it doesn't work yet though.  This is also where
> that boot option or hypervisor magic would come in handy to hide the
> console UART.  Once dom0 discovers the console UART it seems to mess
> with it's baud rate and bad things happen.  domU domains won't have this
> problem since they can't see the physical UART.  Thanks,
So, we have to disable UART.  I will work on that.

Tristan.


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


 


Rackspace

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