From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/108/PID/1133769 |  47 ---------
 results/classifier/108/PID/1708551 | 157 ----------------------------
 results/classifier/108/PID/1760    |  68 -------------
 results/classifier/108/PID/1821054 |  68 -------------
 results/classifier/108/PID/1857811 | 204 -------------------------------------
 results/classifier/108/PID/2423    |  49 ---------
 results/classifier/108/PID/655     |  47 ---------
 7 files changed, 640 deletions(-)
 delete mode 100644 results/classifier/108/PID/1133769
 delete mode 100644 results/classifier/108/PID/1708551
 delete mode 100644 results/classifier/108/PID/1760
 delete mode 100644 results/classifier/108/PID/1821054
 delete mode 100644 results/classifier/108/PID/1857811
 delete mode 100644 results/classifier/108/PID/2423
 delete mode 100644 results/classifier/108/PID/655

(limited to 'results/classifier/108/PID')

diff --git a/results/classifier/108/PID/1133769 b/results/classifier/108/PID/1133769
deleted file mode 100644
index 379ff210..00000000
--- a/results/classifier/108/PID/1133769
+++ /dev/null
@@ -1,47 +0,0 @@
-PID: 0.996
-other: 0.996
-files: 0.993
-semantic: 0.984
-performance: 0.983
-socket: 0.980
-graphic: 0.980
-device: 0.975
-debug: 0.970
-vnc: 0.940
-KVM: 0.932
-permissions: 0.930
-network: 0.929
-boot: 0.810
-
-qtest failures leave orphaned qemu processes hanging around
-
-If a qtest test case fails, it leaves orphaned qemu processes hanging around. On Fedora 18 with qemu.git as of today ( Feb 26 2013), the  patch just forces a test failure
-
-ps axwww | grep qemu | grep -v grep
-$ make check-qtest-x86_64
-  CC    tests/rtc-test.o
-  LINK  tests/rtc-test
-GTESTER check-qtest-x86_64
-
-$ ps axwww | grep qemu | grep -v grep
-$ patch -p1 < force-test-failure.patch
-patching file tests/rtc-test.c
-
-$ make check-qtest-x86_64
-  CC    tests/rtc-test.o
-  LINK  tests/rtc-test
-GTESTER check-qtest-x86_64
-**
-ERROR:tests/rtc-test.c:256:bcd_check_time: assertion failed: (0)
-GTester: last random seed: R02Sf2521dda395a2713128e0cbf86651a21
-make: *** [check-qtest-x86_64] Error 1
-
-$ ps axwww | grep qemu | grep -v grep
-26258 pts/0    Sl     0:00 x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-26256.sock,nowait -qtest-log /dev/null -qmp unix:/tmp/qtest-26256.qmp,nowait -pidfile /tmp/qtest-26256.pid -machine accel=qtest -display none -rtc clock=vm
-
-The problem is that an assertion failure in a test case causes the test program to exit(2) without hitting the qtest cleanup.
-
-I think this has been fixed sometime in the past already. Or can you still reproduce this problem with the latest version of QEMU?
-
-It appears this is fixed, I haven't seen it in a while
-
diff --git a/results/classifier/108/PID/1708551 b/results/classifier/108/PID/1708551
deleted file mode 100644
index 69564041..00000000
--- a/results/classifier/108/PID/1708551
+++ /dev/null
@@ -1,157 +0,0 @@
-PID: 0.955
-permissions: 0.940
-graphic: 0.940
-other: 0.934
-socket: 0.934
-boot: 0.934
-device: 0.929
-performance: 0.928
-network: 0.923
-semantic: 0.918
-files: 0.917
-debug: 0.916
-vnc: 0.899
-KVM: 0.896
-
-macOS Guest Reading USB 3.0 Bus as USB 2.0
-
-Description:
-I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
-
-Parameters:
-QEMU release version: 2.10.0-rc0
-Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
-Command Line: https://pastebin.com/pBSYbrW1
-Host: Arch Linux
-Guest: macOS v10.12.6
-Guest System Info: https://pastebin.com/U1Tihxei
-
-Notes:
-1. Observed sometime after late-May-early-June of this year.
-
-2. Due to [a defect in qemu v2.8 which affected GTK users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent change to macOS' booting process conflicting with qemu v2.9](https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as -rc1 fails to load OVMF right now).
-
-Could you please try to run QEMU without the "-usb" option here? "-usb" automatically creates an EHCI and UHCI controller on the q35 machine, so that might be the reason that your USB devices get connected as USB 2.0 instead.
-
-Doing so returns:
-`qemu-system-x86_64: -device usb-tablet,bus=usb-bus.0: Bus 'usb-bus.0' not found`
-
-> On Aug 4, 2017, at 2:31 AM, Thomas Huth <email address hidden> wrote:
-> 
-> Could you please try to run QEMU without the "-usb" option here? "-usb"
-> automatically creates an EHCI and UHCI controller on the q35 machine, so
-> that might be the reason that your USB devices get connected as USB 2.0
-> instead.
-> 
-> ** Changed in: qemu
->       Status: New => Incomplete
-> 
-> -- 
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1708551
-> 
-> Title:
->  macOS Guest Reading USB 3.0 Bus as USB 2.0
-> 
-> Status in QEMU:
->  Incomplete
-> 
-> Bug description:
->  Description:
->  I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
-> 
->  Parameters:
->  QEMU release version: 2.10.0-rc0
->  Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
->  Command Line: https://pastebin.com/pBSYbrW1
->  Host: Arch Linux
->  Guest: macOS v10.12.6
->  Guest System Info: https://pastebin.com/U1Tihxei
-> 
->  Notes:
->  1. Observed sometime after late-May-early-June of this year.
-> 
->  2. Due to [a defect in qemu v2.8 which affected GTK
->  users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent
->  change to macOS' booting process conflicting with qemu
->  v2.9](https://lists.nongnu.org/archive/html/qemu-
->  devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as
->  -rc1 fails to load OVMF right now).
-> 
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions
-
-
-Then simply omit the "bus=usb-bus.0" here - the devices then should be put onto the XHCI bus automatically.
-
-Removing the `bus=usb-bus.0` param from everything, [as shown here](https://pastebin.com/x0Cp70XD), boots fine; but completely breaks mouse functionality. To mitigate, i tried passing through a Logitech mousepad I own--in similar fashion to the iPhone; but Host complained about permissions & `libusb` requiring "write access to USB device nodes".
-
-FWIW, I vaguely recall the `usb-tablet` parameter being "a whole thing" with virtual macOS; however, I'll need to check my records to refresh my memory.
-
-
-> On Aug 4, 2017, at 11:29 AM, Thomas Huth <email address hidden> wrote:
-> 
-> Then simply omit the "bus=usb-bus.0" here - the devices then should be
-> put onto the XHCI bus automatically.
-> 
-> -- 
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1708551
-> 
-> Title:
->  macOS Guest Reading USB 3.0 Bus as USB 2.0
-> 
-> Status in QEMU:
->  Incomplete
-> 
-> Bug description:
->  Description:
->  I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
-> 
->  Parameters:
->  QEMU release version: 2.10.0-rc0
->  Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
->  Command Line: https://pastebin.com/pBSYbrW1
->  Host: Arch Linux
->  Guest: macOS v10.12.6
->  Guest System Info: https://pastebin.com/U1Tihxei
-> 
->  Notes:
->  1. Observed sometime after late-May-early-June of this year.
-> 
->  2. Due to [a defect in qemu v2.8 which affected GTK
->  users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent
->  change to macOS' booting process conflicting with qemu
->  v2.9](https://lists.nongnu.org/archive/html/qemu-
->  devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as
->  -rc1 fails to load OVMF right now).
-> 
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions
-
-
-Ok, could you maybe try something like this instead:
-
- qemu-system-x86_64 ... -usb \
-    -device qemu-xhci,id=xhci \
-    -device usb-tablet,bus=usb-bus.0 \
-    -device usb-kbd,bus=usb-bus.0 \
-    -device usb-host,bus=xhci.0,vendorid=0x05ac,productid=0x12a8
-
-i.e. use "bus=xhci.0" for the usb-host device?
-
-In doing so, the device is now unseen by the system.
-
-
-xhci doesn't work with macos because macos has a white list of supported xhci controllers and ignores the xhci adapters emulated by qemu.
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/146
-
-
diff --git a/results/classifier/108/PID/1760 b/results/classifier/108/PID/1760
deleted file mode 100644
index 0c290462..00000000
--- a/results/classifier/108/PID/1760
+++ /dev/null
@@ -1,68 +0,0 @@
-PID: 0.966
-performance: 0.934
-graphic: 0.920
-device: 0.909
-files: 0.860
-debug: 0.831
-network: 0.727
-permissions: 0.714
-vnc: 0.615
-socket: 0.609
-boot: 0.551
-KVM: 0.516
-semantic: 0.502
-other: 0.134
-
-qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90)
-Description of problem:
-qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386.
-```
-$ strace ./oldmmap
-execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0
-[ Process PID=405233 runs in 32 bit mode. ]
-mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000
-exit(5)                                 = ?
-+++ exited with 5 +++
-
-$ build/qemu-i386 -strace ./oldmmap
-405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000
-405254 exit(5)
-```
-Steps to reproduce:
-1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S  # build 32-bit executable
-2. strace ./oldmmap  # run under strace
-3. build/qemu-i386 -strace ./oldmmap  # run under "qemu-i386 -strace"
-4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did.
-Additional information:
-```
-$ cat oldmmap.S
-MAP_FIXED=     0x10
-MAP_PRIVATE=   0x02
-MAP_ANONYMOUS= 0x20
-
-PROT_READ=      1
-PROT_WRITE=     2
-PROT_EXEC=      4
-
-_NR_exit = 1
-_NR_mmap = 90  // oldmmap: %ebx -> array of 6 arguments
-
-    .globl _start
-_start:
-    push $0  // offset
-    push $-1  // fd
-    push $MAP_PRIVATE|MAP_ANONYMOUS  // flags
-    push $PROT_READ|PROT_WRITE  // protection
-    push $2<<12  // length
-    push $0  // addr (kernel chooses)
-    mov %esp,%ebx
-    mov $_NR_mmap,%eax
-    int $0x80
-    nop
-
-    mov $5,%ebx
-    mov $_NR_exit,%eax
-    int $0x80
-    hlt
-$ 
-```
diff --git a/results/classifier/108/PID/1821054 b/results/classifier/108/PID/1821054
deleted file mode 100644
index a420fcb6..00000000
--- a/results/classifier/108/PID/1821054
+++ /dev/null
@@ -1,68 +0,0 @@
-PID: 0.959
-other: 0.943
-semantic: 0.914
-graphic: 0.909
-device: 0.904
-performance: 0.894
-permissions: 0.885
-debug: 0.844
-vnc: 0.818
-socket: 0.761
-KVM: 0.722
-boot: 0.699
-network: 0.697
-files: 0.693
-
-qemu segfault error when using pcie to dual pci adapter
-
-All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
-I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
-
-hmm that's a fun board.
-
-It looks like qemu has segfaulted;
-   1) is this a qemu build you built yourself? If so, exactly which version, built on which distro?
-   2) Could you get a backtrace of qemu crashing  - this might be easiest if your distro records core dumps somewhere.
-
-FYI: I was happy to find the board and I'm hopeful to get it working. My goal is to use old hardware to make a retro gaming machine for my girls to play games I used to play growing up.
-
-1)No its the qemu installed with unraid version 6.6.7, which i believe is qemu 3.0
-2)im willing to get any notes, logs, or dumps you wish. I just need to know how to do it.
-
-I don't know anything about unraid unfortunately; so I suggest you go back to their forums and ask how to get the backtrace.
-
-I have requested additional info in the other forum. While I wait on reply there, i will say, since you dont know it well, that Unraid is a disto built on top of slackware. Are there any basic command line commands that i could run to get the output you requested, or something to keep things moving while i wait on additional info from the other forum.
-
-Hi! Did you ever get a backtrace? ... otherwise I think we have to close this ticket due to insufficient data...
-
-No I never did. I reached out to try and get info on how to run or get a backtrack and never heard anything. I finally gave up and ended up selling the computer since I never got it working how I wanted to. 
-
-> On Nov 25, 2020, at 10:20 AM, Thomas Huth <email address hidden> wrote:
-> 
-> Hi! Did you ever get a backtrace? ... otherwise I think we have to close
-> this ticket due to insufficient data...
-> 
-> ** Changed in: qemu
->       Status: New => Incomplete
-> 
-> -- 
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1821054
-> 
-> Title:
->  qemu segfault error when using pcie to dual pci adapter
-> 
-> Status in QEMU:
->  Incomplete
-> 
-> Bug description:
->  All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
->  I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
-> 
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1821054/+subscriptions
-
-
-Ok, thanks for getting back. So I'm closing this now due to insufficient data.
-
diff --git a/results/classifier/108/PID/1857811 b/results/classifier/108/PID/1857811
deleted file mode 100644
index fb20509a..00000000
--- a/results/classifier/108/PID/1857811
+++ /dev/null
@@ -1,204 +0,0 @@
-PID: 0.948
-performance: 0.943
-socket: 0.938
-device: 0.935
-permissions: 0.934
-debug: 0.933
-other: 0.933
-network: 0.920
-files: 0.912
-semantic: 0.907
-graphic: 0.899
-boot: 0.897
-vnc: 0.842
-KVM: 0.816
-
-qemu user static binary seems to lack support for network namespace.
-
-Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message.
-
-Unable to configure loopback interface: Operation not supported
-
-If I disable emerge's network-sandbox which utilizes network namespace, the error disappears.
-
-Could you run qemu unimplemented error trace, by using "export QEMU_LOG=unimp"?
-
-You can also set the QEMU_STRACE="" to see which syscall fails.
-
-I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="".
-
-The interesting part in emerge.log is:
-
-  23473 socket(16,,IPPROTO_IP) = 5
-  23473 bind(5,274886353720,12,0,1,274889671712) = 0
-  23473 sendto(5,275542232672,38,0,274886353960,12) = -1 errno=95 (Operation not supported)
-  23473 close(5) = 0
-  Unable to configure loopback interface: Operation not supported
-
-So you're right 16 is AF_NETLINK
-
-At QEMU level only one function returns  EOPNOTSUPP, the one managing RTM_* operations (RTM_GETLINK, RTM_GETADDR, ...) and it doesn't manage a bunch of them.
-
-Could you provide a step by step example to reproduce the problem?
-
-def _configure_loopback_interface():
-	"""
-	Configure the loopback interface.
-	"""
-
-	# We add some additional addresses to work around odd behavior in glibc's
-	# getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
-	#
-	# For example:
-	#
-	#   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = AI_ADDRCONFIG };
-	#   getaddrinfo("localhost", NULL, &hints, &res);
-	#
-	# This returns no results if there are no non-loopback addresses
-	# configured for a given address family.
-	#
-	# Bug: https://bugs.gentoo.org/690758
-	# Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
-
-	# Avoid importing this module on systems that may not support netlink sockets.
-	from portage.util.netlink import RtNetlink
-
-	try:
-		with RtNetlink() as rtnl:
-			ifindex = rtnl.get_link_ifindex(b'lo')
-			rtnl.set_link_up(ifindex)
-			rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
-			if _has_ipv6():
-				rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
-	except EnvironmentError as e:
-		writemsg("Unable to configure loopback interface: %s\n" % e.strerror, noiselevel=-1)
-
-If I execute _configure_loopback_interface in a qemu-aarch64 chroot, I see the following error.
-
-Unable to configure loopback interface: Operation not supported
-
-https://bugs.gentoo.org/703276 explains the issue.
-
-You can obtain portage source code from https://gentoo.osuosl.org/distfiles/portage-2.3.84.tar.bz2
-
-I've copied the file portage-2.3.84/build/lib.linux-x86_64-3.7/portage/util/netlink.py from portage to my local directory and run the following script:
-
-cat > rtnetlink.py <<EOF
-import socket
-
-__has_ipv6 = None
-
-def _has_ipv6():
-        """
-        Test that both userland and kernel support IPv6, by attempting
-        to create a socket and listen on any unused port of the IPv6
-        ::1 loopback address.
-
-        @rtype: bool
-        @return: True if IPv6 is supported, False otherwise.
-        """
-        global __has_ipv6
-
-        if __has_ipv6 is None:
-                if socket.has_ipv6:
-                        sock = None
-                        try:
-                                # With ipv6.disable=0 and ipv6.disable_ipv6=1, socket creation
-                                # succeeds, but then the bind call fails with this error:
-                                # [Errno 99] Cannot assign requested address.
-                                sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
-                                sock.bind(('::1', 0))
-                        except EnvironmentError:
-                                __has_ipv6 = False
-                        else:
-                                __has_ipv6 = True
-                        finally:
-                                # python2.7 sockets do not support context management protocol
-                                if sock is not None:
-                                        sock.close()
-                else:
-                        __has_ipv6 = False
-
-        return __has_ipv6
-
-def _configure_loopback_interface():
-        """
-        Configure the loopback interface.
-        """
-
-        from netlink import RtNetlink
-        try:
-                with RtNetlink() as rtnl:
-                        ifindex = rtnl.get_link_ifindex(b'lo')
-                        rtnl.set_link_up(ifindex)
-                        rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
-                        if _has_ipv6():
-                                rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
-        except EnvironmentError as e:
-                print("Unable to configure loopback interface: %s\n" % e.strerror)
-
-_configure_loopback_interface()
-EOF
-
-And I have no error in an aarch64/ubunut eoan chroot.
-
-sudo QEMU_STRACE= unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
-...
-675051 socket(PF_NETLINK,,NETLINK_ROUTE) = 3
-675051 bind(3,{nl_family=AF_NETLINK,nl_pid=0,nl_groups=0}, 12) = 0
-675051 sendto(3,274891222784,38,0,274886293096,12) = 38
-...
-
-sudo strace -yyy unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
-
-..
-socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 3<NETLINK:[26260481]>
-bind(3<NETLINK:[26260481]>, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
-sendto(3<NETLINK:[26260481]>, {{len=38, type=0x12 /* NLMSG_??? */, flags=NLM_F_REQUEST, seq=1, pid=0}, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06\x00\x03\x00\x6c\x6f"}, 38, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 38
-...
-
-So I need to know which version you are using (qemu, kernel host).
-
-
-
-qemu-4.0.0
-
-> uname -a
-Linux gentoo 4.19.97-gentoo #3 SMP PREEMPT Mon Feb 10 15:09:44 KST 2020 x86_64 AMD FX(tm)-8300 Eight-Core Processor AuthenticAMD GNU/Linux
-
-Could you run something like "sudo strace -yyy unshare --net chroot ..." with your failing binary to see what returns the host kernel?
-
-Can you rephrase your question? I don't know what to do with your question.
-
-I need the strace result of _configure_loopback_interface in a qemu-aarch64 chroot.
-
-But as strace cannot be started in the chroot you must strace the "chroot" command and its children.
-
-So something like "sudo strace -yyy chroot <your chroot directory> <your test path>"
-
-I just called _configure_loopback_interface in a qemu-aarch64 chroot, and the error is not reproducible with qemu-4.2.0. Has it been fixed?
-
-Yes, it's fixed in v4.2.0, and with the help of your test program I've bisect to the fix:
-
-commit 1645fb5a1e537f85eda744bfa6e9d3dda047ba28
-Author: Shu-Chun Weng <email address hidden>
-Date:   Thu Oct 17 17:19:20 2019 -0700
-
-    Fix unsigned integer underflow in fd-trans.c
-    
-    In any of these `*_for_each_*` functions, the last entry in the buffer (so the
-    "remaining length in the buffer" `len` is equal to the length of the
-    entry `nlmsg_len`/`nla_len`/etc) has size that is not a multiple of the
-    alignment, the aligned lengths `*_ALIGN(*_len)` will be greater than `len`.
-    Since `len` is unsigned (`size_t`), it underflows and the loop will read
-    pass the buffer.
-    
-    This may manifest as random EINVAL or EOPNOTSUPP error on IO or network
-    system calls.
-    
-    Signed-off-by: Shu-Chun Weng <email address hidden>
-    Reviewed-by: Laurent Vivier <email address hidden>
-    Message-Id: <email address hidden>
-    Signed-off-by: Laurent Vivier <email address hidden>
-
-
diff --git a/results/classifier/108/PID/2423 b/results/classifier/108/PID/2423
deleted file mode 100644
index ef57e3b7..00000000
--- a/results/classifier/108/PID/2423
+++ /dev/null
@@ -1,49 +0,0 @@
-PID: 0.960
-performance: 0.877
-graphic: 0.868
-other: 0.796
-device: 0.779
-permissions: 0.701
-semantic: 0.674
-debug: 0.645
-vnc: 0.508
-socket: 0.498
-network: 0.492
-boot: 0.448
-files: 0.386
-KVM: 0.264
-
-`qemu -serial stdio` leaves stdout in non-blocking mode
-Description of problem:
-When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout.
-Steps to reproduce:
-Run the following script:
-
-```
-#!/usr/bin/env bash
-
-qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio &
-PID="$!"
-sleep 5
-kill "$PID"
-wait "$PID"
-echo "EXITING $?"
-
-sleep 5
-seq 1 400000
-```
-
-The seq command will be interrupted prematurely:
-
-```
-...
-5143
-5144
-5145⏎                                                                                                                                                                                                                wResource temporarily unavailable
-write: Resource temporarily unavailable
-write: Resource temporarily unavailable
-```
-
-When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600).
-Additional information:
-Expect a patch from me soon.
diff --git a/results/classifier/108/PID/655 b/results/classifier/108/PID/655
deleted file mode 100644
index 1731ff8d..00000000
--- a/results/classifier/108/PID/655
+++ /dev/null
@@ -1,47 +0,0 @@
-PID: 0.989
-device: 0.968
-files: 0.948
-graphic: 0.942
-semantic: 0.936
-permissions: 0.892
-vnc: 0.884
-performance: 0.868
-network: 0.853
-socket: 0.852
-debug: 0.832
-KVM: 0.828
-other: 0.822
-boot: 0.745
-
-Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
-Description of problem:
-The `java` command fails with the following message:
-
-```console
-$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version
-#
-# A fatal error has been detected by the Java Runtime Environment:
-#
-# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884
-#
-# JRE version: (17.0+35) (build )
-# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed
-# mode, sharing, tiered, compressed oops, compressed class ptrs,
-# serial gc, linux-s390x)
-# Problematic frame:
-# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
-#
-# Core dump will be written. Default location: Core dumps may
-# be processed with "/usr/share/apport/apport %p %s %c %d %P %E"
-# (or dumping to /home/ubuntu/core.2883)
-#
-# An error report file with more information is saved as:
-# /home/ubuntu/hs_err_pid2883.log
-#
-#
-Aborted (core dumped)
-```
-Steps to reproduce:
-1. Run `java --version`
-Additional information:
-The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log).
-- 
cgit 1.4.1