Bug 110017 - [libexec] [patch] serial port console output garbled
Summary: [libexec] [patch] serial port console output garbled
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-06 23:20 UTC by Dan D Niles
Modified: 2017-12-31 22:34 UTC (History)
0 users

See Also:


Attachments
file.diff (468 bytes, patch)
2007-03-06 23:20 UTC, Dan D Niles
no flags Details | Diff
file.diff (588 bytes, patch)
2007-03-06 23:20 UTC, Dan D Niles
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dan D Niles 2007-03-06 23:20:04 UTC
	When using a serial port for a console, entering a blank line,
a line that starts with a '-', or a line containing only spaces causes
the output to become garbled.  This can result in loss of console output
when you are using a console server that stores console output (such
as the Cyclades AlterPath console servers).

The problem has been there for a while, but is more pronounced on a
Dell 1950 or 2950.

Fix: Inserting a sleep(1) before the setttymode(0) inside the
main for loop fixes the problem.  I'm not sure _why_ it works,
but I don't think it is unreasonable to have a small delay after
entering invalid input.

Here are two potential patches.  The first one is the simplest.
The second one can be used instead if a 1 sec delay is undesireable 
when AB or PS are set.  The output might get garbled when AB or
PS are set, I did not test that.  If they do, the second patch
would not work.

And the alternate patch:

How-To-Repeat: 	On a Dell 2950, enable console redirection and set up ttyd0
in /etc/ttys.
	Connect to the serial port.
	Hit Enter.
	The output will look something like:

nooo~:Woo{;>6(|uww~now~nou})|t}}t9-
Comment 1 hcaldwell 2010-09-15 22:49:44 UTC
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
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:45 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped