Bug 811910 - [virtio-win][viostor] BSOD when doing S3 after upgrade virtio-blk driver to the latest build virtio-win-prewhql-0.1-25 on win7-32.
[virtio-win][viostor] BSOD when doing S3 after upgrade virtio-blk driver to t...
Status: CLOSED DUPLICATE of bug 811161
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virtio-win (Show other bugs)
6.3
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Vadim Rozenfeld
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-12 06:02 EDT by dawu
Modified: 2012-04-16 04:07 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-14 16:04:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
win7-32-blk-upgrad-BSOD (18.02 KB, image/png)
2012-04-12 06:02 EDT, dawu
no flags Details

  None (edit)
Description dawu 2012-04-12 06:02:55 EDT
Created attachment 577025 [details]
win7-32-blk-upgrad-BSOD

Description of problem:
BSOD when doing S3 after upgrade virtio-blk driver from virtio-win-rewhql-0.1-16 to the latest build virtio-win-prewhql-0.1-25 on win7-32, I also tried from virtio-win-rewhql-0.1-24 to 25, the same thing happened.

Version-Release number of selected component (if applicable):
kernel-2.6.32-259.el6.x86_64
qemu-kvm-0.12.1.2-2.270.el6.x86_64
virtio-win-rewhql-0.1-25
seabios-0.6.1.2-16.el6.x86_64 


How reproducible:
always

Steps to Reproduce:
1.Start guest with old driver virtio-win-rewhql-0.1-16 or virtio-win-rewhql-0.1-24:
   /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic,family=0xf -usb -device usb-tablet -drive file=win7-32-0326.raw,format=raw,if=none,id=drive-virtio0,boot=on,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0,bootindex=1 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup0,downscript=no -device e1000,netdev=hostnet0,mac=00:10:1a:01:78:26,bus=pci.0,addr=0x4  -uuid b35f00e9-c93d-4c14-883e-0451a4331d2c -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/win7-32,server,nowait -mon chardev=111a,mode=readline -monitor stdio  -spice disable-ticketing,port=5931 -vga qxl
  
2.Upgrade driver to virtio-win-rewhql-0.1-25.

3.S3
  
Actual results:
Guest BSOD with Error code "0x000000D1" and qemu quit after finishing dump file collecting,no error found from qemu monitor side.Following is the dump file analysis:

*******************************************************************************
*                                                                             *
*                        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: 0000000a, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 88424f8d, address which referenced memory

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


READ_ADDRESS:  00000004 

CURRENT_IRQL:  a

FAULTING_IP: 
viostor+1f8d
88424f8d 8b4804          mov     ecx,dword ptr [eax+4]

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  System

TRAP_FRAME:  807e1d14 -- (.trap 0xffffffff807e1d14)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=8447369c edx=000000b0 esi=844af5e8 edi=8447369c
eip=88424f8d esp=807e1d88 ebp=807e1d9c iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
viostor+0x1f8d:
88424f8d 8b4804          mov     ecx,dword ptr [eax+4] ds:0023:00000004=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 88424f8d to 8268c5cb

STACK_TEXT:  
807e1d14 88424f8d badb0d00 000000b0 807c1120 nt!KiTrap0E+0x2cf
WARNING: Stack unwind information not available. Following frames may be wrong.
807e1d9c 883b26ae 8447369c 00000001 807e1dbc viostor+0x1f8d
807e1dac 883b30f0 8446a188 00000001 807e1dd0 storport!RaCallMiniportMsiInterrupt+0x1b
807e1dbc 826d5b30 8447c500 8446a0e8 00000001 storport!RaidpAdapterMSIInterruptRoutine+0x29
807e1dd0 826857ad 8447c500 8446a0e8 807e1dfc nt!KiInterruptMessageDispatch+0x12
807e1dd0 82616da2 8447c500 8446a0e8 807e1dfc nt!KiInterruptDispatch+0x6d
807e1e6c 82619a4d 8446a188 844e8228 00000002 hal!HalpGenerateInterrupt+0x2ce
807e1e8c 82619ba0 00000000 84473302 807e1ea4 hal!HalpLowerIrqlHardwareInterrupts+0xf5
807e1e9c 8272c2d2 807e1eb8 883b287e 84473410 hal!KfLowerIrql+0x58
807e1ea4 883b287e 84473410 00000002 8446a0e8 nt!KeReleaseInterruptSpinLock+0x19
807e1eb8 883b2917 8446a0e8 00000002 807e1ef0 storport!RaidAdapterReleaseInterruptLock+0x54
807e1ec8 883b53bb 8446a0e8 807e1ee4 85c113b0 storport!RaidAdapterReleaseHwInitializeLock+0x14
807e1ef0 883bcdd9 8446a0e8 8446a0e8 85c113b0 storport!RaidAdapterStopAdapter+0x3d
807e1f08 883bcea3 85c113b0 8446a0e8 8446a0e8 storport!RaidAdapterDevicePowerstopAdapter+0x46
807e1f20 883b331e 85243008 8446a0a4 85fce99c storport!RaidAdapterDevicePowerDownSrbComplete+0x4d
807e1f48 826c31b5 8446a0a4 8446a030 00000000 storport!RaidpAdapterDpcRoutine+0x51
807e1fa4 826c3018 807c1120 85fce918 00000000 nt!KiExecuteAllDpcs+0xf9
807e1ff4 826c27dc 9c2a1b78 00000000 00000000 nt!KiRetireDpcList+0xd5
807e1ff8 9c2a1b78 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
826c27dc 00000000 0000001a 00d6850f bb830000 0x9c2a1b78


STACK_COMMAND:  kb

FOLLOWUP_IP: 
viostor+1f8d
88424f8d 8b4804          mov     ecx,dword ptr [eax+4]

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  viostor+1f8d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: viostor

IMAGE_NAME:  viostor.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4f81aec6

FAILURE_BUCKET_ID:  0xD1_viostor+1f8d

BUCKET_ID:  0xD1_viostor+1f8d

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

For more details,please refer to the attached "win7-32-BSOD-S3-Uprade.DMP" and "win7-32-blk-upgrad-BSOD-S3-new.png".

Expected results:
S3 should be successfully after driver upgrade.

Additional info:
1.This issue does not reproduce when downgrade driver.
2.Reboot guest after qemu quit, guest can do S3 without any error.
Comment 2 Miya Chen 2012-04-12 06:49:00 EDT
Hi Dawn, you mean this is a regression of the block driver in build 25 ? How about doing s3 with build 16 and 24? thanks.
Comment 3 Vadim Rozenfeld 2012-04-14 16:04:27 EDT

*** This bug has been marked as a duplicate of bug 811161 ***
Comment 4 dawu 2012-04-16 03:24:52 EDT
(In reply to comment #2)
> Hi Dawn, you mean this is a regression of the block driver in build 25 ? How
> about doing s3 with build 16 and 24? thanks.

Hi Miya,

This issue does not exist on 24 when upgrade from 16 to 24,and I verified this issue on the latest build 26 with the same steps in commont #0, also does not reproduce any more, more viewed, I also can not reproduce this issue on build 25. 

Best Regards,
Dawn
Comment 5 Vadim Rozenfeld 2012-04-16 03:42:42 EDT
(In reply to comment #4)
> (In reply to comment #2)
> > Hi Dawn, you mean this is a regression of the block driver in build 25 ? How
> > about doing s3 with build 16 and 24? thanks.
> 
> Hi Miya,
> 
> This issue does not exist on 24 when upgrade from 16 to 24,and I verified this
> issue on the latest build 26 with the same steps in commont #0, also does not
> reproduce any more, more viewed, I also can not reproduce this issue on build
> 25. 
Hi Dawn,
I was able to reproduce this crash with drivers from build 25. Definitely it was a regression, introduced with the flush request handler bug-fix. I believe, I managed to fix this problem in build 26, but this fix requires entire re-WHQL'ing of viostor driver.

best regards,
Vadim.
 
> 
> Best Regards,
> Dawn
Comment 6 Mike Cao 2012-04-16 03:55:56 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > Hi Dawn, you mean this is a regression of the block driver in build 25 ? How
> > > about doing s3 with build 16 and 24? thanks.
> > 
> > Hi Miya,
> > 
> > This issue does not exist on 24 when upgrade from 16 to 24,and I verified this
> > issue on the latest build 26 with the same steps in commont #0, also does not
> > reproduce any more, more viewed, I also can not reproduce this issue on build
> > 25. 
> Hi Dawn,
> I was able to reproduce this crash with drivers from build 25. Definitely it
> was a regression, introduced with the flush request handler bug-fix. I believe,
> I managed to fix this problem in build 26, but this fix requires entire
> re-WHQL'ing of viostor driver.
> 
> best regards,
> Vadim.

Hi, Vadim

From my test ,your patch fixed 811161 , and what your request is QE's work plan in this week :) 

Mike

> 
> > 
> > Best Regards,
> > Dawn

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