Hide Forgot
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.
Created attachment 426530 [details] dump file
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.
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.
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.
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
*** Bug 605508 has been marked as a duplicate of this bug. ***
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?
(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
Could you please recheck with "cache=writethrough" instead on "none" Thanks, Vadim.
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 .
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
So, can we close the bug? We have additional 3 virtio-blk issues, can you please test them?
Change this bug status to verified according to Comment13.
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.