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

[Alex Williamson <alex.williamson@xxxxxx>]

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

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

> Maybe kcons should be enabled early and hpsim_cons completly disabled.
> 
> After disabling hpsim_cons, /dev/ttyS0 now works, but /dev/console prints to 
> nowhere.  The reason is that /dev/console is vt, which does not work.
> 
> My fix is to add console=ttyS0 on the command line.
> 
> Now, domU console does not work, because /dev/console is vt.  My fix is to 
> undef CONFIG_VT, which also fix the previous problem.
> 
> 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 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,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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