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: Always 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:
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: 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.
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: ftp://people.redhat.com/zaitcev/us3/
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.
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 did 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 2.4.21-15.0.2ELsmp. 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 transient."
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. http://rhn.redhat.com/errata/RHBA-2004-433.html