[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-xen/40675: Xen 3.3: guest serial console not functional
The following reply was made to PR port-xen/40675; it has been noted by GNATS.
From: "Christoph Egger" <Christoph_Egger%gmx.de@localhost>
To: Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>,
Subject: Re: port-xen/40675: Xen 3.3: guest serial console not functional
Date: Fri, 20 Feb 2009 17:01:01 +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?
Actually it unbroke Linux. With your patch it works, no matter
if you have unix98 ptys or BSD pty. W/o your patch and even
w/o my patch, only unix98 ptys worked.
My patch causes some troubles to unix98 ptys
with certain glibc / linux kernel versions.
> > > 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
> 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 ...
It is racey. There's a comment saying that at the very bottom
Main Index |
Thread Index |