Bug 1129549
| Summary: | seabios will lost some bootable device after "sendkey ctrl-alt-delete" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jun Li <juli> | ||||||
| Component: | seabios | Assignee: | Gerd Hoffmann <kraxel> | ||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Severity: | low | Docs Contact: | Jiri Herrmann <jherrman> | ||||||
| Priority: | low | ||||||||
| Version: | 6.6 | CC: | chayang, juzhang, michen, mkenneth, qzhang, rbalakri, rpacheco, virt-bugs, virt-maint, xfu | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Windows | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||
| Doc Text: |
Soft-rebooted Windows guests cannot detect some of their bootable devices
Under certain circumstances, soft-rebooting a Windows guest (for example by using the Ctrl+Alt+Del keys) causes the guest not to detect some of its bootable devices. To work around this problem, perform a hard reboot of the guest - for example by the Shutdown button in the virt-manager interface, or by the "system_reset" command in the QEMU monitor console.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-01-15 16:24:46 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jun Li
2014-08-13 07:32:03 UTC
Created attachment 926295 [details]
Before "sendkey ctrl-alt-delete"
Created attachment 926296 [details]
After "sendkey ctrl-alt-delete"
Retest this issue with linux guest, do not hit this issue. Version of components: seabios-0.6.1.2-29.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.457.el6.x86_64 Guest: RHEL-Server-6.6-64 Cli and steps are the same with comment 0. cli: # /usr/libexec/qemu-kvm -name test -machine rhel6.6.0,dump-guest-core=off -cpu SandyBridge,hv_relaxed,enforce -enable-kvm -m 4024 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid b123c5df-d85b-2ce9-5e93-926f4f4ce03b -nodefconfig -nodefaults -rtc base=utc -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/mnt/RHEL-Server-6.6-64-virtio.qcow2,snapshot=on,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device ide-drive,bus=ide.1,unit=1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=24:BE:05:0C:11:18,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5901,addr=0.0.0.0,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on -drive file=/usr/share/virtio-win/virtio-win.iso,id=nic-package,if=none,media=cdrom -device ide-drive,drive=nic-package,id=sys-nic-package,bus=ide.0,unit=1 -drive file=/home/en_windows_8_enterprise_x86_dvd_917587.iso,id=other-driver,if=none,media=cdrom -device ide-drive,drive=other-driver,id=sys-other-driver,bus=ide.0,unit=0 -monitor stdio -qmp tcp::8888,server,nowait -drive file=/home/data-disk.qcow2,if=none,id=data-disk,format=qcow2 -device ide-drive,drive=data-disk,id=sys-data-disk,bus=ide.1,unit=0 -fda /home//file.vfd -drive file=/home/test.img,if=none,id=drive-fdc0-0-0,readonly=on,format=raw -global isa-fdc.driveA=drive-fdc0-0-0 -boot menu=on Hi Amos, QE has tested with linux guest, do not hit this issue. Any further testing needed, free to update it in the comment. Thx. Best Regards, Jun Li Also re-test with win8-32 guest using comment 5 component, hit comment 0's issue, too. Version of component: seabios-0.6.1.2-29.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.457.el6.x86_64 Guest: win8-32 ==================== QE also tests this issue on rhel7, don't hit this issue. Version of components: seabios-1.7.5-8.el7.x86_64 qemu-kvm-rhev-2.2.0-5.el7.x86_64 Guest: win8-32 The following patches fixed the problem in rel-0.6.2 of seabios upstream.
commit 244caf86f11f5f65d166d91704f64cb673167abc (key fixing)
Author: Kevin O'Connor <kevin>
Date: Wed Sep 15 21:48:16 2010 -0400
Try to hard-reboot on rerun of post even on emulators.
Extend the hard-reboot logic to qemu and kvm. On qemu, a reboot will
not reset the memory settings for 0xc0000-0xfffff, so copy that memory
area manually before rebooting. Unfortunately, kvm does not keep a
pristine copy of the BIOS at 0xffff0000, so detect that case and
shutdown the machine.
commit 5bd01de26257849f36d361018c3ec17aa29b0218
Author: Kevin O'Connor <kevin>
Date: Mon Sep 13 21:19:27 2010 -0400
Don't do shadow copying of optionroms when CONFIG_OPTIONROMS_DEPLOYED.
When CONFIG_OPTIONROMS_DEPLOYED is set, there is no need to copy the
0xc0000-0xf0000 space around - SeaBIOS ignores what's there when it
that mode.
commit adaf373bae943b8ab516a4e2c1ddf1e9b58cc050
Author: Kevin O'Connor <kevin>
Date: Mon Sep 13 20:22:07 2010 -0400
Try to hard-reboot processor on rerun of post under coreboot.
Add several methods for rebooting a processor.
Detect a rerun of POST under coreboot and attempt to reboot the
processor.
The shutdown doesn't occur with upstream qemu, so we need to backport some fix of qemu. Looks like this issue is being discussed upstream and different fixes are being proposed. Reverting the BZ back to ASSIGNED. (In reply to Amos Kong from comment #15) > The shutdown doesn't occur with upstream qemu, so we need to backport some > fix of qemu. Well, "some fix" is the memory api (which allows to correctly emulate the chipset settings for the 0xa0000 -> 0xfffff area). That is _way_ to invasive to be backported to RHEL-6. So, backporting the patches mentioned in comment 7 is out. Unfortunately there is no other easy way to handle this. Invoking a reset is the only way to bring the hardware into a known state. And that is needed for reliable hardware detection, otherwise the hardware initialization can trip up due to hardware being in some odd/unexpected state. Which most likely is the reason for the ide drives disappearing here. Why has this high priority? |