Prev: How to Enable debug print in SCSI miniport driver
Next: How to define a writable WMI property ?
From: Scott Noone on 16 Jul 2010 10:33
"Mini UVC UAC" <MiniUVCUAC(a)discussions.microsoft.com> 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" <MiniUVCUAC(a)discussions.microsoft.com> wrote in message
news:4FE83744-6CB1-4134-B20A-E14DEF641017(a)microsoft.com...
> 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/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
>>
>>
>> "Mini UVC UAC" <MiniUVCUAC(a)discussions.microsoft.com> wrote in message
>> news:B04DE4CC-C47B-4475-9CA4-F45035EDC3AB(a)microsoft.com...
>> > 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
>> >
>> >
>> >
>> >
>> >
>> >
From: Maxim S. Shatskih on 16 Jul 2010 17:32
> 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
maxim(a)storagecraft.com
http://www.storagecraft.com

First  |  Prev  | 
Pages: 1 2
Prev: How to Enable debug print in SCSI miniport driver
Next: How to define a writable WMI property ?