Re: port-xen/40675: Xen 3.3: guest serial console not functional

[Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

The following reply was made to PR port-xen/40675; it has been noted by GNATS.

From: Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Christoph Egger <Christoph_Egger%gmx.de@localhost>
Subject: Re: port-xen/40675: Xen 3.3: guest serial console not functional
Date: Fri, 20 Feb 2009 16:48:54 +0100

 On Fri, Feb 20, 2009 at 04:38:10PM +0100, Christoph Egger wrote:
 > 
 > > On Fri, Feb 20, 2009 at 02:56:51PM +0100, Christoph Egger wrote:
 > > > 
 > > > Nope, that doesn't fix it.
 > > 
 > > Did you try it out?
 > 
 > Yes. Sorry, I was too fast. I thought that doesn't fit with
 > unix98 vs. BSD ptys.
 > 
 > I tested it on Linux, too. It works there, too.
 > I can only send patches upstream which don't break Linux.
 
 So my patch broke Linux?
 
 > > I had the problem described in this PR
 > > on an amd64, running NetBSD-5.0_RC2 with xentools33 (2008Q4)
 > > and it disappears with my patch.  I printed the terminal
 > > attributes after openpty() and they were garbage on the first
 > > console, valid on the second etc.
 > 
 > When openpty() returns garbage, isn't it broken then?
 
 Openpty() gets garbage in (uninitialized attributes MODIFIED by cfmakeraw()).
 It sets the slave to the attributes requested.
 
 > > This just hides the bug.  We create a pty pair with random
 > > attributes, close the slave so these attributes disappear and
 > > hope the slave will be reopened and initialized.
 > 
 > And this happens on second console then ?
 
 The initialization will come from xenconsole (init_term(spty, ...)).
 This looks racey ...
 
 -- 
 Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)