| Summary: | Redhat 5.7 xen kernel will not show all the output in xvc | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | zou.chris | ||||
| Component: | kernel-xen | Assignee: | Xen Maintainance List <xen-maint> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 5.7 | CC: | drjones, imammedo, leiwang, lersek, mrezanin, pbonzini, qguan, qwan, xen-maint | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 5.7 | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: |
RHEL5.7 Xen
|
|||||
| Last Closed: | 2011-12-13 12:57:03 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Using hvc (or perhaps xvc too) between dom0 and Xen should take care of flow control from dom0 to Xen. Dependent on: - the hardware of both host and guest, - and possibly the wiring (pinout) of the null-modem cable connecting them, the serial output of Xen can behave differently. We have checked the above testcase in two setups. The host sides running Xen were identical (HP workstations with real serial ports). The cables were separate objects, and one client used a USB-to-Serial converter, the other a real serial port. Surprisingly, the setup with USB-to-Serial converter works perfectly (doesn't lose a single byte), while the serial-to-serial setup lists about 10K and then stops printing anything. However, this dropping behavior of RHEL-5 Xen is intentional. See bug 518338 and commit cd5f91c7 (called "xen-allow-booting-with-broken-serial-hardware.patch" in the SRPM.) The idea behind that patch is: instead of being blocked by potentially broken hardware forever, remove flow control and start dropping data in *big* chunks, until the output buffer sinks below the half mark. This is the explanation why serial output can be skippy, and sometimes just "stop" -- the output backlog is constantly kept over the half mark. Note that said patch adds the SERIAL_NEVER_DROP_CHARS macro, which reintroduces flow control. I guess one could experiment with rebuilding the SRPM, #defining the macro in the SPEC file or somewhere else, but it's untested and unsupported. The behavior being deliberate, I'm closing this bug as WONTFIX. Actually: due to the above, this is not a bug, but a feature. hi I was not authorized to access bug #518338,would you mind coping all the words to me, many thanks Created attachment 546629 [details] cd5f91c [xen] allow booting with broken serial hardware (In reply to comment #3) > hi I was not authorized to access bug #518338,would you mind coping all the > words to me, many thanks Unfortunately I can't do that. However, the patch file that I mentioned before has an extensive description and is public. I'm attaching it for your convenience. Many thanks. We will have a try. |
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install Redhat Enterprise Linux 5.7 64bit with Xen enabled. 2. Change grub.conf: a. append the following to the kernel line: com1=9600,8n1 console=com1,vga b. append the following to the vmlinuz line: console=xvc xencons=xvc 3. Change /etc/inittab to contain the following line: xv:2345:respawn:/sbin/agetty xvc0 9600 vt100 4. Add xvc0 to /etc/securetty. 5. Enable com1 console redirection in BIOS setup and boot to system. 6. Login from com1 via a serial cable. 7. Issue "ls -R /": ==> fail, command exit in few seconds, but not all of the output of this command is shown. Actual results: Expected results: Additional info: