win2008r2sp1 AllocatePage cause Bug check 0x000000C2 while migration

win2008r2sp1 AllocatePage cause Bug check 0x000000C2 while migration

[alice wan]

[-- Attachment #1.1: Type: text/plain, Size: 1425 bytes --]

hi james,

    the win2008r2 vm crash problem while migration seems related about the
AllocatePage.

    according to the previous  BSOD info, we modified code to test if page
address after AllocatePage is FFFFFA8000000000 or FFFFFA8000000002. if
FFFFFA8000000000 , then free it immediately, and allocate again.

    the test result shows

12948535073500: XenPCI --- AllocatePages IRQL = 0, Buf = FFFFFA8000000000
12948535073500: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref =
FFFFFA8000000000
12948535073500: XenPCI     test - tx-ring-ref = 18446738026395598848
12948535073515: XenPCI --- FreePages IRQL = 0, Buf = FFFFFA8000000000
12948535073515: XenPCI FreePages 1
12948535073515: XenPCI FreePages 2
Log-dirty command enable
Log-dirty command disable
XenPCI     Bug check 0x000000C2 (0x0000000000000042, 0xFFFFFA8000000000,
0x0000000000000000, 0x0000000000000000)
reset requested in cpu_handle_ioreq.
Issued domain 1436 reboot

    the previous test result without no modification of code is vm crashed,
BSOD  is also 0x000000C2.

    it means when it call ExAllocatePoolWithTag in AllocatePage func, the
return address is already wrong.

    is this the bug of win2008r2, even pactched with sp1?

    And the curious thing is why it always happened in vif allocate ?
sometimes tx-ring-ref, sometimes rx-ring-ref

    any advice?

    maybe, later, we can do some test about allocate,free in win2008r2sp1
image without pv.

[-- Attachment #1.2: Type: text/html, Size: 1740 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel