1 files changed, 64 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1478376 b/results/classifier/zero-shot/108/other/1478376
new file mode 100644
index 000000000..c88483633
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1478376
@@ -0,0 +1,64 @@
+semantic: 0.907
+device: 0.743
+performance: 0.582
+socket: 0.577
+other: 0.530
+graphic: 0.511
+vnc: 0.458
+network: 0.436
+PID: 0.400
+permissions: 0.384
+files: 0.311
+debug: 0.290
+boot: 0.283
+KVM: 0.225
+
+PL050 KMIDATA register does not reset
+
+static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
+  ...
+   case 2: /* KMIDATA */
+        if (s->pending)
+            s->last = ps2_read_data(s->dev);
+        return s->last;
+}
+
+When the receive queue is empty (s->pending is false), is the KMIDATA register supposed to be reset to 0x00? In the current implementation,  the  KMIDATA  does not reverse its value after interrupt is lowered.
+
+On 26 July 2015 at 19:16, T-T Yu <email address hidden> wrote:
+> Public bug reported:
+>
+> static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
+>   ...
+>    case 2: /* KMIDATA */
+>         if (s->pending)
+>             s->last = ps2_read_data(s->dev);
+>         return s->last;
+> }
+>
+> When the receive queue is empty (s->pending is false), is the KMIDATA
+> register supposed to be reset to 0x00? In the current implementation,
+> the  KMIDATA  does not reverse its value after interrupt is lowered.
+
+The documentation for the PL050:
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0143c/i1014040.html
+
+just says that when KMIDATA is read you get the value in the
+receive data register. The implication is that if you read
+it multiple times you'll just continue to read the same
+value it holds until the keyboard sends further data to be
+clocked into the register.
+
+Are you saying that real hardware behaves differently?
+
+thanks
+-- PMM
+
+
+Yes. In our pl050 keyboard controller, the KMIDATA is reset once the receive queue is empty. 
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+