Hide Forgot
Description of problem: Job of "Crashdump Support Test [LOGO]" always failed for not generating dump file. Version-Release number of selected component (if applicable): virtio-win-prewhql-0.1-23 kernel-2.6.32-232.el6.x86_64 qemu-kvm-0.12.1.2-2.227.el6.x86_64 How reproducible: always Steps to Reproduce: 1.Set virtual memory larger than RAM,take win7-64 for example,the RAM is 2046, set it to 2500 or 2150 etc. And the free size of c:\ is 25G. 1.Run job of "Crashdump Support Test [LOGO]" Actual results: Failed at sub-job of "Run kernel dump test/Analyse complete dump", the BSOD is triggered successfully but system reboot automatically immediately without dump file generating. Following is the DTM logs: -Loading Dump File Test Start Test 2/24/2012 8:01:10.613 PM Loading Dump File Test End Test 2/24/2012 8:01:10.613 PM Loading Dump File Test Result: Fail Repro: crashdumptest.exe -autorun -y C:\symbols -dtm Expected results: Job of "Crashdump Support Test [LOGO]" should passed without any error. Additional info: This issue reproduced all guests which have this job,please refer to the attachment of "crashdumptest_win7_64.wtl" and "win7-64-blk-23-fail-AD.cpk" for details.
Created attachment 566980 [details] crashdumptest_win7_64.wtl
Created attachment 566981 [details] win7-64-blk-23-fail-AD.cpk
Hi Dawn, Seems to be a regression introduced by uniform virtio library. Could you please re-check that build 22 doesn't have such problem? Thank you, Vadim.
Hibernation is also broken. BTW, seems Crash dump doesn't work with any Virtual Memory size. Yan, could look into this problem?
(In reply to comment #3) > Hi Dawn, > > Seems to be a regression introduced by uniform virtio library. Could you please > re-check that build 22 doesn't have such problem? No this bug found in build 22 , referring to https://docspace.corp.redhat.com/docs/DOC-93167 > > Thank you, > Vadim.
I tested the code base in my repository and build 23. In both cases in order to get a crash dump in my environment (I had a small image of 15G that I used as a secondary driver and redirected dump creation to it) I had to set \HKLM\System\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump DWORD value to 1 . Why it should be done explained here: http://www.osronline.com/article.cfm?article=545 The solution looks always to set the above registry value to 1 (could be that 25G + expected crash dump size of free space can also be a solution). I tested both the creation of full and kernel memory dumps. Please retest with set registry value.
(In reply to comment #7) > I tested the code base in my repository and build 23. > > In both cases in order to get a crash dump in my environment (I had a small > image of 15G that I used as a secondary driver and redirected dump creation to > it) I had to set > \HKLM\System\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump DWORD > value to 1 . > > Why it should be done explained here: > http://www.osronline.com/article.cfm?article=545 > > The solution looks always to set the above registry value to 1 (could be that > 25G + expected crash dump size of free space can also be a solution). > > I tested both the creation of full and kernel memory dumps. > > > Please retest with set registry value. Hi Yan, I have tried the two ways you mentioned, following is the details: 1. Set \HKLM\System\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump DWORD value to 1 . Result: actually this value is set to 1 as default.I have tried to reset it as the same vale 1, the same issue still happened. 2. 25G + expected crash dump size of free space,I have set the free space as 37G, the guest RMA is 2G,but the same issue happend. Note: 1.This issue does not only reproduce on win7 but all the guests which has this job. 2.I ran the build with virtio-win-prewhql-0.1-22 on the same guest with the same configuration,complete dump file can be collected and the whole job passed without any error,so looks something wrong with the driver self on build virtio-win-prewhql-0.1-23. Best Regards, Dawn
(In reply to comment #8) > (In reply to comment #7) > > I tested the code base in my repository and build 23. > > ... > 2.I ran the build with virtio-win-prewhql-0.1-22 on the same guest with the > same configuration,complete dump file can be collected and the whole job passed > without any error,so looks something wrong with the driver self on build > virtio-win-prewhql-0.1-23. > > Best Regards, > Dawn Hi Dawn, To be on the same page, please provide the following: 1. Command line that you use to run the guest VM. 2. From what exact location you are installing the driver? (I did it from <unpacked package>\Win7\amd64). Thanks, Yan.
(In reply to comment #9) > Hi Dawn, > > To be on the same page, please provide the following: > > 1. Command line that you use to run the guest VM. CLI: /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic,family=0xf -usb -device usb-tablet -drive file=win7-64-blk-23.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,id=hostnet0,script=/etc/qemu-ifup0 -device e1000,netdev=hostnet0,mac=00:10:1a:15:78:16,bus=pci.0,addr=0x4 -uuid 4760a481-5886-4cfc-b406-2589fd3e7dcd -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/win7-64-blk-23,server,nowait -mon chardev=111a,mode=readline -name win7-64-blk-23 -spice disable-ticketing,port=5931 -vga qxl -drive file=disk1.raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -drive file=disk2.raw,if=none,id=drive-virtio2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio2,id=virtio-blk-pci2 -drive file=disk3.raw,if=none,id=drive-virtio3,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio3,id=virtio-blk-pci3 -drive file=disk4.raw,if=none,id=drive-virtio4,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio4,id=virtio-blk-pci4 > 2. From what exact location you are installing the driver? (I did it from > <unpacked package>\Win7\amd64). I installed it from <unpacked package>\Wlh/amd64 and I also tried to install it from <unpacked package>\Win7\amd64,the same thing happened. Best Regards, Dawn > > Thanks, > Yan.
Hi Yan, I tried to manually trigger a crash via Ctrl + ScrollLock to generate a complete dump, BSOD happened, but the dump file collecting stopped in disk initializing stage,please refer to the attached pic "CrashDump_fail_generateDumpFile_win7-64.png" for details. Best Regards, Dawn
Created attachment 569592 [details] CrashDump_fail_generateDumpFile_win7-64
Build 24 includes the fix.
Verified this issue with the latest build http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/24/win/virtio-win-prewhql-0.1.zip,following is the environment details: virtio-win-prewhql-0.1-24 kernel-2.6.32-232.el6.x86_64 qemu-kvm-0.12.1.2-2.227.el6.x86_64 Job "Crashdump Support Test [LOGO]" passed. Note: although this job passed on all guests,but one strange thing happened to make this job hard to pass on win7-32 and win2k8-r2, the sub job "Initialize" was always showed as on going in Job Monitor of DTM Studio till all the other sub jobs passed, it was cancelled finally with unexpected reboot error, no DTM log, but finally the whole job showed as passed in Job Monitor, however, it showed as fail in the report, please refer to the attachment of "win2k8-R2-crashdump-failed-AD.cpk" for details. I ran 7 times for this job on win7-32, it passed at the last time. For win2k8-R2, ran 10 times, still hit this strange thing, and I re-ran on a fresh img again, it passed in the first time.So keep this bug open till the whql passed. Best Regards, Dawn
Keep in mind that using a clean image for WHQL tests is always a good practice.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No Documentation needed. Sort time regression introduced while switching uniform virtio library.
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-2012-0751.html