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 1037949 - [virtio-win][viostor]guest bsod(9F) when do s4 while guest running iozone
Summary: [virtio-win][viostor]guest bsod(9F) when do s4 while guest running iozone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-04 06:24 UTC by lijin
Modified: 2015-11-24 08:39 UTC (History)
9 users (show)

Fixed In Version: virtio-win-prewhql-89
Doc Type: Bug Fix
Doc Text:
NO_DOCS
Clone Of:
Environment:
Last Closed: 2015-11-24 08:39:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2513 0 normal SHIPPED_LIVE virtio-win bug fix and enhancement update 2015-11-24 13:38:38 UTC

Description lijin 2013-12-04 06:24:36 UTC 
Description of problem:
do S4 while running iozone in win8-64 guest,it will take a long time then guest bsod.

Version-Release number of selected component (if applicable):
    virtio-win-1.6.7-2.el7.noarch
    kernel-3.10.0-53.el7.x86_64
    qemu-kvm-rhev-1.5.3-19.el7.x86_64
    seabios-1.7.2.2-4.el7.x86_64

How reproducible:
2/10

Steps to Reproduce:
1.boot win8-64 guest with:
/usr/libexec/qemu-kvm \
-M pc -m 2G -smp 2,cores=2 \
-drive file=win8-64.qcow3,format=qcow2,media=disk,if=none,cache=none,id=drive-blk,serial=blk1 \
-device virtio-blk-pci,physical_block_size=512,logical_block_size=512,drive=drive-blk,id=ide-blk-pci1,bootindex=1 \
-rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection \
-name win8-64-nic \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-usb -device usb-tablet \
-monitor stdio \
-vnc :1 -vga cirrus \
-fda /usr/share/virtio-win/virtio-win_amd64.vfd \
-netdev tap,id=hostnet1,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet1,id=net1,mac=00:52:12:16:54:48,bus=pci.0 \
-cdrom /usr/share/virtio-win/virtio-win.iso \
-drive file=disk.raw,format=raw,media=disk,if=none,id=drive2,cache=none,serial=blk2 -device virtio-blk-pci,physical_block_size=4096,logical_block_size=512,drive=drive2,id=ide-blk-pci2 \
2.running iozone
  eg:iozone -az -b c:\aaaa -g 4g -y 32k -i 0 -i 1 
3.do s4 on guest

Actual results:
after long time waiting,guest bsod with 9F code.

Expected results:
guest can s4 correctly,no bsod.

Additional info:
This issue happened only twice,cannot reproduce it after that.
I will upload the dump analyse later.
Comment 1 lijin 2013-12-04 06:29:13 UTC 
the first dump windbg analyse:
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa80024a3060, Physical Device Object of the stack
Arg3: fffff801ecb5eb30, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: fffffa8003bbbbc0, The blocked IRP

Debugging Details:
------------------


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  5010ab1f

MODULE_NAME: pci

FAULTING_MODULE: fffff88001368000 pci

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

TAG_NOT_DEFINED_c000000f:  FFFFF801ECB5EFB0

STACK_TEXT:
fffff801`ecb5eaf8 fffff801`ecda941e : 00000000`0000009f 00000000`00000003 fffffa80`024a3060 fffff801`ecb5eb30 : nt!KeBugCheckEx
fffff801`ecb5eb00 fffff801`ecda9451 : fffffa80`02b76860 fffff801`eceb0c20 00000000`00000000 00000000`000000f3 : nt!PopIrpWatchdogBugcheck+0xe2
fffff801`ecb5eb60 fffff801`eccc08b4 : fffffa80`02b76898 00000000`00000000 fffff801`ecb5ee68 00000000`00000000 : nt!PopIrpWatchdog+0x32
fffff801`ecb5ebb0 fffff801`eccc0ed5 : fffff801`ecf11f00 fffff801`ecc8a4f8 fffff801`ecb5ee00 00000000`000000f3 : nt!KiProcessExpiredTimerList+0x214
fffff801`ecb5ecf0 fffff801`eccc0d88 : fffff801`ecf0f180 fffff801`ecf11f80 00000000`00000007 00000000`00017af3 : nt!KiExpireTimerTable+0xa9
fffff801`ecb5ed90 fffff801`eccbae76 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiTimerExpiration+0xc8
fffff801`ecb5ee40 fffff801`eccba745 : 00000000`00000000 fffff801`ecf0f180 fffff880`02f64a10 fffff801`ed3ad580 : nt!KiRetireDpcList+0x1f6
fffff801`ecb5efb0 fffff801`eccba549 : 0000056f`591493c8 fffff801`ecd554c1 00000000`01000010 00000000`00000282 : nt!KxRetireDpcList+0x5
fffff880`02f64950 fffff801`ecd554d5 : 00000000`017a3be9 fffff801`ecc8d523 00000005`37cf5e24 00000001`dc0060f6 : nt!KiDispatchInterruptContinue
fffff880`02f64980 fffff801`ecc8d523 : 00000005`37cf5e24 00000001`dc0060f6 fffff801`ed3ad580 fffff6fc`40019668 : nt!KiDpcInterruptBypass+0x25
fffff880`02f64990 fffff801`ed38cee5 : fffff801`ed37de51 fffff6fb`7e2000c8 fffff6fc`40019668 00000000`00000000 : nt!KiInterruptDispatchLBControl+0x243
fffff880`02f64b28 fffff801`ed37de51 : fffff6fb`7e2000c8 fffff6fc`40019668 00000000`00000000 fffff8a0`0028c140 : hal!HalpPmTimerQueryCounterIoPort+0x5
fffff880`02f64b30 fffff880`03287011 : fffffa80`01961098 00000000`00369e99 fffffa80`01961098 fffffa80`01961010 : hal!KeQueryPerformanceCounter+0x71
fffff880`02f64b60 fffff880`03286f8a : 00000000`00000000 00000000`00369e99 fffffa80`01961098 fffffa80`01961010 : dxgkrnl!BLTQUEUE::IssueCommand+0x21
fffff880`02f64ba0 fffff880`03286f09 : 00000000`00000000 00000000`00000011 00000000`00000000 00000000`00000002 : dxgkrnl!BLTQUEUE::Flush+0x6a
fffff880`02f64bd0 fffff880`03285b1a : fffffa80`035c4920 fffffa80`035c4920 00000000`00000011 00000000`00000000 : dxgkrnl!DXGDODPRESENT::Flush+0x25
fffff880`02f64c00 fffff880`032cd9d9 : fffffa80`035c48d0 fffff880`0c83ea00 00000000`00000000 00000000`00000000 : dxgkrnl!DXGADAPTER::AcquireCoreResourceExclusive+0xe2
fffff880`02f64c50 fffff880`0328b31c : 00000000`00000001 fffffa80`035c48d0 fffff880`032cd500 00000000`00000000 : dxgkrnl!DXGADAPTER::AcquireLocksForStop+0xf5
fffff880`02f64c80 fffff880`0328b23e : 00000000`00000006 fffff880`032cd500 fffff880`0c83ea02 fffff880`032cd500 : dxgkrnl!DXGADAPTER::AcquireCoreSync+0xbc
fffff880`02f64cc0 fffff880`032cd6dd : fffffa80`0c476190 fffffa80`00000000 fffff880`01a7b800 00000000`00000000 : dxgkrnl!DxgkAcquireAdapterCoreSync+0x22
fffff880`02f64cf0 fffff801`ecc3b521 : fffffa80`0c476a10 fffffa80`0c7fe540 00000000`00000080 fffffa80`0c476040 : dxgkrnl!DpiPowerArbiterThread+0x1a9
fffff880`02f64d50 fffff801`ecc79dd6 : fffff801`ecf0f180 fffffa80`0c7fe540 fffffa80`01892b00 fffffa80`018be740 : nt!PspSystemThreadStartup+0x59
fffff880`02f64da0 00000000`00000000 : fffff880`02f65000 fffff880`02f5f000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0x9F_3_QxlWddm_IMAGE_pci.sys

BUCKET_ID:  0x9F_3_QxlWddm_IMAGE_pci.sys

Followup: MachineOwner
---------
Comment 2 lijin 2013-12-04 06:31:12 UTC 
the second dump windbg analyse:
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa80024b1060, Physical Device Object of the stack
Arg3: fffff8039cc78920, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: fffffa8003b8ce10, The blocked IRP

Debugging Details:
------------------


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  5010ab1f

MODULE_NAME: pci

FAULTING_MODULE: fffff880012be000 pci

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

TAG_NOT_DEFINED_c000000f:  FFFFF8039CC7EFB0

STACK_TEXT:
fffff803`9cc788e8 fffff803`9cf9e41e : 00000000`0000009f 00000000`00000003 fffffa80`024b1060 fffff803`9cc78920 : nt!KeBugCheckEx
fffff803`9cc788f0 fffff803`9cf9e451 : fffffa80`040b9230 fffff803`9cc78958 00000000`00000000 fffffa80`02dce060 : nt!PopIrpWatchdogBugcheck+0xe2
fffff803`9cc78950 fffff803`9ceb58b4 : fffffa80`040b9268 fffff803`00001000 fffff803`9cc78c58 00000000`00000f45 : nt!PopIrpWatchdog+0x32
fffff803`9cc789a0 fffff803`9ceb5ed5 : fffffa80`02d02010 fffff803`9ce7f4f8 fffff803`9cc78bf0 00000000`000000ac : nt!KiProcessExpiredTimerList+0x214
fffff803`9cc78ae0 fffff803`9ceb5d88 : fffff803`9d104180 fffff803`9d106f80 00000000`00000002 00000000`0000ce94 : nt!KiExpireTimerTable+0xa9
fffff803`9cc78b80 fffff803`9ceafe76 : fffffa80`02d02010 00000000`ffffffff fffffa80`02d022e8 00000000`00000000 : nt!KiTimerExpiration+0xc8
fffff803`9cc78c30 fffff803`9ceb457a : fffff803`9d104180 fffff803`9d104180 00000000`00183de0 fffff803`9d15e880 : nt!KiRetireDpcList+0x1f6
fffff803`9cc78da0 00000000`00000000 : fffff803`9cc79000 fffff803`9cc73000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWFAILURE_BUCKET_ID:  0x9F_3_E1G6032E_IMAGE_pci.sys

BUCKET_ID:  0x9F_3_E1G6032E_IMAGE_pci.sys

Followup: MachineOwner
Comment 6 Vadim Rozenfeld 2014-07-04 10:25:14 UTC 
(In reply to lijin from comment #3)
> the dump files located in
> \\smamit.eng.lab.tlv.redhat.com\win-team\Public\QE\bug1037949
> 
> It's seems this bug is similar to
> https://bugzilla.redhat.com/show_bug.cgi?id=869116,does the seabios patch in
> rhel6 merged into rhel7?

yes, there were two different driver failing - qxl and nic. I don't know if rehl6 bios changes were merged to rhel 7 or not, but we can try retesting this issue with the bios from rhel6 or upstream.

Thanks,
Vadim.
Comment 7 Ronen Hod 2014-08-07 08:06:34 UTC 
QE, see comment 6
Comment 8 Mike Cao 2014-08-13 03:06:33 UTC 
lijin ,pls retest following scenario with latest virtio-win-prewhql build 
1.retest it w/ latest seabios on RHEL7
2.retest it w/ upstream seabios.
git clone git://git.seabios.org/seabios.git seabios
Comment 9 lijin 2014-08-14 05:20:56 UTC 
(In reply to Mike Cao from comment #8)
> lijin ,pls retest following scenario with latest virtio-win-prewhql build 
> 1.retest it w/ latest seabios on RHEL7
> 2.retest it w/ upstream seabios.
> git clone git://git.seabios.org/seabios.git seabios

retest with these scenarios with build 89 5 times,guest can do s4 and resume correctly.

package info:
qemu-kvm-rhev-1.5.3-60.el7ev_0.5.x86_64
kernel-3.10.0-133.el7.x86_64
virtio-win-prewhql-89
Comment 10 Vadim Rozenfeld 2014-11-03 08:22:53 UTC 
Based on c#9, closing this bug as fixed.
Comment 11 Mike Cao 2014-11-03 09:42:59 UTC 
build 89 or later build  is not shipped via RHN ,pls keep it open
Comment 12 Mike Cao 2014-11-03 09:43:44 UTC 
Move to Verified according to Comment #9
Comment 16 errata-xmlrpc 2015-11-24 08:39:22 UTC 
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-2015-2513.html
Note You need to log in before you can comment on or make changes to this bug.