add new classifier result

1 files changed, 103 insertions, 0 deletions

diff --git a/results/classifier/105/semantic/304636 b/results/classifier/105/semantic/304636
new file mode 100644
index 000000000..8659929aa
--- /dev/null
+++ b/results/classifier/105/semantic/304636
@@ -0,0 +1,103 @@
+semantic: 0.870
+other: 0.853
+assembly: 0.839
+graphic: 0.837
+network: 0.833
+device: 0.831
+instruction: 0.826
+mistranslation: 0.801
+socket: 0.759
+vnc: 0.743
+KVM: 0.731
+boot: 0.695
+
+-hda FAT:. limited to 504MBytes
+
+Binary package hint: qemu
+
+The size of the virtual FAT file system (for sharing a particular directory with Guest OS) is hard-coded to be limited to 504MBytes, in block-vvfat.c
+--
+/* 504MB disk*/
+bs->cyls=1024; bs->heads=16; bs->secs=63;
+--
+
+If the directory contents exceeds this is stops with an assert
+--
+qemu: block-vvfat.c:97: array_get: Assertion `index < array->next' failed.
+Aborted
+--
+
+Also the FAT16 mode (default) only uses 8KByte cluster sizes which prevents the above being increased. 16KByte and 32KByte sectors can be selected with the following patch
+--
+--- block-vvfat.c_orig  2008-12-02 12:37:28.000000000 -0700
++++ block-vvfat.c       2008-12-02 19:50:35.000000000 -0700
+@@ -1042,6 +1042,12 @@
+        s->fat_type = 32;
+     } else if (strstr(dirname, ":16:")) {
+        s->fat_type = 16;
++    } else if (strstr(dirname, ":16-16K:")) {
++       s->fat_type = 16;
++       s->sectors_per_cluster=0x20;
++    } else if (strstr(dirname, ":16-32K:")) {
++       s->fat_type = 16;
++       s->sectors_per_cluster=0x40;
+     } else if (strstr(dirname, ":12:")) {
+        s->fat_type = 12;
+        s->sector_count=2880;
+--
+
+Cheers,
+Mungewell
+
+please send your patch to upstream at <email address hidden>, the vvfat code in qemu is fragile and should be carefully reviewed.
+
+the path ever came? i'm still having this problem, i can't run qemu on windows because in the fat: partition there are files bigger then 500 mb
+
+Please submit the patch upstream
+
+Linked against upstream, confirmed and wishlist.  Ubuntu should get this when upstream takes the patch.
+
+Thanks!
+:-Dustin
+
+Thank YOU, dustin!
+What's next? I don't understand, should i do something else or i can just wait for the fix? somebody has to send the patch ?
+Another thing: why wishlist? this is clearly a bug, and a quite serious one: you just can't give a fat bigger than 500 mb to qemu. i can't use qemu since years, because of this...
+Thanks
+
+Hello.
+
+I am using qemu-5.2.0 in Windows with operating system Minix 3.1.2a and vfat fail to write files of size over 4096 bytes. The read works well. This is not ploblem of Minix 3.1.2a because in Bochs emulator reads an writes of files of any size works well.
+
+I also consider this to be a major bug as it prevents communication of information between the guest OS and the host. I have over 300 students complaining about this bug present in qemu.
+
+Thanks.
+
+
+
+Hi Pedro,
+
+Sorry to hear of your difficulty, but given the age of this bug report, I'd strongly urge you to file a new bug report.  Since this was last looked at over 10 years ago, it's extremely likely your issue is completely unrelated to the originally reported one.
+
+Here are a couple pages on how to write effective bug reports, that I'd encourage reading to ensure your report is actionable and can (hopefully) get resolved expediently:
+
+  * https://help.ubuntu.com/community/ReportingBugs
+  * https://ubuntu.com/server/docs/reporting-bugs
+
+A few other tips specific to qemu (per the upstream bug tracker):
+
+  * Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug. Reports against the latest release or even the latest development tree are usually acted upon faster.
+  * Include the full command line used to launch the QEMU guest.
+  * Reproduce the problem directly with a QEMU command-line. Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
+  * Include information about the host and guest (operating system, version, 32/64-bit).
+
+
+Pedro,
+please also note that vvfat driver is general in a bad state and more or less completely unmaintaind. I can only strongly recommend to *not* use it in production. If you have to share files between guest and host, please use something more modern like virtio-fs (or maybe virtio-9p) instead.
+
+If you need OS portability then the "usb-mtp" device is also an option for adhoc file sharing.
+
+This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets now closed in Launchpad. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/66
+