Bug 1126378 - [virtio-win][vioscsi][rhel6]win2012 guest bsod(d1) when shutdown guest with multi virtio-scsi devices on the same scsi controller
Summary: [virtio-win][vioscsi][rhel6]win2012 guest bsod(d1) when shutdown guest with m...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-04 09:52 UTC by lijin
Modified: 2015-11-24 08:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Attaching more than four LUNs to the same virtio-scsi controller can causes BSOD Consequence: under some circumstances, VM will crash with BSOD Fix: Add pending SRB queue to keep unsubmitted SRBs for the future processing instead of failing them. Result: Virtio-scsi device driver is capable to service up to 254 LUNs attached to the same controller *NOTE this bug has the same Doc context as bz#1195920 because these two bugs are closely related and were fixed with the same patch.
Clone Of:
Environment:
Last Closed: 2015-11-24 08:43:24 UTC


Attachments (Terms of Use)


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

Description lijin 2014-08-04 09:52:43 UTC
Description of problem:
boot win2012 guest with 256 disk on the same virtio-scsi-pci controller,when shutdown guest,gust bsod with d1 error code

Version-Release number of selected component (if applicable):
2.6.32-491.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.431.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64
virtio-win-prewhql-86 

How reproducible:
1/5,hit this issue only once,cannot reproduce it after i tried more 5 times

Steps to Reproduce:
1.boot guest with 256 disk on the same virtio-scsi-pci controller(one system disk and 255 data disks):
/usr/libexec/qemu-kvm  \
-drive file=win2k12-scsi-iso.qcow2,if=none,cache=none,media=disk,format=qcow2,werror=stop,rerror=stop,id=drive-scsi-0 \
-device virtio-scsi-pci,id=scsi0 -device scsi-hd,id=disk-scsi-0,drive=drive-scsi-0,bootindex=1 \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-usb -device usb-tablet \
-monitor stdio \
-chardev file,path=/root/console.log,id=serial1 \
-device isa-serial,chardev=serial1,id=s1 \
-cpu SandyBridge  -M rhel6.6.0  \
-smp 4 -m 4G \
-enable-kvm \
-qmp tcp:0:4444,server,nowait \
-vnc :0 -vga cirrus \
-drive file='/tmp/stg0.raw',if=none,id=virtio-scsi2-id1,media=disk,cache=none,snapshot=off,format=raw,aio=native \
-device scsi-disk,drive=virtio-scsi2-id1 \
-drive file='/tmp/stg1.raw',if=none,id=virtio-scsi3-id2,media=disk,cache=none,snapshot=off,format=raw,aio=native \
-device scsi-disk,drive=virtio-scsi3-id2 \
......
......
-drive file='/tmp/stg254.raw',if=none,id=virtio-scsi256-id255,media=disk,cache=none,snapshot=off,format=raw,aio=native \
-device scsi-disk,drive=virtio-scsi256-id255

2.check disks exist status:
cmd:wmic DISKDRIVE

3.shutdown guest

Actual results:
guest bsod with code d1

Expected results:
no bsod,guest can shutdown

Additional info:
windbg info:
3: 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: 0000000000000008, memory referenced
Arg2: 0000000000000008, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800103683b, address which referenced memory

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

Page 11ff00 not present in the dump file. Type ".hh dbgerr004" for details
Page 11ff00 not present in the dump file. Type ".hh dbgerr004" for details

READ_ADDRESS:  0000000000000008 

CURRENT_IRQL:  8

FAULTING_IP: 
vioscsi+283b
fffff880`0103683b 8b4608          mov     eax,dword ptr [rsi+8]

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  System

TRAP_FRAME:  fffff88000000000 -- (.trap 0xfffff88000000000)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
Unable to get program counter
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0ffff00100000000 rsp=ffffffffffffffff rbp=0009ffffffffffff
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl nz na pe nc
fe00:0000 ??              ???
Resetting default scope

EXCEPTION_RECORD:  fffff88000005583 -- (.exr 0xfffff88000005583)
Page 11ff00 not present in the dump file. Type ".hh dbgerr004" for details
Cannot read Exception record @ fffff88000005583

UNALIGNED_STACK_POINTER:  ffffffffffffffff

LAST_CONTROL_TRANSFER:  from fffff803e88f0369 to fffff803e88f1040

STACK_TEXT:  
fffff880`057d4918 fffff803`e88f0369 : 00000000`0000000a 00000000`00000008 00000000`00000008 00000000`00000000 : nt!KeBugCheckEx
fffff880`057d4920 fffff803`e88eebe0 : 00000000`00000000 fffffa80`04d835d0 fffff803`e8bbb000 fffff880`057d4a60 : nt!KiBugCheckDispatch+0x69
fffff880`057d4a60 fffff880`0103683b : 00000000`0018f817 fffff880`03174cc0 00000000`00000001 fffff803`e8b14400 : nt!KiPageFault+0x260
fffff880`057d4bf0 fffff803`e88ea106 : 00000000`0018f817 fffff880`0000006c fffff880`03174cc0 00000000`00000000 : vioscsi+0x283b
fffff880`057d4c20 fffff803`e8923f06 : fffff880`00005583 00000000`057d4f00 fffff880`00000000 00000000`00000000 : nt!KiInterruptDispatch+0x1d6
fffff880`057d4db0 fffff803`e895ee0c : 00000202`0018002b 00000000`00000000 fffff880`057d5020 00000000`00000000 : nt!KeFlushMultipleRangeTb+0x1f6
fffff880`057d4fb0 fffff803`e89fc70c : 00000000`00000000 fffff803`e89fc598 00000000`00000000 fffff980`05d46ca0 : nt!MiFlushPteList+0x2c
fffff880`057d4fe0 fffff803`e8ae67dd : ffffffff`ffdba100 00000000`00000000 00000000`2b707249 00000000`00000000 : nt!MmFreeSpecialPool+0x2ec
fffff880`057d5120 fffff803`e8ebc8e4 : fffff980`05d46ca0 fffffa80`044a4740 fffff980`05d46ca0 fffff803`e891c7d6 : nt!ExFreePool+0x6d8
fffff880`057d5200 fffff803`e8eb3fac : 00000000`00000001 fffff980`05d46ca0 fffffa80`05408a00 fffff803`e8991019 : nt!VfIoFreeIrp+0x174
fffff880`057d52b0 fffff803`e89912ac : 00000000`00000000 fffff880`057d52f0 00000000`00000000 fffff803`e8b0d930 : nt!IovFreeIrpPrivate+0x5c
fffff880`057d52f0 fffff803`e8bd7768 : fffffa80`05408d88 fffffa80`057379a0 fffff980`05d46ca0 fffff980`05d46ca0 : nt!PopFreeIrp+0xac
fffff880`057d5340 fffff803`e8eb2e9d : fffff980`05d46f68 fffffa80`057379a0 fffff980`05d46ca0 fffff880`057d55a0 : nt!PopSystemIrpCompletion+0x6c
fffff880`057d5410 fffff803`e8928156 : fffff980`05d46ca0 fffffa80`00000000 fffff880`057d54e9 fffff803`e888372a : nt!IovpLocalCompletionRoutine+0x17d
fffff880`057d5470 fffff803`e8eb3f20 : 00000000`00000100 fffff980`05d46c00 ffffef4b`fb58113e fffff803`e8ec3855 : nt!IopfCompleteRequest+0x446
fffff880`057d5550 fffff880`040b9cd8 : fffffa80`0449b570 fffff803`e8ec7dee 00000000`00000006 fffffa80`054081b0 : nt!IovCompleteRequest+0x1b0
fffff880`057d5620 fffff803`e8991473 : fffffa80`054855c0 fffffa80`05485500 fffff980`08fccca0 00000000`00000000 : HIDCLASS+0x6cd8
fffff880`057d5660 fffff803`e8eb2e9d : fffff980`08fccf68 fffffa80`054855c0 fffff980`08fccca0 fffff880`057d5840 : nt!PopRequestCompletion+0x63
fffff880`057d56b0 fffff803`e8928156 : fffff980`08fccca0 fffffa80`00000000 fffff880`057d5789 fffff803`e888372a : nt!IovpLocalCompletionRoutine+0x17d
fffff880`057d5710 fffff803`e8eb3f20 : ffffef4b`fb581200 fffff980`08fccc00 00000000`00000000 fffff803`e8ec7dee : nt!IopfCompleteRequest+0x446
fffff880`057d57f0 fffff880`040b92bf : 00000000`00000004 fffff980`08fccf68 00000000`00000004 fffffa80`04e531b0 : nt!IovCompleteRequest+0x1b0
fffff880`057d58c0 fffff880`040b8c33 : fffff980`08fccca0 00000000`00000001 fffffa80`054081b0 fffffa80`053fd1e0 : HIDCLASS+0x62bf
fffff880`057d5940 fffff880`040b44d0 : fffff980`08fccca0 00000000`00000016 fffffa80`054081b0 fffff980`08fccca0 : HIDCLASS+0x5c33
fffff880`057d59a0 fffff803`e8eb3d12 : fffff980`08fccca0 fffff980`08fccca0 fffffa80`05408060 fffff880`057d5a68 : HIDCLASS+0x14d0
fffff880`057d5a00 fffff880`040d82a3 : 00000000`00000004 00000000`00000000 fffffa80`053fd330 fffffa80`044feea0 : nt!IovCallDriver+0x3d2
fffff880`057d5a50 fffff803`e8eb3d12 : fffff980`08fccca0 fffffa80`053fd1e0 00000000`00000002 fffff880`057d5b10 : mouhid+0x22a3
fffff880`057d5ab0 fffff880`00cd4e17 : 00000000`00000004 00000000`00000000 00000000`00000000 fffffa80`0449e440 : nt!IovCallDriver+0x3d2
fffff880`057d5b00 fffff803`e8991ac4 : fffff980`08fccd01 00000000`00000001 fffff880`057d5be0 fffffa80`05408a00 : mouclass+0x9e17
fffff880`057d5b60 fffff803`e8898521 : ffffffff`fa0a1f00 fffffa80`059e8080 fffffa80`04e66c80 fffff880`02cdce40 : nt!PopIrpWorker+0x284
fffff880`057d5c10 fffff803`e88d6dd6 : fffff880`02cd1180 fffffa80`059e8080 fffff880`02cdce40 fffffa80`038925c0 : nt!PspSystemThreadStartup+0x59
fffff880`057d5c60 00000000`00000000 : fffff880`057d6000 fffff880`057d0000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
vioscsi+283b
fffff880`0103683b 8b4608          mov     eax,dword ptr [rsi+8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  vioscsi+283b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vioscsi

IMAGE_NAME:  vioscsi.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  538f1d5d

FAILURE_BUCKET_ID:  AV_VRF_vioscsi+283b

BUCKET_ID:  AV_VRF_vioscsi+283b

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

Comment 3 lijin 2014-08-06 05:38:07 UTC
win2012 guest hit the similar issue while running iometers on multiple scsi disks,guest bsod with "d1" error code.

How reproducible:
2/3

steps:
Testing Matrix ,
1. NTFS, cache=none|writethroug|writheback|unsafe
2. FAT32,cache=none|writethrough|writheback|unsafe
3. FAT,cache=none|writethrough|writheback|unsafe 
1.boot guest with one scsi system disk and 12 data disks:
/usr/libexec/qemu-kvm -drive file=win2k12-scsi-iso.qcow2,if=none,cache=none,media=disk,format=qcow2,werror=stop,rerror=stop,id=drive-scsi-0 -device virtio-scsi-pci,id=scsi0 -device scsi-hd,id=disk-scsi-0,drive=drive-scsi-0,bootindex=1 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -monitor stdio -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -cpu SandyBridge -M rhel6.6.0 -smp 4 -m 4G -enable-kvm -qmp tcp:0:4444,server,nowait -vnc :0 -vga cirrus \
-device virtio-scsi-pci,id=scsi1 \
-drive file=ntfs-none.raw,if=none,cache=none,media=disk,format=raw,id=drive-scsi-1 -device scsi-hd,id=disk-scsi-1,drive=drive-scsi-1 -drive file=ntfs-back.raw,if=none,cache=writeback,media=disk,format=raw,id=drive-scsi-2 -device scsi-hd,id=disk-scsi-2,drive=drive-scsi-2 -drive file=ntfs-through.raw,if=none,cache=writethrough,media=disk,format=raw,id=drive-scsi-3 -device scsi-hd,id=disk-scsi-3,drive=drive-scsi-3 -drive file=ntfs-unsafe.raw,if=none,cache=unsafe,media=disk,format=raw,id=drive-scsi-4 -device scsi-hd,id=disk-scsi-4,drive=drive-scsi-4 -drive file=fat-none.raw,if=none,cache=none,media=disk,format=raw,id=drive-scsi-5 -device scsi-hd,id=disk-scsi-5,drive=drive-scsi-5 -drive file=fat-back.raw,if=none,cache=writeback,media=disk,format=raw,id=drive-scsi-6 -device scsi-hd,id=disk-scsi-6,drive=drive-scsi-6 -drive file=fat-through.raw,if=none,cache=writethrough,media=disk,format=raw,id=drive-scsi-7 -device scsi-hd,id=disk-scsi-7,drive=drive-scsi-7 -drive file=fat-unsafe.raw,if=none,cache=unsafe,media=disk,format=raw,id=drive-scsi-8 -device scsi-hd,id=disk-scsi-8,drive=drive-scsi-8 -drive file=fat32-none.raw,if=none,cache=none,media=disk,format=raw,id=drive-scsi-9 -device scsi-hd,id=disk-scsi-9,drive=drive-scsi-9 -drive file=fat32-back.raw,if=none,cache=writeback,media=disk,format=raw,id=drive-scsi-10 -device scsi-hd,id=disk-scsi-10,drive=drive-scsi-10 -drive file=fat32-through.raw,if=none,cache=writethrough,media=disk,format=raw,id=drive-scsi-11 -device scsi-hd,id=disk-scsi-11,drive=drive-scsi-11 -drive file=fat32-unsafe.raw,if=none,cache=unsafe,media=disk,format=raw,id=drive-scsi-12 -device scsi-hd,id=disk-scsi-12,drive=drive-scsi-12
2.format the disk into ntfs/fat32/fat
3.Execute iometers on those disks together(include the system disk)

Actual result:
guest bsod with d1

the windbg info:
3: 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: fffff98000030008, memory referenced
Arg2: 0000000000000007, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800103683b, address which referenced memory

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


READ_ADDRESS:  fffff98000030008 

CURRENT_IRQL:  7

FAULTING_IP: 
vioscsi+283b
fffff880`0103683b 8b4608          mov     eax,dword ptr [rsi+8]

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  System

TAG_NOT_DEFINED_c000000f:  FFFFF88002D01FB0

TRAP_FRAME:  fffffa8005921b00 -- (.trap 0xfffffa8005921b00)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=0100050500000000 rbp=fffffa8005921b00
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl nz na pe nc
00000000`00000000 ??              ???
Resetting default scope

EXCEPTION_RECORD:  fffff800a7f4e12a -- (.exr 0xfffff800a7f4e12a)
ExceptionAddress: 20418b2b74c98548
   ExceptionCode: 8348c033
  ExceptionFlags: 90c328c4
NumberParameters: 611631237
   Parameter[0]: 0f41c88b44000002
   Parameter[1]: 0fca3ac2b60f08b6
   Parameter[2]: 0000c0c08149c147
   Parameter[3]: e675c9ff49d08a00
   Parameter[4]: 8348909090c3c28a
   Parameter[5]: 3b43b5e8c93328ec
   Parameter[6]: c328c48348c03300
   Parameter[7]: d18b4cc933459090
   Parameter[8]: 0280fa813774d285
   Parameter[9]: f30d8d4838730000
   Parameter[10]: 81048bc28b00217b
   Parameter[11]: eac1d08b2874c085
   Parameter[12]: 0fc0b60f443f2406
   Parameter[13]: 4c08ca548b49cab7
   Parameter[14]: 41c1920f41c2a30f

LAST_CONTROL_TRANSFER:  from fffff800a7e87369 to fffff800a7e88040

STACK_TEXT:  
fffff880`02cfa428 fffff800`a7e87369 : 00000000`0000000a fffff980`00030008 00000000`00000007 00000000`00000000 : nt!KeBugCheckEx
fffff880`02cfa430 fffff800`a7e85be0 : 00000000`00000000 fffffa80`05ac0620 fffff800`a8103100 fffff880`02cfa570 : nt!KiBugCheckDispatch+0x69
fffff880`02cfa570 fffff880`0103683b : fffffa80`04f76c70 fffff880`0371a3e0 fffffa80`04f76c70 00000000`00000063 : nt!KiPageFault+0x260
fffff880`02cfa700 fffff800`a7e81106 : fffff880`02cd65c8 fffff880`0000086c fffff880`0316ac00 00000000`ffffffff : vioscsi+0x283b
fffff880`02cfa730 fffff800`a858bfdf : fffff800`a7f4e12a fffffa80`05921c70 fffffa80`05921b00 fffff880`02cdce40 : nt!KiInterruptDispatch+0x1d6
fffff880`02cfa8c8 fffff800`a7f4e12a : fffffa80`05921c70 fffffa80`05921b00 fffff880`02cdce40 fffff880`016b3a5b : hal!HalProcessorIdle+0xf
fffff880`02cfa8d0 fffff800`a7eb69a0 : fffff880`02cd65c8 00000000`00369e99 00000000`00000000 00000000`00000000 : nt!PpmIdleDefaultExecute+0xa
fffff880`02cfa900 fffff800`a7eb53c0 : 00000000`00000000 00010e15`00010e15 fffff880`02cfab68 fffff880`02cfab70 : nt!PpmIdleExecuteTransition+0x47f
fffff880`02cfab20 fffff800`a7eb354c : fffff880`02cd1180 fffff880`02cd1180 00000000`00000000 fffff880`02cdce40 : nt!PoIdle+0x1e0
fffff880`02cfac60 00000000`00000000 : fffff880`02cfb000 fffff880`02cf5000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x2c


STACK_COMMAND:  kb

FOLLOWUP_IP: 
vioscsi+283b
fffff880`0103683b 8b4608          mov     eax,dword ptr [rsi+8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  vioscsi+283b

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  RAISED_IRQL_USER_FAULT

MODULE_NAME: Unknown_Module

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

Comment 4 Mike Cao 2014-08-07 06:33:39 UTC
Move back to rhel7.1.0 as Fam can 100% reproduce it when debuging https://bugzilla.redhat.com/show_bug.cgi?id=1125796

Comment 5 Fam Zheng 2014-08-07 10:02:12 UTC
Please test with the latest virtio-win driver

https://brewweb.devel.redhat.com/buildinfo?buildID=361029

It has some improvements on virtio-scsi driver, and also fixes bug 1125796.

Comment 6 lijin 2014-08-08 04:56:10 UTC
(In reply to Fam Zheng from comment #5)
> Please test with the latest virtio-win driver
> 
> https://brewweb.devel.redhat.com/buildinfo?buildID=361029
> 
> It has some improvements on virtio-scsi driver, and also fixes bug 1125796.

retry scenario in comment #3 five times with virtio-win-prewhql-89,iometer can be finished without any error,and guest works fine.

Comment 7 Mike Cao 2014-08-15 02:58:14 UTC
(In reply to lijin from comment #6)
> (In reply to Fam Zheng from comment #5)
> > Please test with the latest virtio-win driver
> > 
> > https://brewweb.devel.redhat.com/buildinfo?buildID=361029
> > 
> > It has some improvements on virtio-scsi driver, and also fixes bug 1125796.
> 
> retry scenario in comment #3 five times with virtio-win-prewhql-89,iometer
> can be finished without any error,and guest works fine.

Since We would like to ship -88 , Can you retest this on virtio-win-prewhql-88 ?

Thanks,
Mike

Comment 8 lijin 2014-08-15 06:59:51 UTC
(In reply to Mike Cao from comment #7)
> (In reply to lijin from comment #6)
> > (In reply to Fam Zheng from comment #5)
> > > Please test with the latest virtio-win driver
> > > 
> > > https://brewweb.devel.redhat.com/buildinfo?buildID=361029
> > > 
> > > It has some improvements on virtio-scsi driver, and also fixes bug 1125796.
> > 
> > retry scenario in comment #3 five times with virtio-win-prewhql-89,iometer
> > can be finished without any error,and guest works fine.
> 
> Since We would like to ship -88 , Can you retest this on
> virtio-win-prewhql-88 ?
> 
> Thanks,
> Mike

retest with build 88,guest still bsod with d1

Comment 12 lijin 2014-10-28 07:57:51 UTC
As guest only bsod once in comment0's scenario ,it's not easy to reproduce this issue,both b86 and b93 work fine during my reproduce;
But in comment3's scenario(nearly 100% reproducible),guest BSOD with b86,and guest works fine with b93,hope this info can help.

package info:
virtio-win-prewhql-86/93
qemu-kvm-rhev-0.12.1.2-2.444.el6.x86_64
kernel-2.6.32-492.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64
spice-server-0.12.4-11.el6.x86_64

Comment 13 Vadim Rozenfeld 2014-10-28 08:18:34 UTC
(In reply to lijin from comment #12)
> As guest only bsod once in comment0's scenario ,it's not easy to reproduce

It should be easier to reproduce this problem under heavy read/write load. Let say copying a huge file to 5 disks simultaneously, while shutting the guest down.

> this issue,both b86 and b93 work fine during my reproduce;
> But in comment3's scenario(nearly 100% reproducible),guest BSOD with b86,and
> guest works fine with b93,hope this info can help.
> 
> package info:
> virtio-win-prewhql-86/93
> qemu-kvm-rhev-0.12.1.2-2.444.el6.x86_64
> kernel-2.6.32-492.el6.x86_64
> seabios-0.6.1.2-28.el6.x86_64
> spice-server-0.12.4-11.el6.x86_64

Comment 14 lijin 2014-10-28 10:09:24 UTC
(In reply to Vadim Rozenfeld from comment #13)
> (In reply to lijin from comment #12)
> > As guest only bsod once in comment0's scenario ,it's not easy to reproduce
> 
> It should be easier to reproduce this problem under heavy read/write load.
> Let say copying a huge file to 5 disks simultaneously, while shutting the
> guest down.

Thanks Vadim,it works.
guest bsod with build86 and guest works fine with build93.
steps:
1.boot win2012 guest with 256 disks(one 50G system disk,255 500M data disks)
2.format several disks(about 11 disks)
3.do iometer on those disks
4.shutdown guest

> > this issue,both b86 and b93 work fine during my reproduce;
> > But in comment3's scenario(nearly 100% reproducible),guest BSOD with b86,and
> > guest works fine with b93,hope this info can help.
> > 
> > package info:
> > virtio-win-prewhql-86/93
> > qemu-kvm-rhev-0.12.1.2-2.444.el6.x86_64
> > kernel-2.6.32-492.el6.x86_64
> > seabios-0.6.1.2-28.el6.x86_64
> > spice-server-0.12.4-11.el6.x86_64

Comment 18 lijin 2015-02-28 08:41:57 UTC
Reproduced this issue on virtio-win-prewhql-86
Verified this issue on virtio-win-prewhql-100

package info:
qemu-kvm-rhev-0.12.1.2-2.454.el6.x86_64
kernel-2.6.32-539.el6.x86_64
seabios-0.6.1.2-29.el6.x86_64

steps same as comment #14

Actual Results:
on virtio-win-prewhql-86, run twice,guest BSOD once;
on virtio-win-prewhql-100,run five times,guest can shutdown correctly,no BSOD

Based on above ,this issue has been fixed already.

Comment 20 lijin 2015-03-16 05:39:37 UTC
Reproduced this issue on virtio-win-prewhql-86
Verified this issue on virtio-win-prewhql-102

package info:
qemu-kvm-rhev-0.12.1.2-2.458.el6.x86_64
kernel-2.6.32-540.el6.x86_64
seabios-0.6.1.2-29.el6.x86_64

steps same as comment #14

Actual Results:
on virtio-win-prewhql-86,BSOD happens when shutdown guest while doing iometer test;
on virtio-win-prewhql-102,run five times,guest can shutdown correctly,no BSOD

Based on above ,this issue has been fixed already.

Comment 21 Vadim Rozenfeld 2015-05-28 01:49:18 UTC
The problem was fixed together with bz#1195920
Can we close it or move to verified?

Thanks,
Vadim.

Comment 22 lijin 2015-05-28 02:10:16 UTC
(In reply to Vadim Rozenfeld from comment #21)
> The problem was fixed together with bz#1195920
> Can we close it or move to verified?
Yes.
According to comment#20,this issue has been fixed.
Change the status to verified

Comment 24 errata-xmlrpc 2015-11-24 08:43:24 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.