isoch tx callback priority

Hi

I’m investigating a situation where my isochronous TX callbacks seem to be
held off for an extended period (too long).

This may be because an application using our driver has raised a real time
thread to a high priority.

Still investigating but I am wondering

(a) is it possible for an isoch TX callback to be blocked by a high priority
application thread?
(b) in another scenario, could it be my completion callbacks being held off
instead, effectively blocking the TX handler (which has to go through the
tedious process of detaching buffers, emptying them, and reattaching, each
with a completion callback that leads on to the next stage)

If (a) is there any way to increase priority at which my callbacks will be
called by the underlying 1394 driver?

If (b) I imagine I can simply raise my thread priority once my callback is
entered - but I have not done this before - which is the recommended method
of doing this - and will it increase the priority of the completion callback
anyway?

Callback should be at IRQL DISPATCH_LEVEL according to spec of
REQUEST_ISOCH_ATTACH_BUFFERS…

Thanks for any tips

Mike

PS RX callbacks are still happening okay, also this is a WDK driver.

I think isoch callbacks are called from DpcForIsr context of OHCI1394.SYS,
so no thread scheduling can bother them.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Mike Kemp” wrote in message news:xxxxx@ntdev…
> Hi
>
> I’m investigating a situation where my isochronous TX callbacks seem to be
> held off for an extended period (too long).
>
> This may be because an application using our driver has raised a real time
> thread to a high priority.
>
> Still investigating but I am wondering
>
> (a) is it possible for an isoch TX callback to be blocked by a high priority
> application thread?
> (b) in another scenario, could it be my completion callbacks being held off
> instead, effectively blocking the TX handler (which has to go through the
> tedious process of detaching buffers, emptying them, and reattaching, each
> with a completion callback that leads on to the next stage)
>
> If (a) is there any way to increase priority at which my callbacks will be
> called by the underlying 1394 driver?
>
> If (b) I imagine I can simply raise my thread priority once my callback is
> entered - but I have not done this before - which is the recommended method
> of doing this - and will it increase the priority of the completion callback
> anyway?
>
> Callback should be at IRQL DISPATCH_LEVEL according to spec of
> REQUEST_ISOCH_ATTACH_BUFFERS…
>
> Thanks for any tips
>
> Mike
>
> PS RX callbacks are still happening okay, also this is a WDK driver.
>
>

Thanks Maxim

Can you confirm also that even though my isoch callback is entered at an
“unbeatable” priority from OHCI1394.SYS, this will persist throughout the
sequence of detach -> detach completion -> process -> reattach -> reattach
completion, or do I have to take special steps when passing say the detach
command back to the lower driver to ensure that it happens and comes back to
me all at the highest priority?

Thanks for any help on this…

Mike

----- Original Message -----
From: Maxim S. Shatskih
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Thursday, September 06, 2007 1:23 PM
Subject: Re:[ntdev] isoch tx callback priority

I think isoch callbacks are called from DpcForIsr context of
OHCI1394.SYS,
so no thread scheduling can bother them.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Mike Kemp” wrote in message news:xxxxx@ntdev…
> Hi
>
> I’m investigating a situation where my isochronous TX callbacks seem to be
> held off for an extended period (too long).
>
> This may be because an application using our driver has raised a real time
> thread to a high priority.
>
> Still investigating but I am wondering
>
> (a) is it possible for an isoch TX callback to be blocked by a high
> priority
> application thread?
> (b) in another scenario, could it be my completion callbacks being held
> off
> instead, effectively blocking the TX handler (which has to go through the
> tedious process of detaching buffers, emptying them, and reattaching, each
> with a completion callback that leads on to the next stage)
>
> If (a) is there any way to increase priority at which my callbacks will be
> called by the underlying 1394 driver?
>
> If (b) I imagine I can simply raise my thread priority once my callback is
> entered - but I have not done this before - which is the recommended
> method
> of doing this - and will it increase the priority of the completion
> callback
> anyway?
>
> Callback should be at IRQL DISPATCH_LEVEL according to spec of
> REQUEST_ISOCH_ATTACH_BUFFERS…
>
> Thanks for any tips
>
> Mike
>
> PS RX callbacks are still happening okay, also this is a WDK driver.
>
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer