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 592839 - [WHQL] BSOD occurs during Device Path Exerciser test for virtio balloon on winxp
Summary: [WHQL] BSOD occurs during Device Path Exerciser test for virtio balloon on winxp
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virtio-win
Version: 6.0
Hardware: All
OS: Windows
low
medium
Target Milestone: rc
: ---
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-17 07:08 UTC by Shirley Zhou
Modified: 2015-03-05 00:51 UTC (History)
4 users (show)

Fixed In Version: mm21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 15:01:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
dump analyze (6.00 KB, text/plain)
2010-05-17 07:17 UTC, Shirley Zhou
no flags Details

Description Shirley Zhou 2010-05-17 07:08:36 UTC
Description of problem:
BSOD happens during virtio Ballon driver Device Path Exerciser testing

Version-Release number of selected component (if applicable):
kernel-2.6.32-24.el6.x86_64
Driver from: http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.0-0/
Driver version:6.1.7600.16385

How reproducible:
always

Steps to Reproduce:
1.Install virtio balloon driver from
http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.0-0/
2.Run whql unclassified Device Path Exerciser for winxp


Actual results:
BSOD happens,please see attached dump analyse file for reference.

Expected results:
Pass

Additional info:
Command line:
/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -name winxp-balloon -m 2G -smp 2 -drive file=/home/winxp-32.img,if=ide -net nic,vlan=0,macaddr=00:32:22:45:66:22,model=rtl8139 -net tap,vlan=0,script=/etc/qemu-ifup -uuid 09876ac2-8507-4199-8096-eec278782ae4 -cpu qemu64,+sse2 -balloon virtio -vnc :3 -cdrom /home/WindowsXP-32.iso -vga std

Comment 1 Shirley Zhou 2010-05-17 07:17:09 UTC
Created attachment 414467 [details]
dump analyze

You can get dump file at:ftp://10.66.65.200/pub/WHQL/winxp-balloon_device/.

Comment 3 RHEL Program Management 2010-06-07 15:54:33 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 4 Vadim Rozenfeld 2010-06-21 08:41:39 UTC
ftp://10.66.65.200/pub/WHQL/winxp-balloon_device/
Is it still available?
Anyway, if sill happens with the latest balloon driver from http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/
I would like to see the crash dump file.

Thanks,
Vadim.

Comment 5 Qunfang Zhang 2010-06-23 08:22:46 UTC
(In reply to comment #4)
> ftp://10.66.65.200/pub/WHQL/winxp-balloon_device/
> Is it still available?
> Anyway, if sill happens with the latest balloon driver from
> http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/
> I would like to see the crash dump file.
> 
> Thanks,
> Vadim.    

It still happens with http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/. dump file:
ftp://10.66.91.127/pub/WHQL/MEMORY.DMP

Comment 6 Vadim Rozenfeld 2010-06-23 09:19:55 UTC
Thanks,
But it looks like a crash in ataport (storage) stack, not in balloon.
Are you sure that it is the correct dump file?

Btw, was the balloon inflated or deflated at the time of testing?

Thanks again,
Vadim.

Executable search path is: 

Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7600.16539.x86fre.win7_gdr.100226-1909

Machine Name:

Kernel base = 0x8263d000 PsLoadedModuleList = 0x82785810

Debug session time: Tue Jun 22 06:58:49.278 2010 (GMT+3)

System Uptime: 0 days 0:01:49.093

Loading Kernel Symbols

...............................................................

................................................................

......

Loading User Symbols



Loading unloaded module list

.....

1: kd> .reload

Loading Kernel Symbols

...............................................................

................................................................

......

Loading User Symbols



Loading unloaded module list

.....

1: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************



KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)

This is a very common bugcheck.  Usually the exception address pinpoints

the driver/function that caused the problem.  Always note this address

as well as the link date of the driver/image that contains this address.

Some common problems are exception code 0x80000003.  This means a hard

coded breakpoint or assertion was hit, but this system was booted

/NODEBUG.  This is not supposed to happen as developers should never have

hardcoded breakpoints in retail code, but ...

If this happens, make sure a debugger gets connected, and the

system is booted /DEBUG.  This will let us see why this breakpoint is

happening.

Arguments:

Arg1: c0000005, The exception code that was not handled

Arg2: 8267c414, The address that the exception occurred at

Arg3: 90ed374c, Trap Frame

Arg4: 00000000



Debugging Details:

------------------





EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".



FAULTING_IP: 

nt!KeSynchronizeExecution+14

8267c414 f00fba2b00      lock bts dword ptr [ebx],0



TRAP_FRAME:  90ed374c -- (.trap 0xffffffff90ed374c)

ErrCode = 00000002

eax=00000000 ebx=00000000 ecx=8bd9ef00 edx=871c07e0 esi=871c07e0 edi=89b6e6e8

eip=8267c414 esp=90ed37c0 ebp=90ed37d8 iopl=0         nv up ei pl zr na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246

nt!KeSynchronizeExecution+0x14:

8267c414 f00fba2b00      lock bts dword ptr [ebx],0   ds:0023:00000000=????????

Resetting default scope



DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO



BUGCHECK_STR:  0x8E



PROCESS_NAME:  System



CURRENT_IRQL:  0



LAST_CONTROL_TRANSFER:  from 826fa382 to 82719d10



STACK_TEXT:  

90ed32b4 826fa382 0000008e c0000005 8267c414 nt!KeBugCheckEx+0x1e

90ed36dc 82681036 90ed36f8 00000000 90ed374c nt!KiDispatchException+0x1ac

90ed3744 82680fea 90ed37d8 8267c414 badb0d00 nt!CommonDispatchException+0x4a

90ed37c4 849c6ea9 89b70a80 849c69f0 871c07e0 nt!KiExceptionExit+0x192

90ed37d8 849c7147 89b670e0 849c69f0 871c07e0 ataport!IdeSynchronizeExecution+0x23

90ed3804 84991074 871c07e0 90ed383c 8260aa2e ataport!IdeStartIoCallBack+0xbb

90ed3810 8260aa2e 89b5c658 00000000 871c083c PCIIDEX!BmReceiveScatterGatherList+0x1e

90ed383c 84991199 871c083c 89b5c658 914f16a0 hal!HalBuildScatterGatherList+0x1ba

90ed3878 849c6b46 89b5c710 871c07e0 871c0701 PCIIDEX!BmSetup+0x3d

90ed3894 849c7041 89b670e0 871c0701 871c07e0 ataport!IdePortSetupScatterGatherList+0x2a

90ed38ac 849c5a12 89b670e0 871c07e0 89b6e6e8 ataport!IdeDispatchChannelRequest+0x59

90ed38c4 849c5de3 89b670e0 871c07e0 8b826604 ataport!IdeStartChannelRequest+0x42

90ed38e8 849c6fa8 00b6e6e8 001c07e0 8f7cf750 ataport!IdeStartDeviceRequest+0x15d

90ed3908 849c346b 00000103 8bd9ef48 90ed393c ataport!IdePortPdoDispatch+0x9a

90ed3918 8296c6c3 89b6e630 8bd9ef48 8a040848 ataport!IdePortDispatch+0x1d

90ed393c 82679473 00000000 8b826558 89b6e630 nt!IovCallDriver+0x258

90ed3950 84c045a4 86a16e28 8b826558 90ed39a0 nt!IofCallDriver+0x1b

90ed3960 84c03fe8 89b6e630 8a03f0e8 8a040008 CLASSPNP!SubmitTransferPacket+0x103

90ed39a0 84c04303 00000000 00a16e28 8a13a1a8 CLASSPNP!ServiceTransferRequest+0x225

90ed39c8 84c043bf 8a03f030 00000000 86a16e28 CLASSPNP!ClassReadWrite+0x172

90ed39dc 8296c6c3 8a03f030 86a16e28 8a03e270 CLASSPNP!ClassGlobalDispatch+0x20

90ed3a00 82679473 00000001 86a16f44 8a03f030 nt!IovCallDriver+0x258

90ed3a14 8491e230 871da358 86a16e28 8a03e1b8 nt!IofCallDriver+0x1b

90ed3a28 8491e2e5 8a03e270 86a16f28 86a16e28 partmgr!PmReadWrite+0x112

90ed3a3c 8296c6c3 8a03e1b8 86a16e28 67fce000 partmgr!PmGlobalDispatch+0x1d

90ed3a60 82679473 00000001 8a041cd0 8a03e1b8 nt!IovCallDriver+0x258

90ed3a74 8492f9ae 8b8f4308 86a16e28 8a041c18 nt!IofCallDriver+0x1b

90ed3a90 8296c6c3 8a041c18 86a16e28 86a16e28 volmgr!VmReadWrite+0x1a8

90ed3ab4 82679473 00000001 86a16e28 8a041c18 nt!IovCallDriver+0x258

90ed3ac8 84bb4475 8a0416f8 90ed3af0 84bb4548 nt!IofCallDriver+0x1b

90ed3ad4 84bb4548 8a0416f8 86a16e28 826ff1e4 fvevol!FveRequestPassThrough+0x31

90ed3af0 84bb4759 8a0416f8 86a16e01 87185970 fvevol!FveReadWrite+0x4e

90ed3b20 84bb47a9 8a041640 86a16e28 90ed3b54 fvevol!FveFilterRundownReadWrite+0x197

90ed3b30 8296c6c3 8a041640 86a16e28 86a16f8c fvevol!FveFilterRundownWrite+0x33

90ed3b54 82679473 00000001 8a0414ec 8a041640 nt!IovCallDriver+0x258

90ed3b68 84dbf76e 8a041490 86a16e28 00000003 nt!IofCallDriver+0x1b

90ed3c48 84dbf8a5 8a041490 86a16e28 00000000 rdyboost!SmdProcessReadWrite+0xa14

90ed3c68 8296c6c3 8a041490 86a16e28 86a16fb0 rdyboost!SmdDispatchReadWrite+0xcb

90ed3c8c 82679473 00000001 86a16fd4 8a0413d8 nt!IovCallDriver+0x258

90ed3ca0 84fa4fd9 8b816da8 86a16e28 8a042020 nt!IofCallDriver+0x1b

90ed3cc8 84fa52fd 00042020 86a16e28 90ed3cfc volsnap!VolsnapWriteFilter+0x265

90ed3cd8 8296c6c3 8a042020 86a16e28 90ed3d28 volsnap!VolSnapWrite+0x21

90ed3cfc 82679473 00000001 86e474c0 8a042020 nt!IovCallDriver+0x258

90ed3d10 84a5891c 86e47420 90ed3d34 826ad11e nt!IofCallDriver+0x1b

90ed3d1c 826ad11e 86e474c0 00000000 ffffffff Ntfs!NtfsStorageDriverCallout+0x14

90ed3d1c 826ad215 86e474c0 00000000 ffffffff nt!KiSwapKernelStackAndExit+0x15a

86e47430 826cd11d 86e474c0 84a58908 90ed4000 nt!KiSwitchKernelStackAndCallout+0x31

86e474a4 84a57939 84a58908 86e474c0 00000000 nt!KeExpandKernelStackAndCalloutEx+0x29d

86e474d0 84a585a6 8a042020 86a16e28 845d6b18 Ntfs!NtfsCallStorageDriver+0x2d

86e47514 84a570a0 86e477d0 8a042020 86a16e28 Ntfs!NtfsMultipleAsync+0x4d

86e47644 84a518fb 86e477d0 86a16e28 921fb0f8 Ntfs!NtfsNonCachedIo+0x413

86e476ac 84a55fa9 86e477d0 86a16e28 921fb0f8 Ntfs!NtfsNonCachedUsaWrite+0x145

86e477c0 84a5785f 86e477d0 86a16e28 0120070a Ntfs!NtfsCommonWrite+0x1dc0

86e47964 8296c6c3 8a099020 86a16e28 00000000 Ntfs!NtfsFsdWrite+0x2e1

86e47988 82679473 00000001 86a16e28 8a099020 nt!IovCallDriver+0x258

86e4799c 84a0720c 8a09a968 86a16e28 00000000 nt!IofCallDriver+0x1b

86e479c0 84a073cb 86e479e0 8a09a968 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa

86e479f8 8296c6c3 8a09a968 86a16e28 00000000 fltmgr!FltpDispatch+0xc5

86e47a1c 82679473 00000001 86a16e28 8a09a968 nt!IovCallDriver+0x258

86e47a30 82671749 86e47a70 00000000 86e47cc4 nt!IofCallDriver+0x1b

86e47a44 826d7b0f 8a03fc40 8a09a968 86e47b10 nt!IoSynchronousPageWrite+0x19d

86e47b74 826d8f4b 921fc008 921fc010 8b8fcb18 nt!MiFlushSectionInternal+0x828

86e47bdc 826cca34 008dac50 00001000 00000004 nt!MmFlushSection+0x78

86e47c70 826d58a3 8b8dac50 00000000 00000001 nt!CcFlushCache+0x329

86e47ca8 826ddee6 86e47cc4 a5bb778c 845b40d0 nt!CcWriteBehind+0x105

86e47d00 826aaf3b 845b40d0 00000000 845b5a70 nt!CcWorkerThread+0x164

86e47d50 8284b6bb 00000000 a5bb771c 00000000 nt!ExpWorkerThread+0x10d

86e47d90 826fd0f9 826aae2e 00000000 00000000 nt!PspSystemThreadStartup+0x9e

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19





STACK_COMMAND:  kb



FOLLOWUP_IP: 

ataport!IdeSynchronizeExecution+23

849c6ea9 eb03            jmp     ataport!IdeSynchronizeExecution+0x28 (849c6eae)



SYMBOL_STACK_INDEX:  4



SYMBOL_NAME:  ataport!IdeSynchronizeExecution+23



FOLLOWUP_NAME:  MachineOwner



MODULE_NAME: ataport



IMAGE_NAME:  ataport.SYS



DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf16



FAILURE_BUCKET_ID:  0x8E_VRF_ataport!IdeSynchronizeExecution+23



BUCKET_ID:  0x8E_VRF_ataport!IdeSynchronizeExecution+23



Followup: MachineOwner

---------

Comment 9 Qunfang Zhang 2010-07-14 05:22:08 UTC
Test in virtio-win-1.1.7-2 with winxp and win2k8-R2 guest, this issue does not exist. 
So, change this bug to verified.

Comment 10 Vadim Rozenfeld 2010-08-30 22:12:50 UTC
please check with the latest drivers from 
http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/mm21/

Comment 11 Qunfang Zhang 2010-09-07 03:02:33 UTC
(In reply to comment #10)
> please check with the latest drivers from 
> http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/mm21/

Re-tested whql virtio balloon with the above driver. All guests passed.
kernel: 2.6.32-66.el6
qemu-kvm: qemu-kvm-0.12.1.2-2.112.el6
virtio-win: 1.1.13-0
guests: win2k3, win2k8, win2k8R2, win7, winxp

Command line:
/usr/libexec/qemu-kvm -m 6G -smp 4 -cpu qemu64,+x2apic -usbdevice tablet -drive file=win2k8-64-balloon-v13.raw,format=raw,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,mac=00:10:42:2F:56:3E,bus=pci.0,addr=0x4 -boot c -uuid ac46937d-17bb-4c26-8c50-2abc02ab124a -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -name win2k8-64-balloon -device virtio-balloon-pci,addr=0x5,bus=pci.0 -spice port=5930,disable-ticketing -vga qxl

So, I will change the status to VERIFIED.

Comment 12 releng-rhel@redhat.com 2010-11-11 15:01:54 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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