invalid MdlAddress

Hi All,

I entered a question several days ago that I probably didn’t specify well
enough. I’m attempting to use IOCTLs to perform direct I/O to DDR ram on a
PCI busmaster card. My issue at this time is not how to do the DMA ops, but
how to set up and properly use the IOCTLs.

A user app would call my API to perform the various ops.

IOCTL declarations:

#define V3_IOCTL_READ CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x800, \
METHOD_OUT_DIRECT, \
FILE_ANY_ACCESS);

#define V3_IOCTL_WRITE CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x801, \
METHOD_IN_DIRECT, \
FILE_ANY_ACCESS);

User app code:

hV3Device = CreateFile(“\\.\v3Device”,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);

if(hV3Device == INVALID_HANDLE_VALUE)
{
// ERROR, we could not open the device!!!
printf(“ERROR: We could not open the device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

ddr_data = 0;
// Read a quad word from the device
if(DeviceIoControl(hV3Device,
V3_IOCTL_READ,
&memory_address,
sizeof(memory_address),
&ddr_data,
sizeof(ddr_data), // one quad
word
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}
where:
typedef __int64 longlong;
longlong ddr_data;
unsigned int memory_address = 0;

The IRP thats issued for this read has Irp->MdlAddress == 0x00000000. This
of course quickly results in an access violation.

I know you guys out there have lots of experience working code such as this.
Can anyone suggest what may be wrong with the syntax i’ve used? I know
that one way to get a 0x00000000 in MdlAddress is to have a zero length
output buffer specified, but I dont believe I have that case here. This is
an NT4 style driver written for w2k.

Thanks in advance,

Howard Keller

Howard, if you are doing short IOs (like less than a couple hundred bytes) I
personally would opt for the simple course and use METHOD_BUFFERED.
Probably not all that much more system overhead than doing it “right” for
that little data. If of course you are doing larger transfers or this is a
gigibit fiber card or some such, then I guess you need to do it this way.

Loren

However he is having a similar problem using method buffered.

=====================
Mark Roddy

-----Original Message-----
From: Loren Wilton [mailto:xxxxx@earthlink.net]
Sent: Thursday, February 12, 2004 10:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] invalid MdlAddress

Howard, if you are doing short IOs (like less than a couple
hundred bytes) I personally would opt for the simple course
and use METHOD_BUFFERED.
Probably not all that much more system overhead than doing it
“right” for that little data. If of course you are doing
larger transfers or this is a gigibit fiber card or some
such, then I guess you need to do it this way.

Loren


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

Loren,

Turns out that a data transfer could be as large as 2 mb.

Howard
“Loren Wilton” wrote in message news:xxxxx@ntdev…
> Howard, if you are doing short IOs (like less than a couple hundred bytes)
I
> personally would opt for the simple course and use METHOD_BUFFERED.
> Probably not all that much more system overhead than doing it “right” for
> that little data. If of course you are doing larger transfers or this is
a
> gigibit fiber card or some such, then I guess you need to do it this way.
>
> Loren
>
>

Mark,

Actually I have succeeded in using METHOD_BUFFERED to read the BAR0
registers using the same input/output buffer.

But back to this problem, Looking at the IRP that was sent to me, windbg
says (looking at the Irp in locals) that the flags associated with the
operation that has the all zeros MdlAddress has a flag value of 0x70 which
appears to be saying IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER |
IRP_INPUT_OPERATION. Does this imply that they are confused about the IOCTL
? I would think that IRP_BUFFERED_IO may cause the MdlAddress to be zero.
What do you think?

Thanks,

Howard

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> However he is having a similar problem using method buffered.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Loren Wilton [mailto:xxxxx@earthlink.net]
> > Sent: Thursday, February 12, 2004 10:55 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] invalid MdlAddress
> >
> > Howard, if you are doing short IOs (like less than a couple
> > hundred bytes) I personally would opt for the simple course
> > and use METHOD_BUFFERED.
> > Probably not all that much more system overhead than doing it
> > “right” for that little data. If of course you are doing
> > larger transfers or this is a gigibit fiber card or some
> > such, then I guess you need to do it this way.
> >
> > Loren
> >
> >
> > —
> > 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
> >
>

METHOD_DIRECT_* requests allocate a system buffer for the input
parameters. This is all that IRP_BUFFERED_IO implies.

the interesting one is IRP_INPUT_OPERATION. the current code only sets
that for a METHOD_BUFFERED operation. This does imply that you’re
somehow providing the wrong I/O control code.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Thursday, February 12, 2004 10:29 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] invalid MdlAddress

Mark,

Actually I have succeeded in using METHOD_BUFFERED to read the BAR0
registers using the same input/output buffer.

But back to this problem, Looking at the IRP that was sent to me, windbg
says (looking at the Irp in locals) that the flags associated with the
operation that has the all zeros MdlAddress has a flag value of 0x70
which appears to be saying IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER |
IRP_INPUT_OPERATION. Does this imply that they are confused about the
IOCTL ? I would think that IRP_BUFFERED_IO may cause the MdlAddress to
be zero.
What do you think?

Thanks,

Howard

“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> However he is having a similar problem using method buffered.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Loren Wilton [mailto:xxxxx@earthlink.net]
> > Sent: Thursday, February 12, 2004 10:55 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] invalid MdlAddress
> >
> > Howard, if you are doing short IOs (like less than a couple hundred
> > bytes) I personally would opt for the simple course and use
> > METHOD_BUFFERED.
> > Probably not all that much more system overhead than doing it
> > “right” for that little data. If of course you are doing larger
> > transfers or this is a gigibit fiber card or some such, then I guess

> > you need to do it this way.
> >
> > Loren
> >
> >
> > —
> > 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
> >
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Very informative. I finally discovered my problem this weekend. Seems like
my IOCTLs were getting redefined. I fixed the problem and now I’m getting
the MdlAddress correctly. The operation WAS being interpreted as a
METHOD_BUFFERED.

I appreciate all of your help (everyone)

Howard

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
METHOD_DIRECT_* requests allocate a system buffer for the input
parameters. This is all that IRP_BUFFERED_IO implies.

the interesting one is IRP_INPUT_OPERATION. the current code only sets
that for a METHOD_BUFFERED operation. This does imply that you’re
somehow providing the wrong I/O control code.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Thursday, February 12, 2004 10:29 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] invalid MdlAddress

Mark,

Actually I have succeeded in using METHOD_BUFFERED to read the BAR0
registers using the same input/output buffer.

But back to this problem, Looking at the IRP that was sent to me, windbg
says (looking at the Irp in locals) that the flags associated with the
operation that has the all zeros MdlAddress has a flag value of 0x70
which appears to be saying IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER |
IRP_INPUT_OPERATION. Does this imply that they are confused about the
IOCTL ? I would think that IRP_BUFFERED_IO may cause the MdlAddress to
be zero.
What do you think?

Thanks,

Howard

“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> However he is having a similar problem using method buffered.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Loren Wilton [mailto:xxxxx@earthlink.net]
> > Sent: Thursday, February 12, 2004 10:55 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] invalid MdlAddress
> >
> > Howard, if you are doing short IOs (like less than a couple hundred
> > bytes) I personally would opt for the simple course and use
> > METHOD_BUFFERED.
> > Probably not all that much more system overhead than doing it
> > “right” for that little data. If of course you are doing larger
> > transfers or this is a gigibit fiber card or some such, then I guess

> > you need to do it this way.
> >
> > Loren
> >
> >
> > —
> > 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
> >
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com