ScsiPortGetPhysicalAddress returns length 0 in 64 -bit windows 2003 standard sever with SP1

Hi All,

I am facing a problem while porting SCSI miniport to windows 2003 AMD 64-bit. Scsiport behavior looks very strange.

In order to build the scatter gather list I am calling the ScsiPortGetPhysicalAddress and passing the srb->databuffer. ScsiPortGetPhysicalAddress call always fails by returning the length field as zero. This behavior is only for the databuffer field when I pass the address of SenseInfoBuffer for ScsiPortGetPhysicalAddress its returning a physical address and valid length.

As per the DDK documentation I am setting the following parameters in the findadaptor but still I couldn’t figure out why it’s failing.

These are the parameters values set in the findadaptor callback.

ConfigInfo->Dma32BitAddresses = FALSE;

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED;

ConfigInfo->DmaWidth = Width32Bits;

I am clueless on what could be the problem. Any help on debugging this is highly appreciated.

Any help on what other configurable variables affect the ScsiPortGetPhysicalAddress behavior will be helpful.

Thanks,

Karthik


Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com

Why are you setting MapBuffers = TRUE? Have you tried to set it to FALSE?
I don’t know why this should make a difference in this case, but I’d try
it anyway. And setting this to TRUE is not a good idea from the
performance perspective.

If this fails, paste your exact call to ScsiPortGetPhysicalAddress. Are
you possibly not passing in the SRB address on this particular call?

Jerry.

xxxxx@lists.osr.com wrote on 08/31/2005 07:05:57 AM:

Hi All,
I am facing a problem while porting SCSI miniport to windows 2003
AMD 64-bit. Scsiport behavior looks very strange.

In order to build the scatter gather list I am calling the
ScsiPortGetPhysicalAddress and passing the srb->databuffer.
ScsiPortGetPhysicalAddress call always fails by returning the length
field as zero. This behavior is only for the databuffer field when I
pass the address of SenseInfoBuffer for ScsiPortGetPhysicalAddress
its returning a physical address and valid length.
As per the DDK documentation I am setting the following parameters
in the findadaptor but still I couldn?t figure out why it?s failing.

These are the parameters values set in the findadaptor callback.
ConfigInfo->Dma32BitAddresses = FALSE;
ConfigInfo->MapBuffers = TRUE;
ConfigInfo->NeedPhysicalAddresses = TRUE;
ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED;
ConfigInfo->DmaWidth = Width32Bits;
I am clueless on what could be the problem. Any help on debugging
this is highly appreciated.
Any help on what other configurable variables affect the
ScsiPortGetPhysicalAddress behavior will be helpful.
Thanks,
Karthik

Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com — Questions? First check the Kernel
Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are
currently subscribed to ntdev as: xxxxx@attotech.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Is your device a virtual device, that is, no actual hardware?


James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no rights.

“Karthik M” wrote in message news:xxxxx@ntdev…
Hi All,

I am facing a problem while porting SCSI miniport to windows 2003 AMD 64-bit. Scsiport behavior looks very strange.

In order to build the scatter gather list I am calling the ScsiPortGetPhysicalAddress and passing the srb->databuffer. ScsiPortGetPhysicalAddress call always fails by returning the length field as zero. This behavior is only for the databuffer field when I pass the address of SenseInfoBuffer for ScsiPortGetPhysicalAddress its returning a physical address and valid length.

As per the DDK documentation I am setting the following parameters in the findadaptor but still I couldn’t figure out why it’s failing.

These are the parameters values set in the findadaptor callback.

ConfigInfo->Dma32BitAddresses = FALSE;

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED;

ConfigInfo->DmaWidth = Width32Bits;

I am clueless on what could be the problem. Any help on debugging this is highly appreciated.

Any help on what other configurable variables affect the ScsiPortGetPhysicalAddress behavior will be helpful.

Thanks,

Karthik

------------------------------------------------------------------------------
Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com

Are you setting Configinfo->Master? I don’t think
ScsiPortGetPhysicalAddress works for SRB databuffer addresses unless
your device support bus mastering DMA…

/simgr


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Karthik M
Sent: Wednesday, August 31, 2005 7:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ScsiPortGetPhysicalAddress returns length 0 in 64 -bit
windows 2003 standard sever with SP1

Hi All,

I am facing a problem while porting SCSI miniport to windows 2003 AMD
64-bit. Scsiport behavior looks very strange.

In order to build the scatter gather list I am calling the
ScsiPortGetPhysicalAddress and passing the srb->databuffer.
ScsiPortGetPhysicalAddress call always fails by returning the length
field as zero. This behavior is only for the databuffer field when I
pass the address of SenseInfoBuffer for ScsiPortGetPhysicalAddress its
returning a physical address and valid length.

As per the DDK documentation I am setting the following parameters in
the findadaptor but still I couldn’t figure out why it’s failing.

These are the parameters values set in the findadaptor callback.

ConfigInfo->Dma32BitAddresses = FALSE;

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED;

ConfigInfo->DmaWidth = Width32Bits;

I am clueless on what could be the problem. Any help on debugging this
is highly appreciated.

Any help on what other configurable variables affect the
ScsiPortGetPhysicalAddress behavior will be helpful.

Thanks,

Karthik


Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com — Questions? First check the Kernel
Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are
currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Driver requires to access data buffers that’s the reason for setting the MapBuffers as TRUE. This driver works perfectly fine in the 32-bit windows, the whole issue arises during porting it to 64-bit windows.

The changes made to the miniport driver for 64 bit version are is that in the find adaptor callback, I am setting these following values in 64-bit mode

ConfigInfo->Master = TRUE;

ConfigInfo->Dma32BitAddresses = FALSE; // IN 32 bit version this was true

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED; // in 32 bit version this field was not there.

ConfigInfo->DmaWidth = Width32Bits;

ConfigInfo->BufferAccessScsiPortControlled = TRUE;

This is the code segment which is failing.

pvDevExt is the HwDeviceExtension pointer from the findadaptor call

Srb is the Srb pointer and length is local variable.

BufferVa = Srb->DataBuffer;

physAddr= ScsiPortGetPhysicalAddress(pvDevExt, Srb, BufferVa, &length);

I also traced the disassembly of ScsiPortGetPhysicalAddress() function. and found that its checking for a flag in the following location

This is the path taken within ScsiPortGetPhysicalAddress.

mov r10, [rcx-0x8] ( where rcx was the PDevExt)

.

.

.

cmp byte ptr [r10 + 0x48a],0x0

And this cmp is zero and hence its assigning 0xffffffff to the physical address low part and ScsiPortGetPhysicalAddress function returns without mapping the physical address of the virtual address.

All I could understand is there is some flag which is not set because of which this failure and I don’t know what is that flag.

Any pointer on this is highly appreciated.

Karthik

xxxxx@attotech.com wrote:
Why are you setting MapBuffers = TRUE? Have you tried to set it to FALSE?
I don’t know why this should make a difference in this case, but I’d try
it anyway. And setting this to TRUE is not a good idea from the
performance perspective.

If this fails, paste your exact call to ScsiPortGetPhysicalAddress. Are
you possibly not passing in the SRB address on this particular call?

Jerry.

xxxxx@lists.osr.com wrote on 08/31/2005 07:05:57 AM:

Hi All,
I am facing a problem while porting SCSI miniport to windows 2003
AMD 64-bit. Scsiport behavior looks very strange.

In order to build the scatter gather list I am calling the
ScsiPortGetPhysicalAddress and passing the srb->databuffer.
ScsiPortGetPhysicalAddress call always fails by returning the length
field as zero. This behavior is only for the databuffer field when I
pass the address of SenseInfoBuffer for ScsiPortGetPhysicalAddress
its returning a physical address and valid length.
As per the DDK documentation I am setting the following parameters
in the findadaptor but still I couldn?t figure out why it?s failing.

These are the parameters values set in the findadaptor callback.
ConfigInfo->Dma32BitAddresses = FALSE;
ConfigInfo->MapBuffers = TRUE;
ConfigInfo->NeedPhysicalAddresses = TRUE;
ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED;
ConfigInfo->DmaWidth = Width32Bits;
I am clueless on what could be the problem. Any help on debugging
this is highly appreciated.
Any help on what other configurable variables affect the
ScsiPortGetPhysicalAddress behavior will be helpful.
Thanks,
Karthik

Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com — Questions? First check the Kernel
Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are
currently subscribed to ntdev as: xxxxx@attotech.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


Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com

I think the test indicates that SCSIPORT believes your device doesn’t do
master DMA; are you setting ConfigInfo->ScatterGather? If you don’t
specify this, then the HAL has to allocate map registers and it’s
possible that the Max Transfer Length you are specifying is so large
that this fails.

/simgr


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Karthik M
Sent: Thursday, September 01, 2005 5:30 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ScsiPortGetPhysicalAddress returns length 0 in 64
-bit windows 2003 standard sever with SP1

Driver requires to access data buffers that’s the reason for setting the
MapBuffers as TRUE. This driver works perfectly fine in the 32-bit
windows, the whole issue arises during porting it to 64-bit windows.

The changes made to the miniport driver for 64 bit version are is that
in the find adaptor callback, I am setting these following values in
64-bit mode

ConfigInfo->Master = TRUE;

ConfigInfo->Dma32BitAddresses = FALSE; // IN 32 bit version this was
true

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED; // in 32
bit version this field was not there.

ConfigInfo->DmaWidth = Width32Bits;

ConfigInfo->BufferAccessScsiPortControlled = TRUE;

This is the code segment which is failing.

pvDevExt is the HwDeviceExtension pointer from the findadaptor call

Srb is the Srb pointer and length is local variable.

BufferVa = Srb->DataBuffer;

physAddr= ScsiPortGetPhysicalAddress(pvDevExt, Srb, BufferVa, &length);

I also traced the disassembly of ScsiPortGetPhysicalAddress() function.
and found that its checking for a flag in the following location

This is the path taken within ScsiPortGetPhysicalAddress.

mov r10, [rcx-0x8] ( where rcx was the PDevExt)

.

.

.

cmp byte ptr [r10 + 0x48a],0x0

And this cmp is zero and hence its assigning 0xffffffff to the physical
address low part and ScsiPortGetPhysicalAddress function returns without
mapping the physical address of the virtual address.

All I could understand is there is some flag which is not set because of
which this failure and I don’t know what is that flag.

Any pointer on this is highly appreciated.

Karthik

xxxxx@attotech.com wrote:

Why are you setting MapBuffers = TRUE? Have you tried to set it
to FALSE?
I don’t know why this should make a difference in this case, but
I’d try
it anyway. And setting this to TRUE is not a good idea from the
performance perspective.

If this fails, paste your exact call to
ScsiPortGetPhysicalAddress. Are
you possibly not passing in the SRB address on this particular
call?

Jerry.

xxxxx@lists.osr.com wrote on 08/31/2005 07:05:57
AM:

Hi All,
> I am facing a problem while porting SCSI miniport to windows
2003
> AMD 64-bit. Scsiport behavior looks very strange.
>
> In order to build the scatter gather list I am calling the
> ScsiPortGetPhysicalAddress and passing the srb->databuffer.
> ScsiPortGetPhysicalAddress call always fails by returning the
length
> field as ze! ro. This behavior is only for the databuffer
field when I
> pass the address of SenseInfoBuffer for
ScsiPortGetPhysicalAddress
> its returning a physical address and valid length.
> As per the DDK documentation I am setting the following
parameters
> in the findadaptor but still I couldn?t figure out why it?s
failing.
>
> These are the parameters values set in the findadaptor
callback.
> ConfigInfo->Dma32BitAddresses = FALSE;
> ConfigInfo->MapBuffers = TRUE;
> ConfigInfo->NeedPhysicalAddresses = TRUE;
> ConfigInfo->Dma64BitAddresses |=
SCSI_DMA64_MINIPORT_SUPPORTED;
> ConfigInfo->DmaWidth = Width32Bits;
> I am clueless on what could be the problem. Any help on
debugging
> this is highly appreciated.
> Any help on what other configurable variables affect the
> ScsiPortGetPhysicalAddress behavior will be helpful.
> Thanks,
> Karthik
>
> Yahoo! India Matrimony: Find your partner online.
> Go to http://yahoo.shaadi.com — Questions? First check the
Kernel
> Driver FAQ at http://www.osronline.com/article.cfm?id=256 You
are
> currently subscribed to ntdev as: xxxxx@attotech.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


Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com — Questions? First check the Kernel
Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are
currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Actually, I bet this driver does NOT work “perfectly fine” in 32-bit
windows - ever tried it on PAE systems with > 4GB of memory? If you
didn’t support 64-bit DMA in 32-bit Windows, why would a change to the
virtual address (which has no impact on the physical address space of
the box) have anything to do with your ability to access different
physical addresses?

Remember: 32-bit Windows runs on 36-bit physical systems. 64-bit
Windows runs on 48-bit physical systems (currently). The ability of
your device to support scatter/gather, bus mastering, and > 32-bit
physical addresses is an attribute of the device, not of the version of
Windows on which you are running. So you need to set these values based
upon what your device supports, not on what Windows version you are
running - if you find yourself changing fields

Given what you’ve shown thus far, the failure appears to be related to
the fact that the allocation of the DMA adapter object for your device
was not done (or failed) for some reason. Thus, the real problem occurs
long before that check is done.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Karthik M
Sent: Thursday, September 01, 2005 5:30 AM
To: ntdev redirect
Subject: Re: [ntdev] ScsiPortGetPhysicalAddress returns length 0 in 64
-bit windows 2003 standard sever with SP1

Driver requires to access data buffers that’s the reason for setting the
MapBuffers as TRUE. This driver works perfectly fine in the 32-bit
windows, the whole issue arises during porting it to 64-bit windows.

The changes made to the miniport driver for 64 bit version are is that
in the find adaptor callback, I am setting these following values in
64-bit mode

ConfigInfo->Master = TRUE;

ConfigInfo->Dma32BitAddresses = FALSE; // IN 32 bit version this was
true

ConfigInfo->MapBuffers = TRUE;

ConfigInfo->NeedPhysicalAddresses = TRUE;

ConfigInfo->Dma64BitAddresses |= SCSI_DMA64_MINIPORT_SUPPORTED; // in 32
bit version this field was not there.

ConfigInfo->DmaWidth = Width32Bits;

ConfigInfo->BufferAccessScsiPortControlled = TRUE;

This is the code segment which is failing.

pvDevExt is the HwDeviceExtension pointer from the findadaptor call

Srb is the Srb pointer and length is local variable.

BufferVa = Srb->DataBuffer;

physAddr= ScsiPortGetPhysicalAddress(pvDevExt, Srb, BufferVa, &length);

I also traced the disassembly of ScsiPortGetPhysicalAddress() function.
and found that its checking for a flag in the following location

This is the path taken within ScsiPortGetPhysicalAddress.

mov r10, [rcx-0x8] ( where rcx was the PDevExt)

.

.

.

cmp byte ptr [r10 + 0x48a],0x0

And this cmp is zero and hence its assigning 0xffffffff to the physical
address low part and ScsiPortGetPhysicalAddress function returns without
mapping the physical address of the virtual address.

All I could understand is there is some flag which is not set because of
which this failure and I don’t know what is that flag.

Any pointer on this is highly appreciated.

Karthik

xxxxx@attotech.com wrote:

Why are you setting MapBuffers = TRUE? Have you tried to set it
to FALSE?
I don’t know why this should make a difference in this case, but
I’d try
it anyway. And setting this to TRUE is not a good idea from the
performance perspective.

If this fails, paste your exact call to
ScsiPortGetPhysicalAddress. Are
you possibly not passing in the SRB address on this particular
call?

Jerry.

xxxxx@lists.osr.com wrote on 08/31/2005 07:05:57
AM:

Hi All,
> I am facing a problem while porting SCSI miniport to windows
2003
> AMD 64-bit. Scsiport behavior looks very strange.
>
> In order to build the scatter gather list I am calling the
> ScsiPortGetPhysicalAddress and passing the srb->databuffer.
> ScsiPortGetPhysicalAddress call always fails by returning the
length
> field as zero. This behavior is only for the databuffer field
when I
> pass the address of SenseInfoBuffer for
ScsiPortGetPhysicalAddress
> its returning a physical address and valid length.
> As per the DDK documentation I am setting the following
parameters
> in the findadaptor but still I couldn?t figure out why it?s
failing.
>
> These are the parameters values set in the findadaptor
callback.
> ConfigInfo->Dma32BitAddresses = FALSE;
> ConfigInfo->MapBuffers = TRUE;
> ConfigInfo->NeedPhysicalAddresses = TRUE;
> ConfigInfo->Dma64BitAddresses |=
SCSI_DMA64_MINIPORT_SUPPORTED;
> ConfigInfo->DmaWidth = Width32Bits;
> I am clueless on what could be the problem. Any help on
debugging
> this is highly appreciated.
> Any help on what other configurable variables affect the
> ScsiPortGetPhysicalAddress behavior will be helpful.
> Thanks,
> Karthik
>
> Yahoo! India Matrimony: Find your partner online.
> Go to http://yahoo.shaadi.com — Questions? First check the
Kernel
> Driver FAQ at http://www.osronline.com/article.cfm?id=256 You
are
> currently subscribed to ntdev as: xxxxx@attotech.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


Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com — 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

>Remember: 32-bit Windows runs on 36-bit physical systems.? 64-bit Windows

runs on 48-bit physical systems (currently).? The ability of your device to
support scatter/gather, bus mastering, and > 32-bit physical addresses is
an attribute of the device, not of the version of Windows on which you are
running.? So you need to set these values based upon what your device
supports, not on what Windows version you are running ? if you find
yourself changing fields

This reminded me of a question. Is there anyway to TEST a driver on 32-bit
Windows is correctly working with physical addresses above 4GB. I believe
64-bit Windows has a boot.ini option /NOLOMEM. Also is there any way to TEST
that a driver is correctly using a DMA adapter object, specifically is there
a way to force bounce buffer and/or AMD IOMMU use?

Also, is there any way to query when MDL page frames will not always be
matching physical addresses? As in I fail DriverEntry if I detect the
current system will need translated addresses sometimes. The driver is not
for use on arbitrary hardware, so bending the rules a bit may not be a
problem. It would be nice to gracefully fail if the assumptions that allow
bent rules are not met.

The problem comes up because I have a higher level driver (like a network
transport) that needs to embed physical addresses in data that’s passed to
lower level drivers, and there is no DMA adapter object available in the
higher level driver. The actual hardware is 64-bit physical address capable,
so am not sure bounce buffers or IOMMU will ever be needed. Theoretically, I
suppose a bridge could translate the 64-bit physical address presented by
the device to a different 64-bit physical address in memory, but is this
ever done?

A useful metaphor that describes things might be device that uses an NDIS
miniport to exchange packets with the TCP driver. A higher level driver can
open a TCP connection to a controller on the device and ask the device to do
bus master transfers. The driver sending and receiving control TCP data
streams needs the physical addresses of application buffers passed in MDL’s.
The NDIS driver can’t do bus translation, as it’s just passing packets to
the control interface. The high level driver can’t really create an adapter
object, as he has no idea what bus the device is even on. How on earth would
you architect a “clean” driver for such a device?

  • Jan