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.
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-2016-2609.html
Description of problem: Version-Release number of selected component (if applicable): virtio-win-prewhql-105 qemu-kvm-rhev-2.3.0-2.el7.x86_64 kernel-3.10.0-267.el7.x86_64 seabios-1.7.5-9.el7.x86_64 win10:build 10162 win2016:en_windows_server_technical_preview_2_x64_dvd_6687981.iso hlk: How reproducible: 100% Steps to Reproduce: 1.boot guest with: /usr/libexec/qemu-kvm -name 105SCSW10S64L4K -enable-kvm -m 6G -smp 8 -uuid 8fe168b6-4486-4641-9dd0-18f90b2b1804 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/105SCSW10S64L4K,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=105SCSW10S64L4K,if=none,id=drive-ide0-0-0,format=raw,serial=mike_cao,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=en_windows_server_technical_preview_2_x64_dvd_6687981.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=105SCSW10S64L4K.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:52:6e:48:cd:99,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus -cpu Nehalem,+fsgsbase -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 -drive file=105SCSW10S64L4K_test.raw,if=none,id=drive-scsi-disk0,format=raw,serial=mike_cao,cache=none -device scsi-hd,bus=scsi0.0,drive=drive-scsi-disk0,id=scsi-disk0 2.submit job in hlk Actual results: guest bsod with D1 Expected results: job can pass,no bsod Additional info: windbg info: 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) 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 kernel debugger is available get stack backtrace. Arguments: Arg1: 000000000000001c, memory referenced Arg2: 000000000000000a, IRQL Arg3: 0000000000000000, value 0 = read operation, 1 = write operation Arg4: fffff801fe92211a, address which referenced memory Debugging Details: ------------------ ADDITIONAL_DEBUG_TEXT: MODULE_NAME: vioscsi FAULTING_MODULE: fffff80034075000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 556eddd9 READ_ADDRESS: unable to get nt!MmSpecialPoolStart unable to get nt!MmSpecialPoolEnd unable to get nt!MmPagedPoolEnd unable to get nt!MmNonPagedPoolStart unable to get nt!MmSizeOfNonPagedPoolInBytes 000000000000001c CURRENT_IRQL: 0 FAULTING_IP: vioscsi+211a fffff801`fe92211a 448b4e1c mov r9d,dword ptr [rsi+1Ch] DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre LAST_CONTROL_TRANSFER: from fffff800341b5da9 to fffff800341ab3e0 STACK_TEXT: ffffd000`82c34688 fffff800`341b5da9 : 00000000`0000000a 00000000`0000001c 00000000`0000000a 00000000`00000000 : nt!KeBugCheckEx ffffd000`82c34690 fffff800`341b45c8 : 00000000`00000010 00000000`00000295 ffff054a`d008c273 fffff800`3419a81d : nt!setjmpex+0x3b59 ffffd000`82c347d0 fffff801`fe92211a : 00000000`00000000 00000000`00000000 00000000`00000000 ffffe001`795b2020 : nt!setjmpex+0x2378 ffffd000`82c34960 fffff801`fe623c97 : ffffe001`00000d80 ffffe001`795b91a0 ffffe001`795b29de ffffe001`795b2020 : vioscsi+0x211a ffffd000`82c349b0 fffff801`fe921c92 : ffffe001`795b2020 ffffe001`795b29de 00000000`00000000 ffffd000`82138000 : storport!StorPortSynchronizeAccess+0x57 ffffd000`82c349e0 fffff801`ff3a1bca : ffffe001`00003f99 ffffe001`795ab110 00000000`00000000 00000000`00000000 : vioscsi+0x1c92 ffffd000`82c34a10 fffff801`ff3a4f55 : 01d0bb06`7180a001 ffffe001`795af5c0 00000000`00000000 fffff800`34795299 : CoreTestShim+0x1bca ffffd000`82c34a40 fffff801`fe61d777 : 01d0bb06`7180a0ef ffffd000`82c34b70 00000000`c0000185 ffffd000`82c34b59 : CoreTestShim+0x4f55 ffffd000`82c34a70 fffff801`fe631bcf : ffffe001`784211b0 ffffe001`784211b0 ffffe001`784211b0 00000000`0000000f : storport!StorPortGetSrb+0xaf27 ffffd000`82c34bc0 fffff801`fe630d26 : ffffcf80`43cb0fa0 ffffcf80`43cb0fa0 ffffcf80`43cb0fa0 fffff800`343ab140 : storport!StorPortWriteRegisterUshort+0xdd2f ffffd000`82c34bf0 fffff800`34112e04 : ffffcf80`43cb0fa0 00000000`00000000 ffffe001`78421060 00000000`00000000 : storport!StorPortWriteRegisterUshort+0xce86 ffffd000`82c34c40 fffff800`341124d9 : fffff800`34444480 ffffe001`79b2a840 fffff800`34112d10 fffff800`34444480 : nt!KeIsAttachedProcess+0x114 ffffd000`82c34cb0 fffff800`340ff1ec : 00000000`00000000 00000000`00000080 fffff800`34444480 ffffe001`79b2a840 : nt!NtTraceEvent+0x11a9 ffffd000`82c34d40 fffff800`341b04c6 : ffffd000`861c1180 ffffe001`79b2a840 ffffe001`784f7040 ffffd000`82c34e49 : nt!KeInitializeDpc+0x1850 ffffd000`82c34da0 00000000`00000000 : ffffd000`82c35000 ffffd000`82c2f000 00000000`00000000 00000000`00000000 : nt!KeSynchronizeExecution+0x4496 STACK_COMMAND: kb FOLLOWUP_IP: vioscsi+211a fffff801`fe92211a 448b4e1c mov r9d,dword ptr [rsi+1Ch] SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: vioscsi+211a FOLLOWUP_NAME: MachineOwner IMAGE_NAME: vioscsi.sys BUCKET_ID: WRONG_SYMBOLS FAILURE_BUCKET_ID: WRONG_SYMBOLS ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:wrong_symbols FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8} Followup: MachineOwner ---------