RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 596590 - BSOD happens while Windows7 booting
Summary: BSOD happens while Windows7 booting
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Gleb Natapov
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 603459 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-27 03:42 UTC by Cao, Chen
Modified: 2013-12-09 00:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-13 11:38:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screen dump (8.66 KB, image/png)
2010-05-27 03:42 UTC, Cao, Chen
no flags Details

Description Cao, Chen 2010-05-27 03:42:28 UTC
Created attachment 417109 [details]
screen dump

Description of problem:
while booting Win7 guest, a recovering screen shows, and blue screen will
happen no matter we choose "Launch startup repair (recommanded)" or
"start Windows normally".


Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.64.el6.x86_64


How reproducible:
100% on my machine


Steps to Reproduce:
1. start Windows 7 guest using command:
/root/autotest/client/tests/kvm/qemu -name 'vm1' -monitor stdio -drive file=/root/autotest/client/tests/kvm/images/win7-64-virtio.qcow2,if=virtio,cache=none,boot=on -net nic,vlan=0,model=e1000,macaddr=02:27:1D:8E:f0:7d -net tap,vlan=0,ifname=e1000_0_6001,script=/root/autotest/client/tests/kvm/scripts/qemu-ifup-switch,downscript=no -m 512 -smp 1 -drive file=/root/autotest/client/tests/kvm/isos/windows/winutils.iso,index=2,media=cdrom  -usbdevice tablet -rtc-td-hack -no-hpet -cpu qemu64,+sse2 -no-kvm-pit-reinjection -redir tcp:5000::22 -vnc :0
2. vncviewer 10.66.91.198:0
3. after Windows starts to boot, BSOD happens.
  

Actual results:
Guest Windows failed to startup with BSOD


Expected results:
Guest Windows normally without failures.


Additional info:
0. NOTE: with the same packages installed, I can only reproduce this problem on the dell 780 machines, but no problems found on some other machines, e.g. dell 755.

1. qemu packages:
[root@dhcp-91-198 results]# rpm -qa |grep qemu
qemu-img-0.12.1.2-2.64.el6.x86_64
qemu-kvm-0.12.1.2-2.64.el6.x86_64
gpxe-roms-qemu-0.9.7-6.3.el6.noarch
qemu-kvm-tools-0.12.1.2-2.64.el6.x86_64

2. kernel info:
[root@dhcp-91-198 results]# uname -a
Linux dhcp-91-198.nay.redhat.com 2.6.32-22.el6.x86_64 #1 SMP Tue Apr
20 12:10:42 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

3. cpuinfo:
[root@dhcp-91-198 debug]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz
stepping	: 10
cpu MHz		: 2659.984
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 5319.96
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz
stepping	: 10
cpu MHz		: 2659.984
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz
stepping	: 10
cpu MHz		: 2659.984
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 5319.72
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz
stepping	: 10
cpu MHz		: 2659.984
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 5319.74
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 3 Amit Shah 2010-05-28 11:39:09 UTC
Does this problem happen without virtio block device?

This looks like a bios bug.

Comment 4 RHEL Program Management 2010-05-28 11:55:45 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 5 Gleb Natapov 2010-05-28 11:59:16 UTC
Stop error 7B usually means inaccessible boot device. Does this Windows image has virtio block driver installed? And what is seabios version on you machine.

Comment 6 RHEL Program Management 2010-05-28 12:15:29 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 7 Cao, Chen 2010-05-31 09:32:45 UTC
(In reply to comment #5)
> Stop error 7B usually means inaccessible boot device. Does this Windows image
> has virtio block driver installed? And what is seabios version on you machine.    

yes, the virtio block driver is installed, since we can boot the same image
using the same command on other machines.


[root@dhcp-91-198 kvm]# rpm -qa |grep bios
vgabios-0.6b-3.4.el6.noarch
seabios-0.5.1-0.9.20100108git669c991.el6.x86_64


and we found that if the seabios version is
seabios-0.5.1-0.5.20100108git669c991.el6,
there is not problem of booting.

Comment 8 Gleb Natapov 2010-05-31 09:43:56 UTC
Then it is dup of 596881.

*** This bug has been marked as a duplicate of bug 596881 ***

Comment 9 Eduardo Habkost 2010-06-11 14:20:13 UTC
Reopening, see bug 596881 comment 7:

> Suqin Huang 2010-06-11 02:16:27 EDT
> windows BSOD reproduce in seabios-0.5.1-0.11.20100108git669c991.el6.x86_64
> 
> qemu-kvm-0.12.1.2-2.71.el6.x86_64
> 2.6.32-33.el6.x86_64

Comment 10 Gleb Natapov 2010-06-13 08:04:59 UTC
I cannot reproduce that. Installed viostor driver from http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/virtio-win-1.1.5-0.vfd on pre-existing windowns7 image. Change disk type to virtio on next boot. Boot succeeds. Some notes on you command line (should not change anything but still): boot=on is not needed with seabios-0.5.1-0.11.20100108git669c991.el6.x86_64. You shouldn't use e1000 nic with windows, we do not support that.

Comment 11 Cao, Chen 2010-06-13 09:25:40 UTC
(In reply to comment #10)
> I cannot reproduce that. Installed viostor driver from
> http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/virtio-win-1.1.5-0.vfd
> on pre-existing windowns7 image. Change disk type to virtio on next boot. Boot
> succeeds. Some notes on you command line (should not change anything but
> still): boot=on is not needed with
> seabios-0.5.1-0.11.20100108git669c991.el6.x86_64. You shouldn't use e1000 nic
> with windows, we do not support that.    

I have verified that there is no problem after updating the block virtio driver.

Comment 12 Eduardo Habkost 2010-06-23 17:00:48 UTC
*** Bug 603459 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.