Loading Dump File [I:\bcao\serial\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: C:\testsymbols\;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.111025-1629
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Fri Mar 23 08:56:15.609 2012 (GMT+8)
System Uptime: 0 days 0:05:45.734
Loading Kernel Symbols
...............................................................
...........................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
Loading unloaded module list
........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 8E, {c0000005, ba15ab17, b59b4904, 0}

PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
Probably caused by : vioser.sys ( vioser!VIOSerialSendCtrlMsg+9b )

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

0: 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: ba15ab17, The address that the exception occurred at
Arg3: b59b4904, Trap Frame
Arg4: 00000000

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

PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details

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

FAULTING_IP: 
vioser!VIOSerialSendCtrlMsg+9b [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\control.c @ 46]
ba15ab17 8b4604          mov     eax,dword ptr [esi+4]

TRAP_FRAME:  b59b4904 -- (.trap 0xffffffffb59b4904)
ErrCode = 00000000
eax=bdad69b0 ebx=00000000 ecx=b59b49a0 edx=00000000 esi=00000000 edi=ba15d7fa
eip=ba15ab17 esp=b59b4978 ebp=b59b49bc iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210282
vioser!VIOSerialSendCtrlMsg+0x9b:
ba15ab17 8b4604          mov     eax,dword ptr [esi+4] ds:0023:00000004=????????
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  python.exe

LAST_CONTROL_TRANSFER:  from 804fe827 to 804f9f43

STACK_TEXT:  
b59b44cc 804fe827 0000008e c0000005 ba15ab17 nt!KeBugCheckEx+0x1b
b59b4894 805420e5 b59b48b0 00000000 b59b4904 nt!KiDispatchException+0x3b1
b59b48fc 80542096 b59b49bc ba15ab17 badb0d00 nt!CommonDispatchException+0x4d
b59b4910 8054bd24 00000068 8a5894c0 00001000 nt!KiExceptionExit+0x18a
b59b49bc ba159a38 00000000 00000001 00000006 nt!ExAllocatePoolWithTag+0x3bc
b59b49dc b9d3c02a 75db8fe8 75a390d0 75aa8d70 vioser!VIOSerialPortCreate+0xfc [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\port.c @ 1126]
b59b49f8 b9d3b10e 75db8fe8 75a390d0 75aa8d70 wdf01000!FxIoQueueIoRead::Invoke+0x2a
b59b4a34 b9d3b1f0 8a517f68 8a517f78 8a59f7b0 wdf01000!FxPkgGeneral::OnCreate+0x2dd
b59b4a50 b9d31a3f 8a517f68 b59b4b4c 804ef19f wdf01000!FxPkgGeneral::Dispatch+0xc3
b59b4a5c 804ef19f 8a247ab8 8a517f68 8a517f68 wdf01000!FxDevice::Dispatch+0x7f
b59b4a6c 80583220 8a247aa0 8a4e0fd4 b59b4c04 nt!IopfCallDriver+0x31
b59b4b4c 805bf488 8a247ab8 00000000 8a4e0f30 nt!IopParseDevice+0xa12
b59b4bc4 805bba14 00000000 b59b4c04 00000042 nt!ObpLookupObjectName+0x53c
b59b4c18 80576057 00000000 00000000 50995801 nt!ObOpenObjectByName+0xea
b59b4c94 805769ce 0021f3b8 c0100080 0021f358 nt!IopCreateFile+0x407
b59b4cf0 805790d8 0021f3b8 c0100080 0021f358 nt!IoCreateFile+0x8e
b59b4d30 8054167c 0021f3b8 c0100080 0021f358 nt!NtCreateFile+0x30
b59b4d30 7c90e526 0021f3b8 c0100080 0021f358 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0021f3b0 00000000 00000000 00000000 00000000 0x7c90e526


STACK_COMMAND:  kb

FOLLOWUP_IP: 
vioser!VIOSerialSendCtrlMsg+9b [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\control.c @ 46]
ba15ab17 8b4604          mov     eax,dword ptr [esi+4]

FAULTING_SOURCE_CODE:  
    42: 
    43:     sg.physAddr = MmGetPhysicalAddress(&cpkt);
    44:     sg.ulSize = sizeof(cpkt);
    45: 
>   46:     if(0 <= vq->vq_ops->add_buf(vq, &sg, 1, 0, &cpkt, NULL, 0))
    47:     {
    48:         vq->vq_ops->kick(vq);
    49:         while(!vq->vq_ops->get_buf(vq, &len))
    50:         {
    51:            KeStallExecutionProcessor(100);


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  vioser!VIOSerialSendCtrlMsg+9b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vioser

IMAGE_NAME:  vioser.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4f66615d

FAILURE_BUCKET_ID:  0x8E_vioser!VIOSerialSendCtrlMsg+9b

BUCKET_ID:  0x8E_vioser!VIOSerialSendCtrlMsg+9b

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

please check with the latest build
http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/25/win/virtio-win-prewhql-0.1.zip

Tested on virtio-win-prewhql-25 w/ win2k8R2 guests

steps:
1.Start guest with vioserial
CLI:/usr/libexec/qemu-kvm -M rhel6.3.0 -enable-kvm -m 1024 -smp     4,sockets=4,cores=1,threads=1 -name win2k8-R2 -uuid     e2eaca3e-e764-f57b-22f0-74f4ab8c4965 -monitor stdio -rtc     base=localtime,driftfix=slew -device     piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive     file=/test/win2k8r2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev     tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device     rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:15:af:6a,bus=pci.0,addr=0x4     -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0     -device usb-tablet,id=input0 -spice port=5910,disable-ticketing -vga qxl     -device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtioserial0 -chardev socket,path=/tmp/serialport0,id=serialport0,server,nowait -device virtserialport,bus=virtioserial0.0,id=virtioserialport0,chardev=serialport0,name=com.redhat.rhevm.vdsm
2.transfer date via vioserial in a loop
3.during step2 ,s3 guests 

Actual Restults:
Guest still BSOD

Based on above ,this issue hasn't been fixed yet ,re-assign this bug .

Moving to RHEL6.4
Since S3 support in RHEL6.3 is not the default, and since the fix involves an
infrastructure change from work-items to working thread.
Ronen.

In work, need to re-test in 2-3 weeks.

This look like a duplicate of a bug 882795. Mike, can you please confirm? Thanks.

(In reply to comment #13)
> This look like a duplicate of a bug 882795. Mike, can you please confirm?
> Thanks.

Sure ,I remeber you said there is a bug in seabios component will costs guest BSOD .Could you send me the seabios w/ the bug fixed first ,I will try to verify it on this issue 

Thanks,
Mike

(In reply to comment #14)
> (In reply to comment #13)
> > This look like a duplicate of a bug 882795. Mike, can you please confirm?
> > Thanks.
> 
> Sure ,I remeber you said there is a bug in seabios component will costs
> guest BSOD .Could you send me the seabios w/ the bug fixed first ,I will try
> to verify it on this issue 

The bug that is related to the BIOS is a virtio-scsi driver's bug. This one (and probably the duplicated bug 882795) is a virtio-serial driver's bug :-).

You should be able to verify this one with a latest driver and the current BIOS.
 
> Thanks,
> Mike

Re-assigned According to comment #17

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

(In reply to comment #19)
> Re-assigned According to comment #17

A commit was posted (230ec9af49d7d9affab273ec4d826bb0ca3ce813) and is waiting for a build.

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

Reproduced this issue on virtio-win-prewhql-0.1-54 version
Verified this issue on virtio-win-prewhql-0.1-55&virtio-win-prewhql-0.1-58 verion

steps same as comment#0

Actual Results:
on virtio-win-prewhql-0.1-54 verion ,guest BSOD when doing s3 while virtio-serial in use;

on virtio-win-prewhql-0.1-55&virtio-win-prewhql-0.1-58 verion ,guest can sleep&wakeup normally

Based on above ,this issue has been fixed already.

Based on Comment #28 ,Move status to Verified

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.

http://rhn.redhat.com/errata/RHBA-2013-1729.html