WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Infinte loop in RtlPrefetchMemoryNonTemporal under Windows

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Infinte loop in RtlPrefetchMemoryNonTemporal under Windows
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 22 Nov 2008 22:23:27 +1100
Delivery-date: Sat, 22 Nov 2008 03:24:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclMlLvoHhLvgAcuR0mEAReL/OsfCg==
Thread-topic: Infinte loop in RtlPrefetchMemoryNonTemporal under Windows
I have been trying to track down a problem that occurs when my GPLPV
drivers give Windows a packet with the NdisPacketTcpChecksumSucceeded
flag set. The problem is that the machine locks hard.

After some tedious work with the debugger, I have found that Windows
makes a call to a routine called RtlPrefetchMemoryNonTemporal, which
looks like this:

8088e579 mov     eax,dword ptr [nt!KePrefetchNTAGranularity 8088e57e
0f184100 prefetchnta [ecx]
8088e582 add     ecx,eax
8088e584 sub     edx,eax
8088e586 ja      nt!RtlPrefetchMemoryNonTemporal+0x6 (8088e57e)
8088e588 ret

Unfortunately it appears that the value at nt!KePrefetchNTAGranularity
is 0, hence the infinite loop.

Is there anything in Xen that could cause Windows to put a zero in
there? The other (more likely?) alternative is that I'm doing something
wrong in my driver that is causing that value to be stepped on. It seems
really strange that I could so neatly step on that value without
breaking the machine in countless other ways though...

The problem only appeared when I upgraded from 3.2.1 to 3.3.0 too.

Any suggestions? It's driving me crazy!

Thanks

James

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