Bug 811910
| Summary: | [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. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | dawu | ||||
| Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.3 | CC: | acathrow, bcao, bsarathy, dyasny, juzhang, michen, yvugenfi | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-04-14 20:04:27 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: | |||||||
| Attachments: |
|
||||||
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. *** This bug has been marked as a duplicate of bug 811161 *** (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 (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 (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 |
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.