Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
If a guest virtual machine running the 64-bit Windows 7 operating system was rebooted repeatedly, it sometimes terminated unexpectedly with a blue error screen. This update fixes the race condition in the multi-path implementation that was causing the problem. As a result, 64-bit Windows 7 guests no longer encounter crashes in the described scenario.
Reproduce this bug on virtio-win-1.8.0-4
Verified this bug on virtio-win-prewhql-118
kernel-3.10.0-327.el7.x86_64
qemu-kvm-tools-rhev-2.3.0-1.el7.x86_64
Steps as comment#0
reboot 100 times , not hit BSOD
Above all, this bug has been fixed.
Thanks
Yu Wang
Hi,
cannot reproduce this issue w/ the latest driver on rhel6 host.
version:
virtio-win-1.8.0-1.el6
qemu-kvm-rhev-0.12.1.2-2.495.el6.x86_64
kernel-2.6.32-667.el6.x86_64
seabios-0.6.1.2-30.el6.x86_64
Above all, this bug has been fixed and change status to verified.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2017-0561.html
Description of problem: Repeatedly reboot Win7 64bit guest for several times, then the guest will got BSOD with error 0x0000000A Version-Release number of selected component (if applicable): kernel: kernel-2.6.32-590.el6.x86_64 qemu-kvm: qemu-kvm-rhev-0.12.1.2-2.481.el6.x86_64 virtio-win: virtio-win-1.7.5-0.el6.noarch How reproducible: Steps to Reproduce: 1.boot the guest with cmdline: /usr/libexec/qemu-kvm \ -S \ -name 'virt-tests-vm1' \ -machine rhel6.6.0 \ -nodefaults \ -vga qxl \ -device intel-hda,bus=pci.0,addr=03 \ -device hda-duplex \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20151209-065825-T3wjQOJZ,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20151209-065825-T3wjQOJZ,server,nowait \ -mon chardev=qmp_id_catch_monitor,mode=control \ -device pvpanic,ioport=0x505,id=idHecTH6 \ -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20151209-065825-T3wjQOJZ,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=04 \ -chardev socket,id=devvs,path=/tmp/virtio_port-vs-20151209-065825-T3wjQOJZ,server,nowait \ -device virtserialport,chardev=devvs,name=vs,id=vs,bus=virtio_serial_pci0.0 \ -chardev socket,id=seabioslog_id_20151209-065825-T3wjQOJZ,path=/tmp/seabios-20151209-065825-T3wjQOJZ,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20151209-065825-T3wjQOJZ,iobase=0x402 \ -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=1d.0,firstport=0,bus=pci.0 \ -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=1d.2,firstport=2,bus=pci.0 \ -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=1d.4,firstport=4,bus=pci.0 \ -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=/home/autotest/autotest/client/tests/virt/shared/data/images/win7-64-sp1-virtio.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \ -device virtio-net-pci,mac=9a:b9:ba:bb:bc:bd,id=idt22MFU,vectors=4,netdev=idhRbZSm,bus=pci.0,addr=06 \ -netdev tap,id=idhRbZSm,vhost=on \ -m 4096 \ -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ -cpu 'Westmere',hv_relaxed,hv_relaxed \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file=/home/autotest/autotest/client/tests/virt/shared/data/isos/windows/winutils.iso \ -device ide-drive,id=cd1,drive=drive_cd1,bootindex=1,bus=ide.0,unit=0 \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -spice port=3000,password=123456,addr=0,tls-port=3200,x509-dir=/tmp/spice_x509d,tls-channel=main,tls-channel=inputs,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -monitor stdio \ -vnc :1 \ 2.reboot the guest for several times. Actual results: Guest got BSOD error 0x0000000A Expected results: guest should boot successfully. Additional info: host info: [root@ibm-x3650m3-04 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 2 Core(s) per socket: 6 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 44 Stepping: 2 CPU MHz: 1596.000 BogoMIPS: 4799.99 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 12288K NUMA node0 CPU(s): 0-11 analyze memory.dmp with win_debug: 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0000000017200111, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff800026d87d5, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 0000000017200111 CURRENT_IRQL: 2 FAULTING_IP: nt!KeSetEvent+1e3 fffff800`026d87d5 488b00 mov rax,qword ptr [rax] DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: System ANALYSIS_VERSION: 6.3.9600.16520 (debuggers(dbg).140127-0329) amd64fre DPC_STACK_BASE: FFFFF80000BA2FB0 TRAP_FRAME: fffff80000b9c8a0 -- (.trap 0xfffff80000b9c8a0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000017200111 rbx=0000000000000000 rcx=fffff880037839d8 rdx=fffffa80048c61a0 rsi=0000000000000000 rdi=0000000000000000 rip=fffff800026d87d5 rsp=fffff80000b9ca30 rbp=0000000000000002 r8=0000000000000100 r9=0000000000000000 r10=0000000017200111 r11=0000000000000002 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz ac po cy nt!KeSetEvent+0x1e3: fffff800`026d87d5 488b00 mov rax,qword ptr [rax] ds:00000000`17200111=???????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff800026d3be9 to fffff800026d4640 STACK_TEXT: fffff800`00b9c758 fffff800`026d3be9 : 00000000`0000000a 00000000`17200111 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx fffff800`00b9c760 fffff800`026d2860 : 00000000`00000000 00000000`00000000 00000000`000000fe fffff880`037839d0 : nt!KiBugCheckDispatch+0x69 fffff800`00b9c8a0 fffff800`026d87d5 : fffff880`037839d0 00000000`00000002 00000000`00000000 fffff800`02846e80 : nt!KiPageFault+0x260 fffff800`00b9ca30 fffff880`01717407 : fffff880`00000000 fffffa80`00000000 fffffa80`048c6100 fffffa80`04965200 : nt!KeSetEvent+0x1e3 fffff800`00b9caa0 fffff880`03e43870 : fffffa80`04965200 00000000`00000000 00000000`00000000 fffffa80`04728b00 : ndis!NdisMPauseComplete+0x67 fffff800`00b9cad0 fffff880`03e406d9 : fffffa80`04728bf8 fffffa80`04728b40 fffffa80`04728b00 fffff880`03e3cacb : netkvm+0xc870 fffff800`00b9cb00 fffff880`03e3a1ed : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : netkvm+0x96d9 fffff800`00b9cbb0 fffff880`03e45750 : fffffa80`04965200 00000000`00000000 00000000`00000000 00000000`00000000 : netkvm+0x31ed fffff800`00b9cbe0 fffff880`01689b51 : 00000000`0000028d fffff800`0284a428 fffff800`02846e80 01d1320d`00f09cec : netkvm+0xe750 fffff800`00b9cc40 fffff800`026dfb1c : fffffa80`04976228 fffff800`00000000 00000000`00000000 fffff800`02846e80 : ndis!ndisInterruptDpc+0x151 fffff800`00b9ccd0 fffff800`026cc36a : fffff800`02846e80 fffff800`02854cc0 00000000`00000000 fffff880`01689a00 : nt!KiRetireDpcList+0x1bc fffff800`00b9cd80 00000000`00000000 : fffff800`00b9d000 fffff800`00b97000 fffff800`00b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a STACK_COMMAND: kb FOLLOWUP_IP: netkvm+c870 fffff880`03e43870 4883c420 add rsp,20h SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: netkvm+c870 FOLLOWUP_NAME: MachineOwner MODULE_NAME: netkvm IMAGE_NAME: netkvm.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5600f3af FAILURE_BUCKET_ID: X64_0xA_netkvm+c870 BUCKET_ID: X64_0xA_netkvm+c870 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:x64_0xa_netkvm+c870 FAILURE_ID_HASH: {a0fd52a1-6318-6df3-8a75-2e294a5758ca} Followup: MachineOwner ---------