From owner-freebsd-bugs@FreeBSD.ORG Wed Sep 15 22:10:03 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745451065672 for ; Wed, 15 Sep 2010 22:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 632468FC08 for ; Wed, 15 Sep 2010 22:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8FMA3Zj079947 for ; Wed, 15 Sep 2010 22:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8FMA3TL079946; Wed, 15 Sep 2010 22:10:03 GMT (envelope-from gnats) Date: Wed, 15 Sep 2010 22:10:03 GMT Message-Id: <201009152210.o8FMA3TL079946@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Heath N. Caldwell" Cc: Subject: Re: kern/110017: [libexec] [patch] serial port console output garbled X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Heath N. Caldwell" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 22:10:03 -0000 The following reply was made to PR kern/110017; it has been noted by GNATS. From: "Heath N. Caldwell" To: bug-followup@FreeBSD.org, dan@more.net Cc: Ji Li Subject: Re: kern/110017: [libexec] [patch] serial port console output garbled Date: Wed, 15 Sep 2010 14:49:44 -0700 We ran into this same problem with the PowerEdge 1950 and PowerEdge R710. I spent some time looking at the problem, and it looks like what is happening is that oflush() is called right before a case that will end up continuing back to the top of the loop, at which time setttymode() gets called, which calls tcflush() right off the bat (with TCIOFLUSH). So the buffered data is sent, but for at least these machines, it doesn't get a chance to be completely written before the call to tcflush(), causing it to get into a garbled state. Here is a patch that uses tcdrain() to make sure that the data is completely written to the terminal before returning from oflush(). I think that this addresses the problem more directly. --- getty/main.c (revision 212627) +++ getty/main.c (working copy) @@ -689,8 +689,10 @@ static void oflush(void) { - if (obufcnt) + if (obufcnt) { write(STDOUT_FILENO, outbuf, obufcnt); + tcdrain(STDOUT_FILENO); + } obufcnt = 0; } -- Heath Caldwell hncaldwell@fastsoft.com