restructure results

1 files changed, 146 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/108/other/732155 b/results/classifier/zero-shot/108/other/732155
new file mode 100644
index 000000000..2538d7caf
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/732155
@@ -0,0 +1,146 @@
+other: 0.776
+permissions: 0.692
+debug: 0.684
+vnc: 0.684
+device: 0.670
+semantic: 0.657
+KVM: 0.652
+boot: 0.648
+graphic: 0.637
+performance: 0.612
+PID: 0.595
+files: 0.587
+socket: 0.576
+network: 0.516
+
+system_reset doesn't work with qemu-kvm and latest SeaBIOS
+
+I've built qemu-kvm and seabios from the latest git sources, and found that the system_reset monitor command causes a freeze if I start qemu-system-x86_64 with the -no-kvm flag.  This is a serial log from an attempt at rebooting:
+
+$ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -bios ../seabios/out/bios.bin -serial /dev/stdout -no-kvm
+QEMU 0.14.50 monitor - type 'help' for more information
+(qemu) Changing serial settings was 0/0 now 3/0
+Start bios (version pre-0.6.3-20110309_171929-desk4)
+Ram Size=0x08000000 (0x0000000000000000 high)
+CPU Mhz=2202
+PCI: pci_bios_init_bus_rec bus = 0x0
+PIIX3/PIIX4 init: elcr=00 0c
+PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
+PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
+PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
+region 4: 0x0000c000
+PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
+PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
+region 0: 0xf0000000
+region 1: 0xf2000000
+region 6: 0xf2010000
+PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
+region 0: 0x0000c100
+region 1: 0xf2020000
+region 6: 0xf2030000
+Found 1 cpu(s) max supported 1 cpu(s)
+MP table addr=0x000fdb40 MPC table addr=0x000fdb50 size=224
+SMBIOS ptr=0x000fdb20 table=0x07fffef0
+ACPI tables: RSDP=0x000fdaf0 RSDT=0x07ffd6a0
+Scan for VGA option rom
+Running option rom at c000:0003
+Turning on vga text mode console
+SeaBIOS (version pre-0.6.3-20110309_171929-desk4)
+
+PS2 keyboard initialized
+Found 1 lpt ports
+Found 1 serial ports
+ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9)
+ATA controller 1 at 170/374/0 (irq 15 dev 9)
+DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
+Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
+Scan for option roms
+Running option rom at c900:0003
+pnp call arg1=60
+pmm call arg1=0
+pmm call arg1=2
+pmm call arg1=0
+Searching bootorder for: /pci@i0cf8/*@3
+Searching bootorder for: /rom@genroms/vapic.bin
+Running option rom at c980:0003
+ebda moved from 9fc00 to 9f400
+Returned 53248 bytes of ZoneHigh
+e820 map has 6 items:
+  0: 0000000000000000 - 000000000009f400 = 1
+  1: 000000000009f400 - 00000000000a0000 = 2
+  2: 00000000000f0000 - 0000000000100000 = 2
+  3: 0000000000100000 - 0000000007ffd000 = 1
+  4: 0000000007ffd000 - 0000000008000000 = 2
+  5: 00000000fffc0000 - 0000000100000000 = 2
+enter handle_19:
+  NULL
+Booting from DVD/CD...
+Device reports MEDIUM NOT PRESENT
+atapi_is_ready returned -1
+Boot failed: Could not read from CDROM (code 0003)
+enter handle_18:
+  NULL
+Booting from ROM...
+Booting from c900:0336
+
+(qemu) 
+(qemu) system_reset
+(qemu) RESET REQUESTEDChanging serial settings was 0/0 now 3/0
+Start bios (version pre-0.6.3-20110309_171929-desk4)
+Attempting a hard reboot
+prep_reset
+apm_shutdown?
+i8042_reboot
+i8042: wait to write...
+i8042: outb
+RESET REQUESTED
+(qemu) 
+(qemu) 
+(qemu) 
+(qemu) info cpus
+* CPU #0: pc=0x00000000fffffff0 thread_id=18125 
+(qemu) system_reset
+(qemu) RESET REQUESTED
+(qemu) 
+(qemu) q
+
+I've tried fiddling a few build options in SeaBIOS but I'm not sure that's where the issue lies.  The RESET REQUESTED is me adding some extra debug to vl.c:1477 in the clause that tests for a reset request, and the i8042: lines are debug lines from seabios tracing the execution of the reset request.
+
+This may be a bug in SeaBIOS of course, since I can replicate the behaviour on my distro's qemu and kvm packages.  However it seems odd that qemu behaves differently with KVM turned on (i.e. system_reset works) than with it disabled.
+
+A bit of bisection on SeaBIOS shows that commit 244caf86f11f5f65d166d91704f64cb673167abc was the first to exhibit this behaviour.  Arguably a SeaBIOS bug, but I don't know enough about the reset process to judge.
+
+This patch to SeaBIOS seems to fix it, but I still think there's a bug in kvm if it behaves differently with or without the "-no-kvm" flag.
+
+qemu 0.12 and newer reboot of FreeBSD (m0n0wall.vmdk http://m0n0.ch/wall/ ) fails. 
+The Server (IBM xSeries 206), on which i found this "problem", has no kvm support... 
+finally i decided not to use the IBM server [it is awfully slow when booting, although ubuntu server is really fast available ;-))...but sometimes fails to boot...so i don't use it for production].
+
+I ran several tests and here is my expierence when trying to run m0n0wall.vmdk in qemu:
+   everything works fine: system starts and can be configured...
+BUT, when I tell the system to reboot, it shuts down only until the message rebooting appears...nothing more happens...
+   i can kill the Vmachine and restart it from commandline, but this is not very handy...
+
+it worked in qemu 0.9 and BOCHS Bios
+
+it always works with kvm: i need to start it as root (sudo kvm), otherwise it also won't reboot.
+
+I tested it with several versions on servers, with kvm-support: 
+- Ubuntu 10.04 server 32 bit
+- Ubuntu 10.04 server 64 bit
+- Suse 11.4 32 bit
+
+-seabios 0.5: reboot worked with kvm, but didn't work with qemu (without kvm support)
+-seabios 0.6: reboot worked with kvm, but didn't work with qemu (without kvm support)
+
+Hope it helps somebody!
+
+stefan
+
+
+Sounds like this could have been a duplicate bug of https://bugs.launchpad.net/qemu/+bug/643430 ? If so, it should have been fixed in late 2011. Could you check with the latest version of QEMU / Seabios if the problem still persists?
+
+Hi Thomas, thanks for the triage.  I'm a few years past working on this project directly so if it's not affecting anyone else I'd probably just close this bug.
+
+OK, thanks for your response! So let's assume it's the same bug as 643430, i.e. it should be fixed nowadays.
+