4 files changed, 141 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/1843 b/results/classifier/gemma3:12b/device/1843
new file mode 100644
index 00000000..c9e2d50c
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1843
@@ -0,0 +1,16 @@
+
+Multitouch - GTK:  Tapping 3 points or more at too close in interval causes all points to be lost
+Description of problem:
+When using the new multitouch input device, if you use three or more fingers within two rapid interval, the all finger inputs get dropped.
+Steps to reproduce:
+ANDROID
+1. Download and install BlissOS
+2. Swipe with two fingers
+3. try multitouch debug app
+
+FEDORA
+1. Load fedora
+2. install wev
+3. try touch 3 or more points
+Additional information:
+Not sure what logs are relevant
diff --git a/results/classifier/gemma3:12b/device/1843651 b/results/classifier/gemma3:12b/device/1843651
new file mode 100644
index 00000000..689a82ff
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1843651
@@ -0,0 +1,81 @@
+
+m68k fpu bug
+
+On gcc123 cfarm machine,
+I was testing m68k executables generated by Free Pascal Compiler.
+
+muller@gcc123:~/pas/check$ cat inf.pp
+function get_double(x : double):double;
+  begin
+    get_double:=x;
+  end;
+
+
+var
+  y : double;
+  py : pbyte;
+  i : byte;
+begin
+  y:=1.0/0.0;
+  py:=@y;
+{$ifdef ENDIAN_LITTLE}
+  write('little endian y=');
+  for i:=7 downto 0 do
+{$else not ENDIAN_LITTLE}
+  write('big endian y=');
+  for i:=0 to 7 do
+{$endif}
+    write(hexstr(py[i],2));
+  writeln;
+  y:=get_double(y)+1;
+{$ifdef ENDIAN_LITTLE}
+  write('little endian y=');
+  for i:=7 downto 0 do
+{$else not ENDIAN_LITTLE}
+  write('big endian y=');
+  for i:=0 to 7 do
+{$endif}
+    write(hexstr(py[i],2));
+  writeln;
+end.
+muller@gcc123:~/pas/check$ ppc68k inf
+Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k
+Copyright (c) 1993-2019 by Florian Klaempfl and others
+Target OS: Linux for m68k
+Compiling inf.pp
+Assembling program
+Linking inf
+33 lines compiled, 0.1 sec
+muller@gcc123:~/pas/check$ ./inf
+big endian y=7FF0000000000000
+big endian y=7FFFFFFFFFFFFFFF
+muller@gcc123:~/pas/check$ qemu-m68k ./inf
+big endian y=7FF0000000000000
+big endian y=7FFFFFFFFFFFFFFF
+muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf
+qemu-m68k        qemu-m68k-fixed
+muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf
+big endian y=7FF0000000000000
+big endian y=7FF0000000000000
+
+~/sys-root/bin/qemu-m68k  is 4.1.0 release,
+~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change:
+
+gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K)
+gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define floatx80_infinity_low  LIT64(0x0000000000000000)
+gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else
+gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define floatx80_infinity_low  LIT64(0x8000000000000000)
+gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif
+
+the M68K branch value is set to the same value as the other branch.
+
+The problem of the M68K specific floatx86_infinity_low values
+is that is enters in conflict with
+muller@gcc123:~/pas/check$ grep -nA6 invalid_enc  /home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h
+752:static inline bool floatx80_invalid_encoding(floatx80 a)
+753-{
+754-    return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0;
+755-}
+
+And thus the m68k variant of floatx80 representing +Infinity is
+considered as an invalid encoding, and thus converted into a NaN 7FFFFFFFFFFFFFFF
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1843711 b/results/classifier/gemma3:12b/device/1843711
new file mode 100644
index 00000000..e23e49a1
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1843711
@@ -0,0 +1,12 @@
+
+qemu-xhci device should detect if libusb host supports streams
+
+When using USB passthrough with the qemu-xhci (and nec-usb-xhci), streams are enabled by default, but if the host xHCI controller doesn't support them, it will trigger hard-to-debug UAS guest errors.
+
+This should be possible to detect since the kernel returns ENOSYS (errno 38) when xhci host controller does not support streams:
+            libusb: error [do_streams_ioctl] streams-ioctl failed error -1 errno 38
+            qemu: libusb_alloc_streams: -99 [OTHER]
+
+Maybe libusb should return a dedicated error instead of LIBUSB_ERROR_OTHER in this case, but qemu does not handle any other error code anyway.
+
+Just trying to enable streams before enabling them in qemu should do it. I don't know if it should be done in hcd-xhci.c, host-libusb.c or elsewhere, but this would be detectable at launch instead of a static option true/false, maybe a ternary with auto would be better.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1843795 b/results/classifier/gemma3:12b/device/1843795
new file mode 100644
index 00000000..4f1078ee
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1843795
@@ -0,0 +1,32 @@
+
+'mtfsf' instruction can clear FI incorrectly
+
+Using mtfsf instruction can clear the FPSCR FI bit incorrectly.  This code snippet exhibits the issue:
+--
+  fpscr.ll = 0x1fffffff;
+  __builtin_mtfsf (0b11111111, fpscr.d);
+  fpscr.d = __builtin_mffs ();
+--
+
+On POWER9 hardware:
+mffs    : FPSCR = 0x000000007ffff7ff
+
+On qemu (git master; "-cpu POWER9"):
+--
+$ ./mtfsf
+mffs    : FPSCR = 0x000000007ffdffff
+--
+
+Two differences:
+bit 52: "reserved", so maybe a "don't care" case
+bit 46: "FI"
+
+$ git log -1 master
+commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1
+Merge: 019217c 2531164
+Author: Peter Maydell <email address hidden>
+Date:   Mon Sep 9 09:48:34 2019 +0100
+
+I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/
+
+Test attached.
\ No newline at end of file