RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1729 0 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.