add 18th iteration of classifier

1 files changed, 55 insertions, 0 deletions

diff --git a/results/classifier/118/none/1013691 b/results/classifier/118/none/1013691
new file mode 100644
index 000000000..b064825dc
--- /dev/null
+++ b/results/classifier/118/none/1013691
@@ -0,0 +1,55 @@
+ppc: 0.782
+graphic: 0.587
+device: 0.549
+user-level: 0.445
+semantic: 0.443
+kernel: 0.354
+mistranslation: 0.353
+performance: 0.315
+architecture: 0.279
+network: 0.266
+PID: 0.249
+socket: 0.248
+boot: 0.232
+peripherals: 0.224
+permissions: 0.213
+risc-v: 0.208
+vnc: 0.205
+register: 0.192
+debug: 0.189
+hypervisor: 0.186
+virtual: 0.165
+arm: 0.154
+i386: 0.130
+x86: 0.126
+TCG: 0.110
+files: 0.104
+VMM: 0.103
+KVM: 0.056
+assembly: 0.049
+
+ppc64 + virtio-scsi: only first scsi disk shows up in the guest
+
+When adding two virtio-scsi targets to a single guest, only the first
+disk is seen inside the guest.  For some unknown reason the guest
+doesn't enumerate the second disk.
+
+For full qemu-system-ppc64 command line and 'dmesg' output, see:
+
+http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02430.html
+
+I have also tried this with Linus's git tree (3.5.0-rc2+ at time of writing),
+same thing.
+
+In both cases I'm using qemu from git.
+
+Can you test whether the spapr-vscsi controller works instead?
+
+Yes, that works fine, both disks seen by the guest.
+
+Only just saw this bug, I assume the problem still exist ? I have somebody look at it next week
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and guest kernel? Or could we close this ticket nowadays?
+
+Closed it, very old bug and we successfully test many disks with ppc64/le nowadays.
+