summary refs log tree commit diff stats
path: root/results/classifier/108/debug/1688231
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/108/debug/1688231')
-rw-r--r--results/classifier/108/debug/168823187
1 files changed, 0 insertions, 87 deletions
diff --git a/results/classifier/108/debug/1688231 b/results/classifier/108/debug/1688231
deleted file mode 100644
index 18f4f55b..00000000
--- a/results/classifier/108/debug/1688231
+++ /dev/null
@@ -1,87 +0,0 @@
-debug: 0.949
-boot: 0.941
-other: 0.927
-performance: 0.916
-PID: 0.915
-graphic: 0.908
-device: 0.902
-permissions: 0.901
-semantic: 0.892
-socket: 0.876
-vnc: 0.826
-network: 0.821
-KVM: 0.814
-files: 0.763
-
-[Qemu-ppc] sendkey is not working for any of the keystrokes
-
-sendkey option is not working for any of the keystrokes in ppc64le,
-
-Qemu version:
-# qemu-img --version
-qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty)
-
-Qemu command line:
-# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22
-
-Guest booted successfully and logged in
-Fedora 25 (Twenty Five)
-Kernel 4.11.0-rc4 on an ppc64le (hvc0)
-
-atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left
-root
-Password: 
-Last login: Mon Mar 27 01:57:51 on hvc0
-[root@atest-guest ~]# 
-
-Qemu monitor:
-# telnet 127.0.0.1 1234
-Trying 127.0.0.1...
-Connected to 127.0.0.1.
-Escape character is '^]'.
-QEMU 2.9.50 monitor - type 'help' for more information
-(qemu) sendkey a
-(qemu) sendkey ret
-
-But from the console, I couldn't observe the keystroke a or return.
-
-I see this happening in ppc64le and x86_64 with QEMU v2.11.0-1684-ga6e0344fa0. The keystrokes are being sent to tty1:
-
-in x86_64:
-
-./v2.11.0-1684-ga6e0344fa0/bin/qemu-system-x86_64 -enable-kvm -m 512 -kernel vmlinuz -initrd initramfs.img -chardev serial,id=s1,path=/dev/pts/10 -mon chardev=s1 -qmp tcp:localhost:4444,server,nowait -vga none -nographic -append "console=ttyS0 i8042.debug"
-
-QEMU 2.11.50 monitor - type 'help' for more information                    
-(qemu) sendkey a
-(qemu) sendkey b
-(qemu) sendkey c
-(qemu) sendkey ret
-
-# cat /dev/tty1
-abc
-
----
-same thing with input-send-event:
-
-{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "a" } } }]}
-{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ret" } } }]}
-
-# cat /dev/tty1
-abc
-a
-
-
-I'm not sure what is the expected behavior when using two input sources in this way (serial line + PS/2 keyboard). I'm inclined to say that the keys should indeed not be seen in the serial console.
-
-Yes, you are right: sendkey does not send keys to the serial console. I had a chat with Peter last year about it in the IRC where the explained:
-
-<danielhb> hey! quick question: is the 'sendkey' monitor command supposed to send the key presses to the serial console of the guest when running with -nographics ? The command works fine with VGA/VNC graphics but the serial console doesn't show the character key being sent by the command
-<pm215> no, 'sendkey' sends a key to whatever physical keyboard is currently being emulated, regardless of what is being done with serial devices
-<danielhb> pm215, I 've debugged the code and saw that the scancodes are being sent to the emulated keyboard via sendkey. I just wondered why the serial console doesn't show the keysyms but the VGA does
-<pm215> because keyboards don't plug into serial terminals
-<pm215> this is like having a server with a PC keyboard plugged into it and also a serial port which you're using as the serial terminal
-<pm215> pressing a key on the PC keyboard doesn't do anything to the serial terminal
-<danielhb> pm215, that makes sense, haven't thought of  that. thanks!
-
-Given that the bug report was created around a wrong assumption, this should be closed.
-