I have implemented a DMA_ADAPTER into my Xen drivers, and it has allowed
for some pretty impressive performance improvements due to the fact that
I can now work with sg lists.
However, the crash dump path of my scsiport driver no longer works. It
crashes in hal!HalAllocateCrashDumpRegisters with 0xA (0x88, 0xD000001F,
0x0, …). This happens as a result of my call to ScsiPortInitialize.
None of my DMA_ADAPTER functions are even called though during the crash
dump path, so I don’t really know where to start looking… any
suggestions?
Thanks
James
>
I have implemented a DMA_ADAPTER into my Xen drivers, and it has
allowed
for some pretty impressive performance improvements due to the fact
that
I can now work with sg lists.
However, the crash dump path of my scsiport driver no longer works. It
crashes in hal!HalAllocateCrashDumpRegisters with 0xA (0x88,
0xD000001F,
0x0, …). This happens as a result of my call to ScsiPortInitialize.
None of my DMA_ADAPTER functions are even called though during the
crash
dump path, so I don’t really know where to start looking… any
suggestions?
I have just spent some time tracing this through in windbg, and it seems
that it wants to access offset 8 in my DMA_ADAPTER structure, which is
outside the structure and into my own private data, and then becomes
unstuck because of what it expects to find there (eg windows private
data instead of mine). It later reads a null pointer from somewhere and
then tries to access offset 0x88, which is where the crash occurs.
Can I assume from this behaviour that a non-Microsoft driver supplied
DMA_ADAPTER is not compatible with the crash dump (and maybe hibernate?)
path? That would be pretty poor… maybe Microsoft had to do some
trickery to make their DMA_ADAPTER work at HIGH_LEVEL?
Or maybe I’m just making a stupid mistake somewhere?
James
I’m not sure either, but WDK’s declaration of DMA_ADAPTER is incomplete as
the actual structure (a.k.a. ADAPTER_OBJECT) also contains a private
member, so you cannot define it yourself. Drivers are supposed to call
IoGetDmaAdapter() to retrieve a pointer to the adapter object.
On Sat, 31 Jan 2009 14:06:41 +0100, James Harper
wrote:
>> I have implemented a DMA_ADAPTER into my Xen drivers, and it has
> allowed
>> for some pretty impressive performance improvements due to the fact
> that
>> I can now work with sg lists.
>>
>> However, the crash dump path of my scsiport driver no longer works. It
>> crashes in hal!HalAllocateCrashDumpRegisters with 0xA (0x88,
> 0xD000001F,
>> 0x0, …). This happens as a result of my call to ScsiPortInitialize.
>>
>> None of my DMA_ADAPTER functions are even called though during the
> crash
>> dump path, so I don’t really know where to start looking… any
>> suggestions?
>>
>
> I have just spent some time tracing this through in windbg, and it seems
> that it wants to access offset 8 in my DMA_ADAPTER structure, which is
> outside the structure and into my own private data, and then becomes
> unstuck because of what it expects to find there (eg windows private
> data instead of mine). It later reads a null pointer from somewhere and
> then tries to access offset 0x88, which is where the crash occurs.
>
> Can I assume from this behaviour that a non-Microsoft driver supplied
> DMA_ADAPTER is not compatible with the crash dump (and maybe hibernate?)
> path? That would be pretty poor… maybe Microsoft had to do some
> trickery to make their DMA_ADAPTER work at HIGH_LEVEL?
>
> Or maybe I’m just making a stupid mistake somewhere?
>
> James
>
I’m not sure either, but WDK’s declaration of DMA_ADAPTER is
incomplete as
the actual structure (a.k.a. ADAPTER_OBJECT) also contains a private
member, so you cannot define it yourself. Drivers are supposed to call
IoGetDmaAdapter() to retrieve a pointer to the adapter object.
My driver is a bus driver and so has to have a DMA_ADAPTER for
enumerated devices (ndis, scsiport) to be able to do scatter gather DMA.
In all other respects it works really well, just not during a crash
dump.
ndis and scsiport both get my DMA_ADAPTER (presumably by IoGetDmaAdapter
or via QueryInterface), so that much is definitely working.
James
> >
> I have implemented a DMA_ADAPTER into my Xen drivers, and it has
allowed
> for some pretty impressive performance improvements due to the fact
that
> I can now work with sg lists.
>
> However, the crash dump path of my scsiport driver no longer works.
It
> crashes in hal!HalAllocateCrashDumpRegisters with 0xA (0x88,
0xD000001F,
> 0x0, …). This happens as a result of my call to
ScsiPortInitialize.
>
> None of my DMA_ADAPTER functions are even called though during the
crash
> dump path, so I don’t really know where to start looking… any
> suggestions?
>
I have just spent some time tracing this through in windbg, and it
seems
that it wants to access offset 8 in my DMA_ADAPTER structure, which is
outside the structure and into my own private data, and then becomes
unstuck because of what it expects to find there (eg windows private
data instead of mine). It later reads a null pointer from somewhere
and
then tries to access offset 0x88, which is where the crash occurs.
Can I assume from this behaviour that a non-Microsoft driver supplied
DMA_ADAPTER is not compatible with the crash dump (and maybe
hibernate?)
path? That would be pretty poor… maybe Microsoft had to do some
trickery to make their DMA_ADAPTER work at HIGH_LEVEL?
Or maybe I’m just making a stupid mistake somewhere?
I had been setting the size member of DMA_ADAPTER to sizeof(DMA_ADAPTER)
- sizeof(my private data). When I set it to just sizeof(DMA_ADAPTER),
windows stops assuming that there is extension data there, but now
doesn’t call my DMA_OPERATIONS routines at all during a crash dump. It
seems I can’t win…
James
Well, it would be very HARD for you to win, that’s for sure.
While the Windows architecture allows this, it’s never been clear to me if the DDK includes enough definitions and information to allow you to write an entirely unique bus driver, with its own DMA model, etc. That’s really what you’re doing when you attempt to create your own DMA_ADAPTER structure, after all, aren’t you?
Hmmmmm…
Peter
OSR
> [quote]
It seems I can’t win…
[/quote]
Well, it would be very HARD for you to win, that’s for sure.
While the Windows architecture allows this, it’s never been clear to
me if
the DDK includes enough definitions and information to allow you to
write
an entirely unique bus driver, with its own DMA model, etc. That’s
really
what you’re doing when you attempt to create your own DMA_ADAPTER
structure, after all, aren’t you?
Yes. I think the problems only started when I set the Size field of my
DMA_ADAPTER to a larger value than sizeof(DMA_ADAPTER). Windows took one
look at that and assumed that I must have the required secret sauce to
make things work, but obviously I don’t - it was just some of my own
private data I was storing at the end of my DMA_ADAPTER structure.
Having set the Size field back to sizeof(DMA_ADAPTER), windows doesn’t
seem to try and call HalAllocateCrashDumpRegisters (haven’t confirmed
that for sure), and so doesn’t crash in the same way anymore in the
crash dump path. It now crashes because the buffers I get in the
scsiport dump driver aren’t mapped, but that at least I can deal with.
From a brief disassembly of HalAllocateCrashDumpRegisters, it appears to
try and access a few members of an extended DMA_ADAPTER
(ADAPTER_OBJECT?) structure. The whole idea of implementing DMA_ADAPTER
was to avoid having to break rules in scsiport, so I’m not going to
pursue it any further.
James
The DMA_ADAPTER is embedded in an ADAPTER_OBJECT which
is determinedly undefined in the published WDK header files. This is too bad
and somebody from Microsoft should offer to define them for you so you can
complete your legitimate task of providing dump support.
Mark Roddy
On Sun, Feb 1, 2009 at 6:33 PM, James Harper
wrote:
> >
> >
> > Well, it would be very HARD for you to win, that’s for sure.
> >
> > While the Windows architecture allows this, it’s never been clear to
> me if
> > the DDK includes enough definitions and information to allow you to
> write
> > an entirely unique bus driver, with its own DMA model, etc. That’s
> really
> > what you’re doing when you attempt to create your own DMA_ADAPTER
> > structure, after all, aren’t you?
> >
>
> Yes. I think the problems only started when I set the Size field of my
> DMA_ADAPTER to a larger value than sizeof(DMA_ADAPTER). Windows took one
> look at that and assumed that I must have the required secret sauce to
> make things work, but obviously I don’t - it was just some of my own
> private data I was storing at the end of my DMA_ADAPTER structure.
> Having set the Size field back to sizeof(DMA_ADAPTER), windows doesn’t
> seem to try and call HalAllocateCrashDumpRegisters (haven’t confirmed
> that for sure), and so doesn’t crash in the same way anymore in the
> crash dump path. It now crashes because the buffers I get in the
> scsiport dump driver aren’t mapped, but that at least I can deal with.
>
> From a brief disassembly of HalAllocateCrashDumpRegisters, it appears to
> try and access a few members of an extended DMA_ADAPTER
> (ADAPTER_OBJECT?) structure. The whole idea of implementing DMA_ADAPTER
> was to avoid having to break rules in scsiport, so I’m not going to
> pursue it any further.
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
The DMA_ADAPTER is embedded in an ADAPTER_OBJECT which is determinedly
undefined in the published WDK header files. This is too bad and
somebody
from Microsoft should offer to define them for you so you can complete
your legitimate task of providing dump support.
That would be nice, but having something defined means that it then has
to be supported, and that means they can’t then modify it between
versions without providing a compatibility layer. It’s easier for
Microsoft just to ignore the problem 
Reading storport.h, there appears to be ‘DumpRegion’ and
‘RequestedDumpBufferSize’ members in the
‘PORT_CONFIGURATION_INFORMATION’ struct, an
‘SRB_FUNCTION_DUMP_POINTERS’, and a ‘MINIPORT_DUMP_POINTERS’, so I think
for storport this problem may be already solved. I get the impression
that Microsoft aren’t so concerned with supporting scsiport anymore.
That being said, feel free to surprise me Microsoft!
James
>for storport this problem may be already solved. I get the impression
that Microsoft aren’t so concerned with supporting scsiport anymore.
From what I know, SCSIPORT is deprecated and is going to be removed from Win7 (or maybe Win7 will be the last Windows with SCSIPORT.SYS, with development of the new SCSIPORT’s miniports strongly discouraged).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com