Mats,
I honestly had no idea what instruction or operation was generating this
fault from the original description - I merely analyzed it from the
meaning of the specific fault - and data alignment has been an issue in
the past on some platforms (e.g. Alpha) as well as current platforms
(IA64). I do know there ARE operations that will cause alignment
faults on x64 that would have worked on x86, but without the reference
manuals in front of me I couldn’t put my finger on a comprehensive list.
I did confirm two things this morning (now that I’m in office and can
get my hands on my x64 ref manuals): (1) Unaligned 8 byte data access
using cmpxchg will generate a data alignment fault in protected mode on
x64 (if alignment checking is enabled, which it is), and (2) the SList
code uses the 8 byte cmpxchg. Indeed, the SList code appears to be hand
written assembly (this doesn’t look to be garden variety C generated
code, at least).
In addition we can SEE the code in the header file (ntddk.h) where
InitializeSListHead is declared:
#ifdef _WIN64
//
// Slist headers must be 16 byte aligned.
//
if ((ULONG_PTR) SListHead & 0x0f) {
DbgPrint( “InitializeSListHead unaligned Slist header. Address
= %p, Caller = %p\n”, SListHead, _ReturnAddress());
RtlRaiseStatus(STATUS_DATATYPE_MISALIGNMENT);
}
#endif
That’s clearly the source of the raise. Note that the alignment
requirement here is 16 bytes, not even 8 bytes, despite the fact they
aren’t using the 16 byte compare exchange in this instance (ah, but
perhaps they will in the future?)
The x64 can be put in a permissive mode where it will accept sloppy
alignment. Fortunately, the OS guys decided not to tolerate this (new
platform, great time to tighten things up). We’ll end up benefiting
from better scalability.
Our resident guinea pig recently installed 64-bit Windows on his
development system and says it is *noticeably* faster, largely due to OS
level improvements. Driver support is still weak, but I think he takes
pleasure in calling up companies and saying “say, don’t you support
Windows XP?” and then telling them their driver doesn’t work on his
Windows XP box…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Thursday, May 12, 2005 8:16 AM
To: ntdev redirect
Subject: RE: [ntdev] AMD64 and ExInitializeNPagedLookasideList
Tony,
x86-64 has no more alignment issues than x86 in general. The only
“alignment trap (fault)” available in x86-64 is Vector 17, which if the
right flags are enabled will trap unaligned access in user-mode (CPL=3),
but nothing else.
Of course, using MOVAxx (Move aligned SSE instructions) will cause a GP
fault.
I believe this is an assert from the kernel that fires for some reason,
for
internal performance reasons most likely.
I agree with the solution, moving the base of the allocated memory to a
8
(or better yet, 16 byte) boundary will be a good idea. Even if the OS
didn’t trap, I’d recommend evening out any large memory block to start
on a
16-byte boundary, as that is the cache-line size of the L1 cache, and it
will help keeping things in the cache more tidy.
IA64 may well have some other criteria, and the “assert” that the OS
gives
off may well have something to do with IA64 requirements.
–
Mats
“Tony Mason”
Sent by:
To
bounce-208984-140 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
cc
05/12/2005 12:54
PM
Subject
RE: [ntdev] AMD64 and
ExInitializeNPagedLookasideList
Please respond to
“Windows System
Software Devs
Interest List”
com>
X86 platforms don’t have the same data alignment requirements as IA64 or
X64 systems have. You don’t provide the rest of the analysis (“!analyze
-v”) nor do you decode the context record (“.cxr 0xFFFFFADFF20EBEF0”)
which would have at least provided additional insight into the crash.
You also don’t tell us how you allocated your lookaside list. My
suspicion is that you have allocated a block of memory and the lookaside
list is in the middle of that block of memory. Move the lookaside list
so it is on an 8 byte boundary and the alignment issue will disappear.
It is possible this is related to something ELSE that you are doing.
Even x86 has alignment constraints (try manipulating data values using
SSE or SSE2 instructions) but they are generally more liberal than
64-bit platforms.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Else Kluger
Sent: Thursday, May 12, 2005 9:30 AM
To: ntdev redirect
Subject: [ntdev] AMD64 and ExInitializeNPagedLookasideList
Hi,
need some help with the AMD64.
My driver was working with AMD64 unless I began to use LookAsideLists.
Now as soon as it calls ExInitializeNPagedLookasideList, following BSOD
occurs:
InitializeSListHead unaligned Slist header. Address = FFFFFADFF39A8B78,
Caller = FFFFFADFF18BFAA6
*** Fatal System Error: 0x0000007e
(0xFFFFFFFF80000002,0xFFFFF800008AE817,0xFFFFFADFF20EBE50,0xFFFFFADFF20E
BEF0)
(meaning 0x80000002: STATUS_DATATYPE_MISALIGNMENT
=An unaligned data reference was encountered)
Under x86 the LookAsideLists work fine.
Kind regards,
Else
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00012D92
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com