From: Phillip Susi [phreak@iag.net] Sent: Friday, September 15, 2000 9:14 PM To: NT Developers Interest List Subject: [ntdev] RE: Large buffers It never reaches your driver because using METHOD_IN_DIRECT, the IO manager builds the MDL for you, which it is unable to do. I was not aware of the limit of 64 megs on an MDL, but the IO manager does have a limit on the number of pages it will lock into memory ( which an MDL does ) for IO. You can tune this number in the registry. If you switch to METHOD_NEITHER like someone already suggested, you should get the request, and then you will need to build your own MDL(s). Heck, with a data buffer size that large, you may not want to build MDLs and lock the pages in memory. If you take the user buffer from a METHOD_NEITHER call, you may want to lock down only smaller parts of the buffer at a time, and work on those. Better yet, why not just have the application send down 2 or 3 smaller buffers at a time in overlapped IO requests? Throughput should not suffer from the overhead of a few more IRPs that you need to process, and in fact, by not locking down huge swaths of memory at a time, performance may gain. Why do you feel you need to use such huge buffers anyway? At 11:41 AM 9/13/00 -0500, you wrote: >Mark: > The problem is it never REACHES the driver. The I/O manager is >bouncing it back. I should hear from MS today on this with a >(hopefully) definitive answer. > >Bill > >== SCSI Adapters & VirtualSCSI Target Mode Libs == >Advanced Storage Concepts, Inc. (409) 744-2129 >2720 Terminal Drive info@advstor.com >Galveston, TX 77554 USA www.virtualscsi.com > > > > > -----Original Message----- > > From: bounce-ntdev-168@lists.osr.com > > [mailto:bounce-ntdev-168@lists.osr.com]On Behalf Of Roddy, Mark > > Sent: Tuesday, September 12, 2000 4:03 PM > > To: NT Developers Interest List > > Subject: [ntdev] RE: Large buffers > > > > > > So you need to redefine the IOCTL to be method neither and > > then slide an MDL > > window across the buffer, or build a series of MDLs, or > > figure out how to > > build your own MDL that ignores the size field limitation. > > You would have to > > do this of course from some sort of highest level driver. > > > > > -----Original Message----- > > > From: Bill Casey [mailto:wjc@advstor.com] > > > Sent: Tuesday, September 12, 2000 4:56 PM > > > To: NT Developers Interest List > > > Subject: [ntdev] RE: Large buffers > > > > > > > > > Gary: > > > > > > FYI, the IOCTL with the large buffer never even gets to my > > driver; the > > > I/O manager returns it with an out of resources-type error. > > I thought > > > it might be because I didn't have enough MapRegisters > > > allocated but not > > > only isn't it that but I'm not even using an AdapterObject. > > > So I think > > > it something else - like the I/O manager just won't accept > > > buffers that > > > big, i.e. 64MB. > > > > > > Hate to say it but in some industries, seismic for example, > > 64MB is a > > > SMALL buffer. > > > > > > Bill > > > == SCSI Adapters & VirtualSCSI Target Mode Libs == > > > > > > > > > > > > > > > > > > I've been reading my 386 book about LDT, GDT, and segment > > > > descriptors. Ok, I > > > > know, the 386 is defunct, but that is the last hardware book > > > > I've had to > > > > buy, and code written for it will run on today's > > > > architecture. Hell we boot > > > > DOS 5 here on a PII all the time. If the PFN in some manner, > > > > closely relates > > > > to the segment base in the descriptor tables then, a 16 bit > > > > size field for > > > > the PFN can effectively address several Gig of memory. > > For instance, > > > > IoMapTransfer takes the next PFN in the MDL, and derives the > > > > base and limit > > > > (or size) of the segment from the LDT/GDT. > > > > > > > > Of course, that being the case, then Bill's problem may be > > > > more in the way > > > > he has defined the buffer and locked it down, and not in an > > > > arbitrary limit > > > > set by the OS. Which is what Mark has been saying. > > > > > > > > But again, that is still speculating (and wading into areas > > > outside my > > > > expertise). > > > > > > > > --- > > > > You are currently subscribed to ntdev as: wjc@advstor.com > > > > To unsubscribe send a blank email to > > leave-ntdev-247T@lists.osr.com > > > > > > > > > > > > > > > > > --- > > > You are currently subscribed to ntdev as: mark_roddy@stratus.com > > > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com > > > > > > > --- > > You are currently subscribed to ntdev as: wjc@advstor.com > > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com > > > > > > >--- >You are currently subscribed to ntdev as: phreak@iag.net >To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com -->Phillip Susi Phreak@iag.net --- You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com