2 files changed, 191 insertions, 0 deletions

diff --git a/results/classifier/108/other/507 b/results/classifier/108/other/507
new file mode 100644
index 00000000..da7619bc
--- /dev/null
+++ b/results/classifier/108/other/507
@@ -0,0 +1,71 @@
+semantic: 0.943
+other: 0.929
+graphic: 0.929
+permissions: 0.924
+debug: 0.917
+performance: 0.891
+device: 0.878
+PID: 0.870
+vnc: 0.861
+socket: 0.846
+boot: 0.842
+files: 0.774
+KVM: 0.751
+network: 0.749
+
+rx / gdbsim-r5f562n7 / serial errors
+Description of problem:
+Test hangs (about once every two executions) because the console emits an error and expected content is not found.  Console content on a failed test execution:
+
+```
+15:49:05 DEBUG| Linux version 4.19.0+ (yo-satoh@yo-satoh-debian) (gcc version 9.0.0 20181105 (experimental) (GCC)) #137 Wed Feb 20 23:20:02 JST 2019
+15:49:05 DEBUG| Built 1 zonelists, mobility grouping on.  Total pages: 8128
+15:49:05 DEBUG| Kernel command line:
+15:49:05 DEBUG| Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
+15:49:05 DEBUG| Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
+15:49:05 DEBUG| Memory: 14648K/32768K available (871K kernel code, 95K rwdata, 140K rodata, 96K init, 175K bss, 18120K reserved, 0K cma-reserved)
+15:49:05 DEBUG| NR_IRQS: 256
+15:49:05 DEBUG| rx-cmt: used for periodic clock events
+15:49:05 DEBUG| clocksource: rx-tpu: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1274173631191 ns
+15:49:05 DEBUG| 96.00 BogoMIPS (lpj=480000)
+15:49:05 DEBUG| pid_max: default: 4096 minimum: 301
+15:49:05 DEBUG| Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
+15:49:05 DEBUG| Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
+15:49:05 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+15:49:05 DEBUG| clocksource: Switched to clocksource rx-tpu
+15:49:05 DEBUG| workingset: timestamp_bits=30 max_order=12 bucket_order=0
+15:49:05 DEBUG| SuperH (H)SCI(F) driver initialized
+15:49:05 DEBUG| 88240.serial: ttySC0 at MMIO 0x88240 (irq = 215, base_baud = 0) is a sci
+15:49:05 DEBUG| console [ttySC0] enabled
+15:49:05 DEBUG| 88248.serial: ttySC1 at MMIO 0x88248 (irq = 219, base_baud = 0) is a sci
+15:49:05 DEBUG| random: get_random_bytes called from 0x01002e48 with crng_init=0
+15:49:05 DEBUG| Freeing unused kernel memory: 96K
+15:49:05 DEBUG| This architecture does not have kernel memory protection.
+15:49:05 DEBUG| Run /sbin/init as init process
+15:49:05 DEBUG| Run /etc/init as init process
+15:49:05 DEBUG| Run /bin/init as init process
+15:49:05 DEBUG| Run /bin/sh as init process
+15:49:05 DEBUG| Sash command shell (version 1.1.1)
+15:49:05 DEBUG| />sh-sci 88240.serial: overrun error
+15:49:05 DEBUG| sh-sci 88240.serial: frame error
+15:49:05 DEBUG| sh-sci 88240.serial: parity error
+15:49:09 DEBUG| random: fast init done
+```
+
+Instead of the last 4 lines seen here, a successful test contains:
+
+```
+20:59:53 DEBUG| Sash command shell (version 1.1.1)
+20:59:53 DEBUG| /> printenv
+20:59:53 DEBUG| HOME=/
+20:59:53 DEBUG| TERM=linux
+20:59:53 DEBUG| >>> {'execute': 'quit'}
+20:59:53 DEBUG| <<< {'return': {}}
+```
+
+It was also observed that the test is much more prone to fail when it runs restricted to a single CPU (with taskset).  It's not clear to me if this is a Kernel or QEMU issue.
+Steps to reproduce:
+1. ./configure --target-list=rx-softmmu
+2. meson compile
+3. make check-venv
+4. ./tests/venv/bin/avocado run tests/acceptance/machine_rx_gdbsim.py:RxGdbSimMachine.test_linux_sash
diff --git a/results/classifier/108/other/50773216 b/results/classifier/108/other/50773216
new file mode 100644
index 00000000..b7f8c0d2
--- /dev/null
+++ b/results/classifier/108/other/50773216
@@ -0,0 +1,120 @@
+permissions: 0.813
+device: 0.764
+other: 0.737
+graphic: 0.723
+semantic: 0.669
+files: 0.666
+debug: 0.659
+vnc: 0.656
+socket: 0.652
+boot: 0.637
+PID: 0.636
+performance: 0.628
+network: 0.606
+KVM: 0.601
+
+[Qemu-devel] Can I have someone's feedback on [bug 1809075] Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel
+
+Hi everyone.
+Can I please have someone's feedback on this bug?
+https://bugs.launchpad.net/qemu/+bug/1809075
+Briefly, guest OS loses characters sent to it via vnc. And I spot the
+bug in relation to ps2 driver.
+I'm thinking of possible fixes and I might want to use a memory barrier.
+But I would really like to have some suggestion from a qemu developer
+first. For example, can we brutally drop capslock LED key events in ps2
+queue?
+It is actually relevant to openQA, an automated QA tool for openSUSE.
+And this bug blocks a few test cases for us.
+Thank you in advance!
+
+Kind regards,
+Gao Zhiyuan
+
+Cc'ing Marc-André & Gerd.
+
+On 12/19/18 10:31 AM, Gao Zhiyuan wrote:
+>
+Hi everyone.
+>
+>
+Can I please have someone's feedback on this bug?
+>
+https://bugs.launchpad.net/qemu/+bug/1809075
+>
+Briefly, guest OS loses characters sent to it via vnc. And I spot the
+>
+bug in relation to ps2 driver.
+>
+>
+I'm thinking of possible fixes and I might want to use a memory barrier.
+>
+But I would really like to have some suggestion from a qemu developer
+>
+first. For example, can we brutally drop capslock LED key events in ps2
+>
+queue?
+>
+>
+It is actually relevant to openQA, an automated QA tool for openSUSE.
+>
+And this bug blocks a few test cases for us.
+>
+>
+Thank you in advance!
+>
+>
+Kind regards,
+>
+Gao Zhiyuan
+>
+
+On Thu, Jan 03, 2019 at 12:05:54PM +0100, Philippe Mathieu-Daudé wrote:
+>
+Cc'ing Marc-André & Gerd.
+>
+>
+On 12/19/18 10:31 AM, Gao Zhiyuan wrote:
+>
+> Hi everyone.
+>
+>
+>
+> Can I please have someone's feedback on this bug?
+>
+>
+https://bugs.launchpad.net/qemu/+bug/1809075
+>
+> Briefly, guest OS loses characters sent to it via vnc. And I spot the
+>
+> bug in relation to ps2 driver.
+>
+>
+>
+> I'm thinking of possible fixes and I might want to use a memory barrier.
+>
+> But I would really like to have some suggestion from a qemu developer
+>
+> first. For example, can we brutally drop capslock LED key events in ps2
+>
+> queue?
+There is no "capslock LED key event".  0xfa is KBD_REPLY_ACK, and the
+device queues it in response to guest port writes.  Yes, the ack can
+race with actual key events.  But IMO that isn't a bug in qemu.
+
+Probably the linux kernel just throws away everything until it got the
+ack for the port write, and that way the key event gets lost.  On
+physical hardware you will not notice because it is next to impossible
+to type fast enough to hit the race window.
+
+So, go fix the kernel.
+
+Alternatively fix vncdotool to send uppercase letters properly with
+shift key pressed.  Then qemu wouldn't generate capslock key events
+(that happens because qemu thinks guest and host capslock state is out
+of sync) and the guests's capslock led update request wouldn't get into
+the way.
+
+cheers,
+  Gerd
+