diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1772086')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1772086 | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1772086 b/results/classifier/zero-shot/108/other/1772086 new file mode 100644 index 000000000..a6a7b0bf6 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1772086 @@ -0,0 +1,48 @@ +semantic: 0.766 +other: 0.657 +device: 0.626 +PID: 0.554 +graphic: 0.549 +files: 0.546 +network: 0.489 +performance: 0.468 +vnc: 0.429 +socket: 0.409 +permissions: 0.385 +debug: 0.383 +boot: 0.294 +KVM: 0.257 + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. + +Something somewhere in the stack is converting LF to CRLF. This could be something inside your guest, or in QEMU, or in the host; to find out where we need more detail. + +Can you describe your setup, including: + * complete QEMU command line + * how you're sending data inside the guest + * how you're reading it on the host end +please? + + +I am unable to provide complete QEMU command line as I'm using virt-manager to deal with configuration. I can say that two serial ports are linked with physical ones through the /dev/ttyS* files. +The guests I tested it with are Windows 98 and Windows XP. For the testing I connected one port to another. I could confirm through a kernel level serial monitor that I was indeed sending just \n but on the second port I received \r\n. I also received \r\n when the port was read by the host. +Host is Ubuntu Xenial. + +After doing a bit of research I think line 142 in file chardev/char-serial.c is problematic. https://github.com/qemu/qemu/blob/master/chardev/char-serial.c#L142 + +It enables output processing, which is something unwanted here. With a simple test program I found out that by default, besides OPOST, ONLCR flag is set in c_oflag. I guess fix would be removing OPOST flag, which would disable any output processing, or setting c_oflag to 0 just to be sure. + +Seems like the problems isn't really new and might be at least 6 years old if not more. https://robert.penz.name/550/mapping-a-serial-device-to-a-kvm-guest-may-lead-to-communication-problems/ + +It's even older than 6 years, see: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +and: +https://bugs.launchpad.net/qemu/+bug/1407813 +https://bugs.launchpad.net/qemu/+bug/1715296 + + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + |