Does StorPortGetSystemAddress really works on Win7 x64 with 4GB Ra

[Mini UVC UAC]

Hi, All:
I'm developing a Storport driver and need get the virtual address of
Srb::DataBuffer. I used StorPortGetSystemAddress to get the virtual address.
It
works well under Win7 x64 with 2GB Ram, but failed under Win7 X64 with 4GB
Ram.

I used the dbgview to print the data after I copied it into the virtual
address, and used BusHound to check the data which our drivers returned. From
the dbgview's logfile, driver always return the correct data, but from the
BusHound's log info, the data sometimes match with the dbgview's logfile, and
sometimes don't match.

BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.

Anyone can give me some help to solve the issue? BTW: I have to use
virtual
address to copy data into Srb::DataBuffer because hardware limited. I have to
use Storport framework.

And I even suspect maybe whether it is the Microsoft stoport class
driver's bug ?

Thanks

[Maxim S. Shatskih]

Post by Mini UVC UAC
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.

Probably the storport's port registration info is not correct?

[Mini UVC UAC]

Hi, Maxim:
Thanks for your reply.
But would you please give me more details about "storport's port
registration info " ? what is is related with issue?
Thanks again;

Post by Maxim S. Shatskih

Post by Mini UVC UAC
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.

Probably the storport's port registration info is not correct?
--
Maxim S. Shatskih
Windows DDK MVP
http://www.storagecraft.com
.

[Mini UVC UAC]

Hi, Maxim & all:
Anyone meet the same issue?
who can give me some suggestion?

many thanks;

BR
Hardys

Post by Mini UVC UAC
Thanks for your reply.
But would you please give me more details about "storport's port
registration info " ? what is is related with issue?
Thanks again;

Post by Maxim S. Shatskih

Post by Mini UVC UAC
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.

Probably the storport's port registration info is not correct?
--
Maxim S. Shatskih
Windows DDK MVP
http://www.storagecraft.com
.

[eagersh]

On Jul 13, 2:14 am, Mini UVC UAC

     Anyone meet the same issue?
     who can give me some suggestion?
many thanks;
BR
Hardys

    Thanks for your reply.
    But would you please give me more details about "storport's port
registration info " ? what is is related with issue?
   Thanks again;

Post by Maxim S. Shatskih

  BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.

Probably the storport's port registration info is not correct?
--
Maxim S. Shatskih
Windows DDK MVP
http://www.storagecraft.com
.

Do you check a return value of StorPortGetSystemAddress?

Igor Sharovar

[Mini UVC UAC]

HI, Eagersh:

Thanks.
Of course, I have checked the result of StorPortGetSystemAddress, it
return STOR_STATUS_SUCCESS;

Anybody has other suggestions?

[Scott Noone]

Is this on a read operation? Could be dummy pages related:

http://msmvps.com/blogs/kernelmustard/archive/2005/05/04/45721.aspx

The end result is that when you copy data into the user data buffer the
result may not compare correctly to the original buffer.

-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Post by Mini UVC UAC
I'm developing a Storport driver and need get the virtual address of
Srb::DataBuffer. I used StorPortGetSystemAddress to get the virtual address.
It
works well under Win7 x64 with 2GB Ram, but failed under Win7 X64 with 4GB
Ram.
I used the dbgview to print the data after I copied it into the virtual
address, and used BusHound to check the data which our drivers returned. From
the dbgview's logfile, driver always return the correct data, but from the
BusHound's log info, the data sometimes match with the dbgview's logfile, and
sometimes don't match.
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.
Anyone can give me some help to solve the issue? BTW: I have to use
virtual
address to copy data into Srb::DataBuffer because hardware limited. I have to
use Storport framework.
And I even suspect maybe whether it is the Microsoft stoport class
driver's bug ?
Thanks

[Mini UVC UAC]

Hi, Scott Noone:

Thanks very much, But I can't understand clearly about the dummy page.
and if so, how to do to fix the issue in my storport driver?

Post by Scott Noone
http://msmvps.com/blogs/kernelmustard/archive/2005/05/04/45721.aspx
The end result is that when you copy data into the user data buffer the
result may not compare correctly to the original buffer.
-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Post by Mini UVC UAC
I'm developing a Storport driver and need get the virtual address of
Srb::DataBuffer. I used StorPortGetSystemAddress to get the virtual address.
It
works well under Win7 x64 with 2GB Ram, but failed under Win7 X64 with 4GB
Ram.
I used the dbgview to print the data after I copied it into the virtual
address, and used BusHound to check the data which our drivers returned. From
the dbgview's logfile, driver always return the correct data, but from the
BusHound's log info, the data sometimes match with the dbgview's logfile, and
sometimes don't match.
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.
Anyone can give me some help to solve the issue? BTW: I have to use
virtual
address to copy data into Srb::DataBuffer because hardware limited. I have to
use Storport framework.
And I even suspect maybe whether it is the Microsoft stoport class
driver's bug ?
Thanks

[Scott Noone]

"Mini UVC UAC" <***@discussions.microsoft.com> wrote in message
news:4FE83744-6CB1-4134-B20A-

Post by Mini UVC UAC
I can't understand clearly about the dummy page.

For simplicity, imagine that the page size of the architecture is a single
byte and the application has a four page virtually contiguous buffer:

[ ]
[ ]
[ ]
[ ]

When entirely valid, each of these maps to a single page of physical memory:

[ ] --> 20
[ ] --> 22
[ ] --> 40
[ ] --> 41

But, it might be possible that some of these pages are paged out to a file
on disk:

[ ] --> X
[ ] --> 22
[ ] --> 40
[ ] --> X

If the user then references this piece of memory, then the memory manager
needs to page the data back in and fix up the pointers. In this case it
would require two one byte I/Os, because the two pages in the middle are
valid and the memory manager can't overwrite them with whatever happens to
be on the disk.

Starting with Server03 (SP1?) the memory manager attempts to optimize this
case by sending a single I/O that will suck up both regions. The way that it
does this is by building an MDL with new pages for the two paged out regions
(N1 and N2) and then filling in the middle region by pointing both pages to
a single unused page. So, the MDL looks like this:

[N1][D][D][N2]

Say the buffer being read was, "1234" and the starting buffer sent down was,
"0000." As the four bytes were copied one by one into this buffer, it would
transform the following way:

0000
1000
1220
1330
1334

Because the middle two pages are the same page. And, in the end, the source
buffer wouldn't match the destination buffer.

Post by Mini UVC UAC
how to do to fix the issue in my storport driver?

It's not anything that you need to fix, I just wanted to make you aware of
it in case you're not really tracking a bug but an artifact of your
observation of the data.

HTH,

-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Post by Mini UVC UAC
Thanks very much, But I can't understand clearly about the dummy page.
and if so, how to do to fix the issue in my storport driver?

Post by Scott Noone
http://msmvps.com/blogs/kernelmustard/archive/2005/05/04/45721.aspx
The end result is that when you copy data into the user data buffer the
result may not compare correctly to the original buffer.
-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Post by Mini UVC UAC
I'm developing a Storport driver and need get the virtual address of
Srb::DataBuffer. I used StorPortGetSystemAddress to get the virtual address.
It
works well under Win7 x64 with 2GB Ram, but failed under Win7 X64 with 4GB
Ram.
I used the dbgview to print the data after I copied it into the virtual
address, and used BusHound to check the data which our drivers
returned.
From
the dbgview's logfile, driver always return the correct data, but from the
BusHound's log info, the data sometimes match with the dbgview's
logfile,
and
sometimes don't match.
BTW, if use the scsiport driver, it work ok both 2GB ram and 4GB ram under
Win7X64.
Anyone can give me some help to solve the issue? BTW: I have to use
virtual
address to copy data into Srb::DataBuffer because hardware limited. I
have
to
use Storport framework.
And I even suspect maybe whether it is the Microsoft stoport class
driver's bug ?
Thanks

[Maxim S. Shatskih]

Post by Scott Noone
Because the middle two pages are the same page. And, in the end, the source
buffer wouldn't match the destination buffer.

I can rephrase this in other words:

- some filters do the following: instead of generating their own new IRP/MDL for read, they monitor a read flow sent from the top and reuse these reads as their own reads (also provided the upper levels with a read).
- i.e. catch the read coming from the top, register the completion routine, send it down, and, in the C.R., look at the data being read (by the upper level's IRP) as the real data being read, to save the filter from the burden of creating its own read IRP/MDL.
- the "dummy pages" issue, which arise to its full glory in Vista+, prohibits this trick. Reason: the MDL from the top's read IRP can be very special and have aliased physical pages.
- so, you cannot trust the successul read IRPs in the completion routine to contain the read on-disk data. You can trust only in a case your code itself created this IRP/MDL initially.