607555 – winxp with virtio block BSOD at the first reboot of installation

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 607555 - winxp with virtio block BSOD at the first reboot of installation

Summary: winxp with virtio block BSOD at the first reboot of installation

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	virtio-win
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Vadim Rozenfeld
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	605508 (view as bug list)
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2010-06-24 11:13 UTC by Miya Chen
Modified:	2013-01-09 22:47 UTC (History)
CC List:	8 users (show)
Fixed In Version:	virtio-win-1.1.8-0.vfd
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2010-11-11 15:01:44 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
bsod screenshot (153.34 KB, image/png) 2010-06-24 11:13 UTC, Miya Chen	no flags	Details
dump file (64.00 KB, application/octet-stream) 2010-06-24 11:15 UTC, Miya Chen	no flags	Details
View All

Description Miya Chen 2010-06-24 11:13:23 UTC

Created attachment 426529 [details]
bsod screenshot

Description of problem:
winxp with virtio block BSOD at the first reboot of installation

Version-Release number of selected component (if applicable):
2.6.32-36.el6.x86_64
qemu-kvm-0.12.1.2-2.77.el6.x86_64
virtio-win-1.1.5-0.vfd & virtio-win-1.1.0-0.vfd

How reproducible:
100%

Steps to Reproduce:
1. install winxp guest with virtio block:
#  /usr/libexec/qemu-kvm -smp 2 -m 2G -drive file=winxp-virt.qcow2,if=none,boot=on,format=qcow2,cache=none,id=test1 -device virtio-blk-pci,drive=test1 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=20:20:20:11:16:68 -uuid `uuidgen` -cpu qemu64,+sse2 -monitor stdio -vnc :11 -cdrom /opt/xp/en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso -fda virtio-win-1.1.0-0.vfd -boot d

  
Actual results:
winxp with virtio block BSOD at the first reboot of installation
screenshot is attached.

Expected results:


Additional info:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 100000D0, {8, 2, 0, 8054805e}

Probably caused by : memory_corruption ( nt!MiAllocatePoolPages+58 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_CORRUPTED_MMPOOL (d0)
Arguments:
Arg1: 00000008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8054805e, address which referenced memory
	An attempt was made to access a pageable (or completely invalid) address at an
	interrupt request level (IRQL) that is too high.  This is
	caused by drivers that have corrupted the system pool.  Run the driver
	verifier against any new (or suspect) drivers, and if that doesn't turn up
	the culprit, then use gflags to enable special pool.  You can also set
	HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ProtectNonPagedPool
	to a DWORD 1 value and reboot.  Then the system will unmap freed nonpaged pool,
	preventing drivers (although not DMA-hardware) from corrupting the pool.

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


READ_ADDRESS: GetUlongFromAddress: unable to read from 80561f50
 00000008 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiAllocatePoolPages+58
8054805e 3918            cmp     dword ptr [eax],ebx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0xD0

PROCESS_NAME:  lsass.exe

LAST_CONTROL_TRANSFER:  from 8054ba71 to 8054805e

STACK_TEXT:  
f762634c 8054ba71 00000000 00001000 00000000 nt!MiAllocatePoolPages+0x58
f76263b4 f716bd4e 00000004 00001000 3966744e nt!ExAllocatePoolWithTag+0x109
f76263f4 f716bf63 f76265f8 89a17620 00000000 Ntfs!NtfsCreateMdlAndBuffer+0x43
f76265e8 f716bc18 f76265f8 89972130 0110070a Ntfs!NtfsCommonWrite+0x17c8
f762675c 804ef18f 899c7020 89972130 012b6000 Ntfs!NtfsFsdWrite+0xf3
f762676c 804f04d9 f76267a8 89a173f0 89a173c0 nt!IopfCallDriver+0x31
f7626780 8050f072 89a17506 f76267a8 f7626848 nt!IoSynchronousPageWrite+0xaf
f7626868 8050fa94 e11d05b0 e11d05b8 e11d05b8 nt!MiFlushSectionInternal+0x3f8
f76268a4 804e4544 89a173f0 00000000 00001000 nt!MmFlushSection+0x1f2
f762692c f718c007 00001000 f76269cc 00001000 nt!CcFlushCache+0x3a0
f76269f4 f718c089 e119f3d8 e10974b0 e119f3d8 Ntfs!LfsFlushLfcb+0x227
f7626a18 f71963db e119f3d8 e10974b0 e1144990 Ntfs!LfsFlushLbcb+0x81
f7626a40 f718ac60 e119f3d8 ffffffff 7fffffff Ntfs!LfsFlushToLsnPriv+0xf3
f7626a80 f71a9fe4 e1144990 ffffffff 7fffffff Ntfs!LfsFlushToLsn+0x8e
f7626aec f71aa160 89971ea0 89987398 89a08290 Ntfs!NtfsCommonFlushBuffers+0x287
f7626b50 804ef18f 899c7020 89987398 806e6410 Ntfs!NtfsFsdFlushBuffers+0x92
f7626b60 8057f982 89a08290 89987398 89973038 nt!IopfCallDriver+0x31
f7626b74 80576eb1 899c7020 89987398 89a08290 nt!IopSynchronousServiceTail+0x70
f7626bec 8054161c 800001cc f7626c80 f7626c88 nt!NtFlushBuffersFile+0x1b9
f7626bec 80500341 800001cc f7626c80 f7626c88 nt!KiFastCallEntry+0xfc
f7626c6c 8063c227 800001cc f7626c80 e12c0ee0 nt!ZwFlushBuffersFile+0x11
f7626c88 8063b6f5 e1036b60 00000001 00000000 nt!CmpFileFlush+0x55
f7626cdc 8063b8ab 01000003 e1036b60 00000000 nt!HvpWriteLog+0x27f
f7626cf0 80632a8a e1036b01 e12a6518 00000000 nt!HvSyncHive+0x71
f7626d04 80624522 e1036b60 00000120 f7626d64 nt!CmFlushKey+0x94
f7626d58 8054161c 00000378 0007fd8c 7c90e506 nt!NtFlushKey+0x88
f7626d58 7c90e506 00000378 0007fd8c 7c90e506 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0007fd8c 00000000 00000000 00000000 00000000 0x7c90e506


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiAllocatePoolPages+58
8054805e 3918            cmp     dword ptr [eax],ebx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiAllocatePoolPages+58

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4802516a

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xD0_nt!MiAllocatePoolPages+58

BUCKET_ID:  0xD0_nt!MiAllocatePoolPages+58

Followup: MachineOwner
---------

1: kd> lmvm nt
start    end        module name
804d7000 806e4000   nt       # (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x86)\sym\ntkrpamp.pdb\7D6290E03E32455BB0E035E38816124F1\ntkrpamp.pdb
    Loaded symbol image file: ntkrpamp.exe
    Mapped memory image file: C:\Program Files\Debugging Tools for Windows (x86)\sym\ntkrpamp.exe\4802516A20d000\ntkrpamp.exe
    Image path: ntkrpamp.exe
    Image name: ntkrpamp.exe
    Timestamp:        Sun Apr 13 11:31:06 2008 (4802516A)
    CheckSum:         001F442E
    ImageSize:        0020D000
    File version:     5.1.2600.5512
    Product version:  5.1.2600.5512
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     040c.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Syst�me d'exploitation Microsoft� Windows�
    InternalName:     ntkrpamp.exe
    OriginalFilename: ntkrpamp.exe
    ProductVersion:   5.1.2600.5512
    FileVersion:      5.1.2600.5512 (xpsp.080413-2111)
    FileDescription:  Noyau et syst�me NT
    LegalCopyright:   � Microsoft Corporation. Tous droits r�serv�s.
1: kd> lmvm nt
start    end        module name
804d7000 806e4000   nt       # (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x86)\sym\ntkrpamp.pdb\7D6290E03E32455BB0E035E38816124F1\ntkrpamp.pdb
    Loaded symbol image file: ntkrpamp.exe
    Mapped memory image file: C:\Program Files\Debugging Tools for Windows (x86)\sym\ntkrpamp.exe\4802516A20d000\ntkrpamp.exe
    Image path: ntkrpamp.exe
    Image name: ntkrpamp.exe
    Timestamp:        Sun Apr 13 11:31:06 2008 (4802516A)
    CheckSum:         001F442E
    ImageSize:        0020D000
    File version:     5.1.2600.5512
    Product version:  5.1.2600.5512
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     040c.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Syst�me d'exploitation Microsoft� Windows�
    InternalName:     ntkrpamp.exe
    OriginalFilename: ntkrpamp.exe
    ProductVersion:   5.1.2600.5512
    FileVersion:      5.1.2600.5512 (xpsp.080413-2111)
    FileDescription:  Noyau et syst�me NT
    LegalCopyright:   � Microsoft Corporation. Tous droits r�serv�s.

Comment 1 Miya Chen 2010-06-24 11:15:33 UTC

Created attachment 426530 [details]
dump file

Comment 2 Miya Chen 2010-06-24 11:18:39 UTC

additional:
virtio-win driver can be downloaded from:
http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.5-0/

this problem does not exist when using ide.

Comment 4 RHEL Program Management 2010-06-24 11:32:56 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 Qunfang Zhang 2010-06-29 05:14:40 UTC

I also meet this issue on win7-32 and win7-64 guest. BSOD often happens after reboot, and can not continue testing virtio-blk using the driver in Comment 2.

Comment 7 Jes Sorensen 2010-06-29 15:19:19 UTC

This looks like a duplicate of BZ#605508, but your bug report seems
more complete than mine, so I will mark 605508 a duplicate of this one.

Jes

Comment 8 Jes Sorensen 2010-06-29 15:20:07 UTC

*** Bug 605508 has been marked as a duplicate of this bug. ***

Comment 9 Jes Sorensen 2010-06-30 16:32:43 UTC

Keqin Hong reported that it worked ok with
seabios-0.5.1-0.10.20100108git669c991.el6.x86_64.rpm, while it resulted
in BSODs with seabios-0.5.1-0.11.20100108git669c991.el6.x86_64.rpm and above.

Which seabios version did you have installed for this test?

Comment 10 Miya Chen 2010-07-01 08:54:59 UTC

(In reply to comment #9)
> Keqin Hong reported that it worked ok with
> seabios-0.5.1-0.10.20100108git669c991.el6.x86_64.rpm, while it resulted
> in BSODs with seabios-0.5.1-0.11.20100108git669c991.el6.x86_64.rpm and above.
> 
> Which seabios version did you have installed for this test?    

Tried this again with the same cmd using the following env, still got the same BSOD.

# uname -r
2.6.32-37.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.82.el6.x86_64
# rpm -q seabios
seabios-0.5.1-0.10.20100108git669c991.el6.x86_64

Comment 11 Vadim Rozenfeld 2010-07-05 10:03:42 UTC

Could you please recheck with "cache=writethrough" instead on "none"

Thanks,
Vadim.

Comment 12 Miya Chen 2010-07-06 02:29:07 UTC

recheck with "cache=writethrough", this problem does not exist, guest can be installed successfully.

# rpm -q seabios
seabios-0.5.1-2.el6.x86_64
# uname -r
2.6.32-37.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.90.el6.x86_64

cmd:
# /usr/libexec/qemu-kvm -smp 2 -m 2G -drive file=winxp_virt.qcow2,if=none,boot=on,format=qcow2,cache=writethrough,id=test1 -device virtio-blk-pci,drive=test1 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=20:20:20:11:16:68 -uuid `uuidgen` -cpu qemu64,+sse2 -monitor stdio -vnc :11 -cdrom en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso -fda virtio-win-1.1.7-2.vfd -boot d


BTW:
Using "cache=none" with the above env, still got BSOD .

Comment 13 Shirley Zhou 2010-07-15 05:39:21 UTC

Install windows xp x86 guest with virtio-win-1.1.8.0 using virtio block, it can be installed successfully.
qemu-kvm-0.12.1.2-2.91.el6.x86_64
kernel-2.6.32-44.el6.x86_64
virtio-win-1.1.8.0
CLI:/usr/libexec/qemu-kvm -m 2G -smp 2 -cpu qemu64,+x2apic -usbdevice tablet -drive file=/home/winxp.qcow2,if=none,id=drive-virtio0,boot=on,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=00:00:16:3F:20:1f,bus=pci.0 -uuid a4f4127c-1233-4e67-95da-8dd0a8891cc4 -name winxp -qmp tcp:0:4444,server,nowait -boot c -monitor stdio -spice port=5930,disable-ticketing -vga qxl -cdrom /mnt/WindowsXP-32.iso -fda /mnt/virtio-win-1.1.8-0.vfd -boot d

Comment 14 Dor Laor 2010-07-15 09:43:25 UTC

So, can we close the bug?
We have additional 3 virtio-blk issues, can you please test them?

Comment 15 Shirley Zhou 2010-07-16 08:08:04 UTC

Change this bug status to verified according to Comment13.

Comment 16 releng-rhel@redhat.com 2010-11-11 15:01:44 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.