28 messages in com.xensource.lists.xen-ia64-develRe: [Xen-ia64-devel] Console investig...| Subject: | Re: [Xen-ia64-devel] Console investigation. |
|---|---|
| From: | Tristan Gingold (Tris...@bull.net) |
| Date: | 12/09/2005 08:52:48 AM |
| List: | com.xensource.lists.xen-ia64-devel |
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-...@lists.xensource.com http://lists.xensource.com/xen-ia64-devel