Bug 966809

Summary: [virtio-win][serial]Guest win7-64 BSOD(7E) during resume from s4 after hot plug virtio serial device
Product: Red Hat Enterprise Linux 6 Reporter: lijin <lijin>
Component: virtio-winAssignee: Gal Hammer <ghammer>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 6.5CC: acathrow, bcao, bsarathy, kzhang, qzhang, rhod, vrozenfe
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: virtio-win-prewhql-0.1-64 Doc Type: Bug Fix
Doc Text:
Cause: resume from s4 after hot plug virtio serial device Consequence: System fail in BSOD with bugcheck code 7E Fix: In vioseral code by handling device surprise-removal condition Result: guest can resume successfully,no BSOD happens.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-22 00:12:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description lijin 2013-05-24 03:29:32 UTC
Description of problem:
Guest win7-64 BSOD during resume from s4 after hot plug virtio serial device 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot a guest with following command:
/usr/libexec/qemu-kvm -drive file=win7-64-serial-62.qcow2,if=none,cache=unsafe,media=disk,format=qcow2,id=drive-ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -device virtio-serial-pci,id=virtio-serial-0,max_ports=16 -chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial-0.0,id=port1 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial-0.0,id=port2 -spice port=5900,disable-ticketing -vga qxl -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -monitor unix:/tmp/tt,server,nowait -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -device ich9-usb-uhci1,id=usb1,bus=pci.0 -cpu Penryn,hv_relaxed -M rhel6.4.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -bios /usr/share/seabios/bios.bin -enable-kvm

2. Hot plug virtio-serial-bus
eg: (qemu) device_add virtio-serial-pci,id=virtio-serial0,max_ports=16

3. hot add virtserialport ,attached on chardev0
eg: (qemu)device_add chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port0

4. hot add virtioserialport ,attached on chardev1
eg: (qemu)device_add chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port1

5. Transferring data from guest to host via port1 in a loop
eg: on the host # for ((;;)) ; do python serial-host-receive.py /tmp/helloworld1; done
in the guest #for ((;;)) ; do python VirtIOChannel_guest_send.py com.redhat.rhevm.vdsm1;done

6. Transferring data form host to guest via port2 in a loop
eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm2; done
on the host # for ((;;)) ;do python serial-host-send.py /tmp/helloworld2 ; done

7. hibernate(s4) guest

8. resume guest

Actual results:
when resume from s4,guest get BSOD with error code 7E

Expected results:
guest can resume successfully,no BSOD happen.

Additional info:
the debug info will be update later

Comment 2 lijin 2013-05-24 04:18:47 UTC
the windbg info:
1: kd> !analyze  -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

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.
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff88002bc4200, The address that the exception occurred at
Arg3: fffff8800311d6f8, Exception Record Address
Arg4: fffff8800311cf50, Context Record Address

Debugging Details:

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

fffff880`02bc4200 488b4308        mov     rax,qword ptr [rbx+8]

EXCEPTION_RECORD:  fffff8800311d6f8 -- (.exr 0xfffff8800311d6f8)
ExceptionAddress: fffff88002bc4200 (vioser+0x0000000000005200)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000008
Attempt to read from address 0000000000000008

CONTEXT:  fffff8800311cf50 -- (.cxr 0xfffff8800311cf50)
rax=000000002d497978 rbx=0000000000000000 rcx=fffff8800311d978
rdx=0000000fffffffff rsi=0000000000000001 rdi=0000000000000000
rip=fffff88002bc4200 rsp=fffff8800311d930 rbp=0000000000000000
 r8=fffff8800311d938  r9=0000000000000000 r10=0000000000000978
r11=fffff8800311d940 r12=00000000ffffffff r13=0000000000000335
r14=0000000000000000 r15=fffff88000f60250
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
fffff880`02bc4200 488b4308        mov     rax,qword ptr [rbx+8] ds:002b:00000000`00000008=????????????????
Resetting default scope



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

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000000008

READ_ADDRESS:  0000000000000008 

fffff880`02bc4200 488b4308        mov     rax,qword ptr [rbx+8]



LAST_CONTROL_TRANSFER:  from fffff88002bcdb24 to fffff88002bc4200

fffff880`0311d930 fffff880`02bcdb24 : fffffa80`03831650 00000000`00000000 fffff880`00f60a80 0000057f`fc7ced18 : vioser+0x5200
fffff880`0311d9a0 fffff880`00f4c904 : fffffa80`02b7c7c0 00000000`00000000 fffff880`00f60a80 fffffa80`02b7c7c0 : vioser+0xeb24
fffff880`0311d9d0 fffff880`00f4b6eb : 00000000`00000000 00000000`00000000 fffff880`00f60a40 00000000`00000001 : Wdf01000!FxPkgPnp::PowerWakingConnectInterrupt+0x4c
fffff880`0311da30 fffff880`00f4b38e : fffffa80`02b7c7c0 00000000`00000000 fffff880`00f607c0 00000000`00000001 : Wdf01000!FxPkgPnp::PowerEnterNewState+0x1db
fffff880`0311db60 fffff880`00f4b218 : fffffa80`02b7c958 00000000`00000000 fffff880`0311dc50 fffffa80`02b7c7c0 : Wdf01000!FxPkgPnp::PowerProcessEventInner+0x13e
fffff880`0311dbd0 fffff880`00f5759f : fffffa80`02b7c958 fffffa80`018bbb60 fffffa80`02b7c7c0 fffffa80`02b7c958 : Wdf01000!FxPkgPnp::_PowerProcessEventInner+0x60
fffff880`0311dc10 fffff800`02988527 : 00000000`00000000 fffffa80`019b57e0 fffff800`028325f8 fffffa80`018bbb60 : Wdf01000!FxEventQueue::EventQueueWorker+0x83
fffff880`0311dc80 fffff800`0269c161 : fffff800`028325f8 fffff800`02988504 fffffa80`018bbb60 fffffa80`018bbb60 : nt!IopProcessWorkItem+0x23
fffff880`0311dcb0 fffff800`02932166 : 00000000`00000000 fffffa80`018bbb60 00000000`00000080 fffffa80`0184bb30 : nt!ExpWorkerThread+0x111
fffff880`0311dd40 fffff800`0266d486 : fffff880`009eb180 fffffa80`018bbb60 fffff880`009f5f40 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`0311dd80 00000000`00000000 : fffff880`0311e000 fffff880`03118000 fffff880`0311d3a0 00000000`00000000 : nt!KiStartSystemThread+0x16


SYMBOL_NAME:  vioser+5200

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  vioser.sys


STACK_COMMAND:  .cxr 0xfffff8800311cf50 ; kb

FAILURE_BUCKET_ID:  X64_0x7E_vioser+5200

BUCKET_ID:  X64_0x7E_vioser+5200

Followup: MachineOwner

Comment 4 Gal Hammer 2013-06-02 13:03:46 UTC
A simple scenario which reproduce the bug:

1. Start a VM without virtio-serial-pci device.
2. Attach a device:

(qemu) device_add virtio-serial-pci,id=virtio-serial0,max_ports=16
(qemu) device_add virtserialport,chardev=charchannel0,name=linux-kvm,bus=virtio-serial0.0,id=serialport0

3. Hibernate the guest.
4. Start the VM again.

Comment 5 lijin 2013-06-17 08:22:51 UTC
Reproduced this issue on build 62
Verified this issue on build 64

steps same as comment #4

Actual Results:
on build 62, win7-64 guest get BSOD with 7E code
on build 64,guest can resume successfully,no BSOD happened. 

Based on above ,this issue has been fixed already .

Comment 6 Mike Cao 2013-06-28 05:17:36 UTC
Move Status to VERIFIED accordingt to comment #5

Comment 10 errata-xmlrpc 2013-11-22 00:12:18 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.