diff options
Diffstat (limited to 'results/classifier/118/none/732155')
| -rw-r--r-- | results/classifier/118/none/732155 | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/results/classifier/118/none/732155 b/results/classifier/118/none/732155 new file mode 100644 index 000000000..aa682c687 --- /dev/null +++ b/results/classifier/118/none/732155 @@ -0,0 +1,161 @@ +user-level: 0.771 +risc-v: 0.754 +VMM: 0.738 +mistranslation: 0.724 +virtual: 0.699 +permissions: 0.692 +debug: 0.684 +vnc: 0.684 +hypervisor: 0.682 +ppc: 0.679 +device: 0.670 +TCG: 0.667 +semantic: 0.657 +KVM: 0.652 +boot: 0.648 +peripherals: 0.645 +graphic: 0.637 +x86: 0.634 +register: 0.630 +architecture: 0.614 +arm: 0.614 +performance: 0.612 +PID: 0.595 +i386: 0.593 +assembly: 0.593 +files: 0.587 +socket: 0.576 +kernel: 0.545 +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. + |