Does StorPortGetSystemAddress really works on Win7 x64 with 4GB Ra

Hi, All:
I'm developing a Storport driver and need get the virtual address of
Srb:ataBuffer. 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:ataBuffer 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

> 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

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;

"Maxim S. Shatskih" wrote:

> > 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
>
> .
>

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

many thanks;

BR
Hardys

"Mini UVC UAC" wrote:

> 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;
>
> "Maxim S. Shatskih" wrote:
>
> > > 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
> >
> > .
> >

HI, Eagersh:

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

Anybody has other suggestions?

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

http://msmvps.com/blogs/kernelmustar.../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


"Mini UVC UAC" <> wrote in message
news:B04DE4CC-C47B-4475-9CA4-...
> Hi, All:
> I'm developing a Storport driver and need get the virtual address of
> Srb:ataBuffer. 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:ataBuffer 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
>
>
>
>
>
>

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?

"Scott Noone" wrote:

> Is this on a read operation? Could be dummy pages related:
>
> http://msmvps.com/blogs/kernelmustar.../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
>
>
> "Mini UVC UAC" <> wrote in message
> news:B04DE4CC-C47B-4475-9CA4-...
> > Hi, All:
> > I'm developing a Storport driver and need get the virtual address of
> > Srb:ataBuffer. 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:ataBuffer 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" <> wrote in message
news:4FE83744-6CB1-4134-B20A-
>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.

>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


"Mini UVC UAC" <> wrote in message
news:4FE83744-6CB1-4134-B20A-...
> 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?
>
> "Scott Noone" wrote:
>
>> Is this on a read operation? Could be dummy pages related:
>>
>> http://msmvps.com/blogs/kernelmustar.../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
>>
>>
>> "Mini UVC UAC" <> wrote in message
>> news:B04DE4CC-C47B-4475-9CA4-...
>> > Hi, All:
>> > I'm developing a Storport driver and need get the virtual address
>> > of
>> > Srb:ataBuffer. 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:ataBuffer 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
>> >
>> >
>> >
>> >
>> >
>> >

> 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.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com