Bug 966809 - [virtio-win][serial]Guest win7-64 BSOD(7E) during resume from s4 after hot plug virtio serial device
Summary: [virtio-win][serial]Guest win7-64 BSOD(7E) during resume from s4 after hot pl...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virtio-win
Version: 6.5
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Gal Hammer
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-24 03:29 UTC by lijin
Modified: 2013-12-06 07:56 UTC (History)
7 users (show)

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.
Clone Of:
Environment:
Last Closed: 2013-11-22 00:12:18 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1729 normal SHIPPED_LIVE virtio-win bug fix and enhancement update 2013-11-21 00:39:25 UTC

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):
qemu-kvm-rhev-0.12.1.2-2.369.el6.x86_64
kernel-2.6.32-381.el6.x86_64
seabios-0.6.1.2-27.el6.x86_64
virtio-win-prewhql-62

How reproducible:
100%

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                                    *
*                                                                             *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
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.

FAULTING_IP: 
vioser+5200
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
vioser+0x5200:
fffff880`02bc4200 488b4308        mov     rax,qword ptr [rbx+8] ds:002b:00000000`00000008=????????????????
Resetting default scope

PROCESS_NAME:  System

CURRENT_IRQL:  0

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 

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

BUGCHECK_STR:  0x7E

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from fffff88002bcdb24 to fffff88002bc4200

STACK_TEXT:  
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_STACK_INDEX:  0

SYMBOL_NAME:  vioser+5200

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vioser

IMAGE_NAME:  vioser.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  519b2b89

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.

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


Note You need to log in before you can comment on or make changes to this bug.