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
[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):
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.
The step 3 is not sufficiently informative. What does it
actually mean, "Connect to it, try to do any command"?
By "connecting to it" I mean the following
I added the port as the serial console in /etc/inittab as follows:
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.
Created attachment 98795 [details]
Test fix 1
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.
Created attachment 98816 [details]
Test fix (RHEL)
Steve, please test a suitable kernel from this location:
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
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?
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.
A fix for this problem has just been committed to the RHEL3 U3
patch pool (in kernel version 2.4.21-15.1.EL).
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?
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?
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
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.