Bug 1081436

Summary: [virtio-rng]BSOD occurs on win8-32bit guest during boot again without virtio-rng device
Product: Red Hat Enterprise Linux 7 Reporter: Xu Han <xuhan>
Component: virtio-winAssignee: Gal Hammer <ghammer>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: bcao, hhuang, juzhang, knoel, mazhang, mdeng, michen, rbalakri, virt-maint, vrozenfe
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virtio-win-prewhql-0.1-88 Doc Type: Bug Fix
Doc Text:
Cause: BSOD occurs on win8-32bit guest during boot again without virtio-rng device. Consequence: Rebooting Win8 VM with virtio-rng device removed will lead to BSOD. Fix: Add proper handler to virtio-rng device DO entry routine, Result: Now rebooting Win8 VM with virtio-rng device removed will not trigger BSOD.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 05:34:09 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1131838    
Attachments:
Description Flags
debuginfo of memory dump
none
mini dump none

Description Xu Han 2014-03-27 10:16:25 UTC
Description of problem:
Boot a win8-32bit guest with virtio-rng device. Shutting down guest and then boot again without virtio-rng, the guest would crashed.

Version-Release number of selected component (if applicable):
virtio-win-prewhql-0.1-76
qemu-kvm-rhev-1.5.3-57.el7ev.x86_64

How reproducible:
always

Steps to Reproduce:
1. boot win8-32bit guest with virtio-rng device
2. shutdown guest and boot again without virtio-rng

Actual results:
Guest crashed during boot.

Expected results:
No crashs.

Additional info:
# cat win8-32.cli
/usr/libexec/qemu-kvm \
-M pc-i440fx-rhel7.0.0 \
-cpu Opteron_G3,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_time \
-m 4096 \
-smp 4,threads=2,cores=2,sockets=1 \
-enable-kvm \
-name hp-dl385g7-03-win8-32 \
-uuid 2cc19222-a0eb-4b42-82a8-25f458b7edcd \
-nodefconfig \
-nodefaults \
-k en-us \
-rtc base=utc,clock=host,driftfix=slew \
-qmp tcp:0:5000,server,nowait \
-boot order=c,menu=on \
-vga cirrus \
-vnc :0 \
-drive file=/home/win8-32.qcow2_v3,if=none,id=drive-virtio0,cache=none,aio=native,rerror=stop,werror=stop \
-device virtio-blk-pci,drive=drive-virtio0,id=os-disk,scsi=off,bootindex=1 \
-netdev tap,id=tap0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown,queues=2 \
-device virtio-net-pci,netdev=tap0,mac=05:d6:32:09:3a:ef,id=net0,vectors=6,mq=on \
-chardev socket,id=charserial0,path=/var/local/qemu/hp-dl385g7-03-win8-32/console,server,nowait \
-device isa-serial,chardev=charserial0,id=serial0 \
-device virtio-serial-pci,id=virtio-serial0,max_ports=16 \
-chardev socket,id=channel0,path=/var/local/qemu/hp-dl385g7-03-win8-32/virtserial,server,nowait \
-device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port1 \
-chardev socket,id=qemu-ga0,path=/var/local/qemu/hp-dl385g7-03-win8-32/qemu-ga,server,nowait \
-device virtserialport,chardev=qemu-ga0,name=org.qemu.guest_agent.0,bus=virtio-serial0.0,id=port2 \
-device virtio-balloon-pci,id=balloon0 \
-drive file=/root/iso/prewhql76.iso,if=none,id=dv,media=cdrom \
-device ide-cd,drive=dv,id=cdrom0 \
-object rng-random,filename=/dev/random,id=rng-random0 \
-device virtio-rng-pci,rng=rng-random0,id=rng0 \
-monitor stdio \
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=0

# diff win8-32.cli win8-32.cli.none 
31,32d30
< -object rng-random,filename=/dev/random,id=rng-random0 \
< -device virtio-rng-pci,rng=rng-random0,id=rng0 \

Comment 1 Xu Han 2014-03-27 10:24:03 UTC
Created attachment 879391 [details]
debuginfo of memory dump

Comment 2 Xu Han 2014-03-27 10:24:52 UTC
Created attachment 879392 [details]
mini dump

Comment 3 Gal Hammer 2014-03-31 07:36:08 UTC
Same solution as in bz #966809. I think this might be is a bug in qemu's shutdown process.

Comment 4 Mike Cao 2014-03-31 08:08:55 UTC
(In reply to Gal Hammer from comment #3)
> Same solution as in bz #966809. I think this might be is a bug in qemu's
> shutdown process.

pls provide devel_ackh

Comment 5 Min Deng 2014-04-21 06:21:36 UTC
The bug could be easily reproduced on win8-32 guest
build,qemu-kvm-1.5.3-60.el7.x86_64
      build 79
steps,
1.boot up guest with the following CLI
/usr/libexec/qemu-kvm -M pc-i440fx-rhel7.0.0 -cpu Nehalem,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_time -m 4096 -smp 4,threads=2,cores=2,sockets=1 -enable-kvm -name hp-dl385g7-03-win8-32 -uuid 2cc19222-a0eb-4b42-82a8-25f458b7edcd -nodefconfig -nodefaults -k en-us -rtc base=utc,clock=host,driftfix=slew -qmp tcp:0:5000,server,nowait -boot order=c,menu=on -vga cirrus -vnc :0 -drive file=/home/win8-32-again.raw,if=none,id=drive-virtio0,cache=none,aio=native,rerror=stop,werror=stop -device ide-drive,drive=drive-virtio0,id=os-disk,bootindex=1 -netdev tap,id=tap0,vhost=on,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=tap0,id=net0 -monitor stdio -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -object rng-random,filename=/dev/random,id=rng-random0 
-device virtio-rng-pci,rng=rng-random0,id=rng0 
2.install driver inside build 79 for virtio-rng and shutdown guest.
3.boot up guest again without '-object rng-random,filename=/dev/random,id=rng-random0 -device virtio-rng-pci,rng=rng-random0,id=rng0'
4.The guest got BSOD ,tried to boot 5 times and hit once.
Probably caused by : viorng.sys ( viorng+13df )

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

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: 00000004, memory referenced
Arg2: 00000008, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804013df, address which referenced memory

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

Comment 7 Mike Cao 2014-05-28 06:27:37 UTC
Based on comment #5 ,reassigned this issue 

dengmin ,pls retested it and make sure fastboot option is disabled

Comment 9 Gal Hammer 2014-07-23 09:06:23 UTC
A patch was posted.

Comment 10 Mike Cao 2014-08-15 06:51:41 UTC
dengmin ,pls reproduce it on virtio-win-prwehql-88

Ronen, This bug is lack of devel_ack+ .

Comment 11 Min Deng 2014-08-15 10:20:08 UTC
   Verified the bug on virtio-win-prewhql-0.1-88 and rhel6.6 and rhel7
On rhel6.6 host 
virtio-win-prewhql-0.1-89
kernel-2.6.32-492.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.430.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64 (latest so far)
On rhel7 host  
virtio-win-prewhql-0.1-89
kernel-3.10.0-143.el7.x86_64
qemu-kvm-rhev-2.1.0-1.el7.x86_64.rpm
seabios-1.7.5-4.el7.x86_64.rpm
seabios-bin-1.7.5-4.el7.noarch.rpm
seavgabios-bin-1.7.5-4.el7.noarch.rpm
  Detail steps please refer to comment5,
  Actual results:Guest works well and there is no BSOD 
  Expected results:Guest works well and there is no BSOD 

  So the bug has already fixed,thanks.

Comment 12 Ronen Hod 2014-08-17 12:06:27 UTC
(In reply to Mike Cao from comment #10)
> dengmin ,pls reproduce it on virtio-win-prwehql-88
> 
> Ronen, This bug is lack of devel_ack+ .

Thanks.
Do you want to remove the FailedQA

Comment 13 Mike Cao 2014-08-20 07:06:03 UTC
Move status to Verified according to comment #11

Comment 15 errata-xmlrpc 2015-03-05 05:34:09 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-0289.html