Bug 799178

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