Bug 118436 - USB serial port doesn't process CR/LF
Summary: USB serial port doesn't process CR/LF
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-16 18:40 UTC by Steve Timm
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-02 04:31:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test fix 1 (11.01 KB, patch)
2004-03-23 19:20 UTC, Pete Zaitcev
no flags Details | Diff
Test fix (RHEL) (15.60 KB, patch)
2004-03-24 02:58 UTC, Pete Zaitcev
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:433 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 3 2004-09-02 04:00:00 UTC

Description Steve Timm 2004-03-16 18:40:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Description of problem:
I have IBM X440 server running Red Hat Enterprise Linux 3.0 AS
(Identical problem also existed under RHEL 2.1)
[root@fnpca root]# uname -a
Linux fnpca.fnal.gov 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST
2004 i686 i686 i386 GNU/Linux
belkin_sa               7320   1
usbserial              22300   0  [belkin_sa]

belkin_sa usb to serial adapter being used.
[root@fnpca root]# lsusb
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 002: ID 050d:0103 Belkin Components F5U103 Serial
Adapter [etek]
[root@fnpca root]# dmesg | grep ttyUSB0
usbserial.c: Belkin / Peracom / GoHubs USB Serial Adapter converter
now attached to ttyUSB0 (or usb/tts/0 for devfs)

The problem is that we can see output on this port but it 
does not process cr/lf combinations directly.
IBM hardware support investigated this problem and found
that it is due to a bug in the USB serial driver which 
only has one character available to the terminal at a time,
thus it can't interpret the CR-LF combinations directly
and most output all scrolls together onto the same line.
IBM tech support claims this is a kernel bug and needs to be fixed.

If there is any way to make this device available to GRUB
it would be very helpful as well.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Connect belkin serial-usb adapter to any usb port
2.OS will recognize it as ttyUSB0 on any boot
3. Connect to it, try to do any command:


Actual Results:  All output, except that which is using ncurses,
scrolls one line
on top of the other without ever doing LF.

Expected Results:  IT should be a normal terminal output.

Additional info:

Comment 1 Pete Zaitcev 2004-03-17 19:47:46 UTC
The step 3 is not sufficiently informative. What does it
actually mean, "Connect to it, try to do any command"?

Comment 2 Steve Timm 2004-03-17 19:54:21 UTC
By "connecting to it" I mean the following
I added the port as the serial console in /etc/inittab as follows:

c:12345:respawn:/sbin/mingetty ttyUSB0

and added ttyUSB0 to /etc/securetty

rebooted the machine
Then I get a login: prompt on that port
which I can log into.

But all output, whether it be the login: and password: prompt
or output from any normal command, scrolls onto the same line
of the screen.

Comment 3 Pete Zaitcev 2004-03-23 19:20:45 UTC
Created attachment 98795 [details]
Test fix 1

Comment 4 Pete Zaitcev 2004-03-23 19:23:47 UTC
This is definitely my fault, sorry. I expect the fix to come out
with U3. Attached patch is against Fedora, I have to merge it
into RHEL yet, but I am sure it nails the issue.

Comment 5 Pete Zaitcev 2004-03-24 02:58:28 UTC
Created attachment 98816 [details]
Test fix (RHEL)

Comment 6 Pete Zaitcev 2004-04-06 05:44:50 UTC
Steve, please test a suitable kernel from this location:

Comment 7 Steve Timm 2004-04-22 20:27:45 UTC
It was not possible to install the test kernel on my system.
When I tried with rpm -i kernel-smp-2.4.21-12.usbserial3.1.EL.i686.rpm
the process just hung indefinitely.

pstree showed me that there is a process "nash" which is a
subprocess of this that was in state "D"
root      8718  0.0  0.0   100   60 pts/0    D    11:55   0:00
/sbin/nash --force --quiet

redhat phone support informs me I will have to reboot the system
to get rid of it.

I think this bug is not fixed until I get a kernel RPM I could
actually install.

Comment 8 Steve Timm 2004-04-23 14:59:49 UTC
Further investigation found that this kernel, or any kernel,
took about 3-4 hours to install on my system, most of the
extra time was spent in the "nash" subprocess of the %post 
script.  But install it did, and when I rebooted the 
system into the new kernel and 

stty 57600 --file=/dev/ttyUSB0

I am able to log into this serial console and it works just fine.
As I suspected, however, a USB console is not appropriate
to send the output of GRUB and the kernel boot messages too,
because it isn't activated that early.

But it works for what it was intended to do.

Is it OK to leave my system running with this kernel 
or should I go back to the 2.4.21-9.0.3 errata kernel from 
redhat for security purposes?

Comment 9 Steve Timm 2004-04-23 15:01:00 UTC
PS--the kernel installing bugs have been opened as 
a new bug against mkinitrd/kernel, bug 121577.
The problem of a slow kernel install on this system is 
true for any kernel rpm, not just this test one.

Comment 10 Ernie Petrides 2004-05-04 04:21:50 UTC
A fix for this problem has just been committed to the RHEL3 U3
patch pool (in kernel version 2.4.21-15.1.EL).

Comment 11 Steve Timm 2004-07-22 16:02:48 UTC
I have just installed kernel 2.4.21-15.0.3ELsmp 
and the fix is not in that kernel, nor was it in 

Was it supposed to be?

Comment 12 Pete Zaitcev 2004-07-22 18:38:13 UTC
The fix is coming out in U3.

We need to publicise and evangelize the RHEL kernel naming scheme.
I thought it was self-evident, but apparently not?

Comment 13 Ernie Petrides 2004-07-23 00:11:38 UTC
Steve, in answer to comment #11: no.  The fix will be in the next
update (U3) of RHEL3, which is expected to begin its external beta
period tomorrow or Monday.  The kernel version will be 2.4.21-18.EL.

Pete, in answer to comment #12: we have had lengthly internal debate
about the RHEL3 naming scheme, and a brief recap is available on our
Intranet (ASEng3KernelNumberingScheme.html).  It has also been shared
with a couple of our partners.  Here's the synopsis:

"We are trying to move toward a more flexible model whereby we
have multiple (parallel) code streams undergoing changes, some of
which may be released to customers.

Here's a table of possible names that we expect to use:

    -4.EL	initial release of RHEL 3
    -x.EL	an official RHEL 3 Update release (where x > 4)
    -x.0.z.EL	an official RHEL 3 Errata release based on -x.EL

    -x.y.EL	internal Engineering builds in an Update stream
    -x.y.z.EL	possible Interim builds offered to select partners
		    and customers with time-critical requirements
		    (branched from -x.y.EL where y > 0)

In all of these cases, x, y, and z are numbers with potentially more
than one digit.  There is also a convention of appending arbitrary
text strings (matching the regular expression [a-zA-Z0-9._]*) to any
of the conventions above to identify an internally built kernel that
is not supported.  This is used by developers providing special
testing/debugging kernel packages whose use outside of Red Hat is

Comment 14 John Flanagan 2004-09-02 04:31:10 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.