Bug 118436
Summary: | USB serial port doesn't process CR/LF | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Steve Timm <timm> | ||||||
Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 3.0 | CC: | petrides, riel | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i386 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2004-09-02 04:31:10 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Steve Timm
2004-03-16 18:40:57 UTC
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 |