Hello
I’m modifying a 1394a driver used to control a device for receiving fast
isochronous packets. I’m working on a win2k laptop with a builtin
FireWire and as we updated the SP1 to SP4 because of security reasons, I
could not allocate resources anymore (using
REQUEST_ISOCH_ALLOCATE_RESOURCES). In the DDK I read that it is
necessary to ask for the local host capabilities first and to ensure
that the used flags are set. OK, I implemented the call to find out
these capabilities:
I’m using a modified version of the 1394diag:
First I fill out the IRB structure:
pIrb->FunctionNumber = REQUEST_GET_LOCAL_HOST_INFO;
pIrb->u.GetLocalHostInformation.nLevel = GET_HOST_CAPABILITIES;
pIrb->u.GetLocalHostInformation.Information =
Irp->AssociatedIrp.SystemBuffer;
// of course with checking the length of the buffer first!
and then a call to the the “submit routine”:
t1394Diag_SubmitIrpSynch(); // unchanged from 1394diag
there is a call to the 1394OHCI driver (or at least I assume that this
driver will be called):
IoCallDriver(DeviceObject, Irp);
And exactely at this point I get a page fault !!! Why!!!
Maybe it’s because it is friday afternoon already and I cannot see the
simplest thing anymore.
I’m greatful for every hint!
Thanks
Daniel
PS: Actually I tried the same driver on a winXP desktop with a pci-1394a
controller card, but there I just get a STATUS_NOT_SUPPORTED error on
the same position?! weird.
> I’m modifying a 1394a driver used to control a device for receiving fast
isochronous packets. I’m working on a win2k laptop with a builtin
FireWire and as we updated the SP1 to SP4 because of security reasons, I
could not allocate resources anymore (using
REQUEST_ISOCH_ALLOCATE_RESOURCES). In the DDK I read that it is
necessary to ask for the local host capabilities first and to ensure
that the used flags are set. OK, I implemented the call to find out
these capabilities:
I’m using a modified version of the 1394diag:
In the change from sp1 to sp2 MS decided that the 1394 driver would
not respond to user mode IRPs (for some or all calls-I don’t
remember). Anyone reusing user mode IRPs to get work done (as was done
in 1394diag would suddenly get STATUS_NOT_SUPPORTED (I think). The fix
is to create your own kernel mode IRP to do the dirty work (can you
just re-label the user mode IRP?).
Can’t help you with the page fault.
Robert Newton
Dear Robert
Thanks very much for the hint. It was really useful! Indeed the 1394diag
sample uses a user mode IRP and gets therefor a STATUS_NOT_SUPPORTED and
I didn’t change that part as I copy-pasted it to my driver (“don’t touch
a working system”, as Murphy used to say…). As I changed it to a
kernel mode IRP (I didn’t know before that there are two kind of
IRP’s…) as it is provided on the 1394diag example in the WinXP DDK it
worked perfectly! I think this is rather strange, what sense does it
make NOT to serve a user mode IRP only a kernel mode IRP? For what is
this difference user mode - kernel mode IRP anyway?
So, I assume that the problem in allocating isochronous resources with
the newer SP’s of win2k and WinXP is propably the same (I also get a
STATUS_NOT_SUPPORTED). At least I saw that in the diag sample in
t1394_IsochAllocateResources() also a kernel mode IRP is created. I will
test this immediately now!
The unfair thing is that I didn’t find any description of that
requirement of a “kernel mode IRP” in the DDK description. From where
should one know that?
OK I know it now and I’m happy with it!
Thanks again!
Regards
Daniel
Robert Newton wrote:
>I’m modifying a 1394a driver used to control a device for receiving fast
>isochronous packets. I’m working on a win2k laptop with a builtin
>FireWire and as we updated the SP1 to SP4 because of security reasons, I
>could not allocate resources anymore (using
>REQUEST_ISOCH_ALLOCATE_RESOURCES). In the DDK I read that it is
>necessary to ask for the local host capabilities first and to ensure
>that the used flags are set. OK, I implemented the call to find out
>these capabilities:
>
>I’m using a modified version of the 1394diag:
In the change from sp1 to sp2 MS decided that the 1394 driver would
not respond to user mode IRPs (for some or all calls-I don’t
remember). Anyone reusing user mode IRPs to get work done (as was done
in 1394diag would suddenly get STATUS_NOT_SUPPORTED (I think). The fix
is to create your own kernel mode IRP to do the dirty work (can you
just re-label the user mode IRP?).
Can’t help you with the page fault.
Robert Newton
[snip]
Hi, since you seem to be using an older DDK which uses usermode IRPs, I just wanted to mention that should the flag RESOURCE_BUFFERS_CIRCULAR be present in your DDK, DO NOT USE IT, as it is horribly buggy. Bill McKenzie pointed this out to the group sometime in the past. I’m not sure at all if you are using this flag, but I just wanted to point it out just in case. In fact, later DDKs have removed that flag.
Bill Mckenzie wrote a nice series of 1394 articles which you can see in the archives at http://www.wd-3.com/ (one is a primer for isoch transfers, should you be interested- he also warns about this flag in that article).
good luck,
Philip Lukidis
Open your e-mail without having to worry about viruses with MSN Premium: Join now and get the first two months FREE*
>I think this is rather strange, what sense does it
make NOT to serve a user mode IRP only a kernel mode IRP? For what is
this difference user mode - kernel mode IRP anyway?
User-mode ioctls are received through IRP_MJ_DEVICE_CONTROL and kernel mode
ioctls are received through IRP_MJ_INTERNAL_DEVICE_CONTROL (they can be
sent/received through IRP_MJ_DEVICE_CONTROL too). So that’s how you can
differentiate them. The RequestorMode field or the IRP structure also
indicates whether the originator is kernel-mode or user-mode.
And for the reason why they do this differentiation, well, it might be for
many reasons; one being that if you allocate resources or bandwidth and not
free them appropriately, the driver might not be designed to free them
automatically, thus creating memory leaks and such. Having kernel-only
ioctls also increases the security… Since isoch is something you can’t
really do efficiently from user-mode (considering you’re always executing
PASSIVE), it makes sense that only drivers can access that functionality.
As you probably know, it is possible to sending async commands from
user-mode.
My 2 cents,
Mat
OK, thanks for all the hints! I actually don’t need the circular flag.
But I’m using the 1394diag sample from the Win2k DDK and now it seems
that I have to change all user mode IRP’s to kernel IRP’s which are
quite a few. Although I don’t really see the sense, because if I write a
driver I also write the API and the application and this thing just
makes life more complicated, but whatever, thanks for your answers anyway.
regards
Daniel
Mathieu Routhier wrote:
>I think this is rather strange, what sense does it
>make NOT to serve a user mode IRP only a kernel mode IRP? For what is
>this difference user mode - kernel mode IRP anyway?
User-mode ioctls are received through IRP_MJ_DEVICE_CONTROL and kernel mode
ioctls are received through IRP_MJ_INTERNAL_DEVICE_CONTROL (they can be
sent/received through IRP_MJ_DEVICE_CONTROL too). So that’s how you can
differentiate them. The RequestorMode field or the IRP structure also
indicates whether the originator is kernel-mode or user-mode.
And for the reason why they do this differentiation, well, it might be for
many reasons; one being that if you allocate resources or bandwidth and not
free them appropriately, the driver might not be designed to free them
automatically, thus creating memory leaks and such. Having kernel-only
ioctls also increases the security… Since isoch is something you can’t
really do efficiently from user-mode (considering you’re always executing
PASSIVE), it makes sense that only drivers can access that functionality.
As you probably know, it is possible to sending async commands from
user-mode.
My 2 cents,
Mat
----- Original Message -----
From: “Daniel Luethi”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 17, 2004 5:29 AM
Subject: Re:[ntdev] 1394a crash on getting local host info
> OK, thanks for all the hints! I actually don’t need the circular flag.
> But I’m using the 1394diag sample from the Win2k DDK and now it seems
> that I have to change all user mode IRP’s to kernel IRP’s which are
> quite a few. Although I don’t really see the sense, because if I write a
> driver I also write the API and the application and this thing just
> makes life more complicated, but whatever, thanks for your answers anyway.
> regards
> Daniel
>
>
[snip]
From (I believe) the XP DDK onwards, the 1394 samples use this technique of
creating kernel mode IRPs. Can you get a version the Windows server 2003
DDK, which is the latest release DDK? Even if you don’t use the 1394
samples, you can compile for Win2k environment there safely, and the header
files and documentation have been updated for the (then) latest service
packs. In principle it is always better to get the latest DDK and compile
for your OS of choice from there. Also, you will get more tools (CUV and
prefast).
good luck,
Philip Lukidis