2 files changed, 96 insertions, 0 deletions
diff --git a/results/classifier/108/device/1854 b/results/classifier/108/device/1854
new file mode 100644
index 00000000..bcd6f27b
--- /dev/null
+++ b/results/classifier/108/device/1854
@@ -0,0 +1,33 @@
+device: 0.934
+graphic: 0.892
+files: 0.865
+PID: 0.855
+permissions: 0.661
+vnc: 0.655
+debug: 0.634
+network: 0.626
+semantic: 0.578
+socket: 0.563
+boot: 0.363
+performance: 0.288
+other: 0.127
+KVM: 0.087
+
+s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Description of problem:
+The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 .
+Reverting that commit fixes the issue.
+Steps to reproduce:
+1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below.
+2. Run it under qemu-s390x.
+
+```
+ ./qemu-s390x nolibc-test
+**
+ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Aborted (core dumped)
+
+```
+Additional information:
+
diff --git a/results/classifier/108/device/1854878 b/results/classifier/108/device/1854878
new file mode 100644
index 00000000..250b55b2
--- /dev/null
+++ b/results/classifier/108/device/1854878
@@ -0,0 +1,63 @@
+device: 0.964
+graphic: 0.923
+semantic: 0.751
+performance: 0.734
+other: 0.676
+PID: 0.608
+permissions: 0.568
+files: 0.468
+socket: 0.438
+debug: 0.394
+boot: 0.389
+network: 0.370
+vnc: 0.334
+KVM: 0.281
+
+Physical USB thumbdrive treated as read-only
+
+So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good.
+
+When I run QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1
+
+it of course is read-only, just like the resulting console message says:
+WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+
+
+So what I then did, was I ran QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw
+
+As expected, the above mentioned console message no longer appears.
+However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message:
+Error writing to drive C: DOS area: sector not found.
+
+The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw.
+
+Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive).
+
+And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot
+That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance.
+
+Here's my current setup.
+Host OS: Windows 10 (64bit)
+Guest OS: FreeDOS
+QEMU version: 4.1.0
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+