Re: isoch firewire listen

Sorry for resuming this outdated thread.
We are currently faced with the same problem on WinXP SP1. The
RESOURCE_BUFFERS_CIRCULAR mode cannot be used anymore. So we have to
attach/detach buffers periodically.
The question is: Can I issue the detach/attach call from the context of
the ISOCH_DESCRIPTOR completion callback? There is potential for a dead
lock if the OHCI/bus driver holds spin locks while issuing the
descriptor callback.

Udo Eberhardt
Thesycon GmbH

>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 6:28 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
>
>>Anything wrong?
>
>
> Yep, Microsoft has confirmed that circular buffers is just flat
broken in a
> few different ways. I have seen exactly what you reported myself using
> circular buffers. Callbacks were missed, hit out of order, it’s a mess.
>
> Some folks from Microsoft have suggested not ever using this flag and
always
> handling the buffers in a linear fashion. There is no inherent
reason why
> using linear buffers and reattaching on the fly should not be every
bit as
> fast as circular buffers. In theory you should always have buffers
> attached, so the time taken to detach and reattach buffers should not
affect
> your throughput unless you just haven’t attached enough buffers to begin
> with.
>
> I have done this for a digital video camera driver before (not using
> streaming) and it worked well there. Not sure how fast is fast for you
> though.
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> news:xxxxx@ntdev…
>
>>Well, yes.
>>
>>Anything wrong? It improves speed quite a lot.
>>
>>Mat
>>
>>-----Original Message-----
>>From: Bill McKenzie [mailto:xxxxx@compuware.com]
>>Sent: Tuesday, March 11, 2003 3:53 PM
>>To: NT Developers Interest List
>>Subject: [ntdev] Re: isoch firewire listen
>>
>>You aren’t allocating the isoch resources with the
>
> RESOURCE_BUFFERS_CIRCULAR
>
>>flag set are you?
>>
>>–
>>Bill McKenzie
>>Compuware Corporation
>>http://www.compuware.com/products/driverstudio/
>>
>>
>>
>>“Mathieu Routhier” wrote in message
>>news:xxxxx@ntdev…
>>
>>>Hi all,
>>>
>>>First, is there a list dedicated solely to problems related to WDM
>>
>>firewire?
>>
>>>Well, anyway, here is a weird behavior I have noticed regarding
>>
>>isochronous
>>
>>>transfers on a WDM 1394 driver I’m working on. I have allocated
>>
> resources
>
>>>for listening on a channel and attached 2 quite big descriptors (but
>>
>>anyway
>>
>>>the size does not seem to have an effect here).
>>>
>>>I receive callbacks every time a descriptor has been filled with
>>
> incoming
>
>>>data. Fine. But from time to time, I get those callbacks in the wrong
>>>order.
>>>
>>>More precisely: sometimes, I am notified that a buffer is filled but
>>
> that
>
>>>buffer does not correspond to the data I’m expecting (the next data
>>
> block
>
>>>count in a CIP header). It appears that some packets have been lost,
>>
> but
>
>>it
>>
>>>could happen, I can cope with that. But right after that, I get a
>>
>>callback
>>
>>>with the packets I thought were lost. So all the data is intact, it
>>
> just
>
>>>seems that the 1394 driver notified me in the wrong order. I have also
>>>checked the sequential number (in the header of a packet when no
>>
> quadlets
>
>>>are stripped) and this has been inverted too.
>>>
>>>I was wondering if someone else has ever experienced that kind of
thing.
>>
>>If
>>
>>>you have a fix for that, a workaround or simply some insight as to why
>>
> it
>
>>>was implemented that way.
>>>
>>>TIA! Mat
>>>
>>>
>>>
>>
>>
>>

A deadlock? I don’t see why.

In any case, we do attach/detach in the callback, which is called at
DISPATCH. Never had a problem with that!

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Thursday, May 22, 2003 8:39 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Sorry for resuming this outdated thread.
We are currently faced with the same problem on WinXP SP1. The
RESOURCE_BUFFERS_CIRCULAR mode cannot be used anymore. So we have to
attach/detach buffers periodically.
The question is: Can I issue the detach/attach call from the context of
the ISOCH_DESCRIPTOR completion callback? There is potential for a dead
lock if the OHCI/bus driver holds spin locks while issuing the
descriptor callback.

Udo Eberhardt
Thesycon GmbH

>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 6:28 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
>
>>Anything wrong?
>
>
> Yep, Microsoft has confirmed that circular buffers is just flat
broken in a
> few different ways. I have seen exactly what you reported myself using
> circular buffers. Callbacks were missed, hit out of order, it’s a mess.
>
> Some folks from Microsoft have suggested not ever using this flag and
always
> handling the buffers in a linear fashion. There is no inherent
reason why
> using linear buffers and reattaching on the fly should not be every
bit as
> fast as circular buffers. In theory you should always have buffers
> attached, so the time taken to detach and reattach buffers should not
affect
> your throughput unless you just haven’t attached enough buffers to begin
> with.
>
> I have done this for a digital video camera driver before (not using
> streaming) and it worked well there. Not sure how fast is fast for you
> though.
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> news:xxxxx@ntdev…
>
>>Well, yes.
>>
>>Anything wrong? It improves speed quite a lot.
>>
>>Mat
>>
>>-----Original Message-----
>>From: Bill McKenzie [mailto:xxxxx@compuware.com]
>>Sent: Tuesday, March 11, 2003 3:53 PM
>>To: NT Developers Interest List
>>Subject: [ntdev] Re: isoch firewire listen
>>
>>You aren’t allocating the isoch resources with the
>
> RESOURCE_BUFFERS_CIRCULAR
>
>>flag set are you?
>>
>>–
>>Bill McKenzie
>>Compuware Corporation
>>http://www.compuware.com/products/driverstudio/
>>
>>
>>
>>“Mathieu Routhier” wrote in message
>>news:xxxxx@ntdev…
>>
>>>Hi all,
>>>
>>>First, is there a list dedicated solely to problems related to WDM
>>
>>firewire?
>>
>>>Well, anyway, here is a weird behavior I have noticed regarding
>>
>>isochronous
>>
>>>transfers on a WDM 1394 driver I’m working on. I have allocated
>>
> resources
>
>>>for listening on a channel and attached 2 quite big descriptors (but
>>
>>anyway
>>
>>>the size does not seem to have an effect here).
>>>
>>>I receive callbacks every time a descriptor has been filled with
>>
> incoming
>
>>>data. Fine. But from time to time, I get those callbacks in the wrong
>>>order.
>>>
>>>More precisely: sometimes, I am notified that a buffer is filled but
>>
> that
>
>>>buffer does not correspond to the data I’m expecting (the next data
>>
> block
>
>>>count in a CIP header). It appears that some packets have been lost,
>>
> but
>
>>it
>>
>>>could happen, I can cope with that. But right after that, I get a
>>
>>callback
>>
>>>with the packets I thought were lost. So all the data is intact, it
>>
> just
>
>>>seems that the 1394 driver notified me in the wrong order. I have also
>>>checked the sequential number (in the header of a packet when no
>>
> quadlets
>
>>>are stripped) and this has been inverted too.
>>>
>>>I was wondering if someone else has ever experienced that kind of
thing.
>>
>>If
>>
>>>you have a fix for that, a workaround or simply some insight as to why
>>
> it
>
>>>was implemented that way.
>>>
>>>TIA! Mat
>>>
>>>
>>>
>>
>>
>>


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

Thanks for the information. We will also try it that way.

In general, there is always potential for a deadlock if a driver is
called back from a callback it issued to another driver. Whether such
scenarios are allowed must be clearly stated in the documentation.
Specifying the IRQL at which a particular function call is allowed is
not sufficient. Unfortunately, the DDK docs do not say anything about
such important details.
BTW, the same questions arise for other APIs and requests too. This is
because each IRP completion routine is in fact a callback from the lower
driver.

Example for a deadlock scenario:

  • Lower driver (OHCI) enters its DPC
  • Lower driver acquires a spin lock in its device object
  • Lower driver issues descriptor completion callback to upper driver
  • Upper driver sends down a DETACH IRP
  • Lower driver acquires the spin lock in its device object
    … end of story

Note that this kind of dead lock will only occur on a multiprocessor
kernel and on a checked kernel. On a single processor free build it will
not occur. This is due to the specific implementation of a spin lock.

Udo Eberhardt
Thesycon GmbH

Mathieu Routhier wrote:

A deadlock? I don’t see why.

In any case, we do attach/detach in the callback, which is called at
DISPATCH. Never had a problem with that!

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Thursday, May 22, 2003 8:39 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Sorry for resuming this outdated thread.
We are currently faced with the same problem on WinXP SP1. The
RESOURCE_BUFFERS_CIRCULAR mode cannot be used anymore. So we have to
attach/detach buffers periodically.
The question is: Can I issue the detach/attach call from the context of
the ISOCH_DESCRIPTOR completion callback? There is potential for a dead
lock if the OHCI/bus driver holds spin locks while issuing the
descriptor callback.

Udo Eberhardt
Thesycon GmbH

>
>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 6:28 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
>
>>Anything wrong?
>
>
> Yep, Microsoft has confirmed that circular buffers is just flat
broken in a
> few different ways. I have seen exactly what you reported myself using
> circular buffers. Callbacks were missed, hit out of order, it’s a mess.
>
> Some folks from Microsoft have suggested not ever using this flag and
always
> handling the buffers in a linear fashion. There is no inherent
reason why
> using linear buffers and reattaching on the fly should not be every
bit as
> fast as circular buffers. In theory you should always have buffers
> attached, so the time taken to detach and reattach buffers should not
affect
> your throughput unless you just haven’t attached enough buffers to begin
> with.
>
> I have done this for a digital video camera driver before (not using
> streaming) and it worked well there. Not sure how fast is fast for you
> though.
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> > news:xxxxx@ntdev…
> >
> >>Well, yes.
> >>
> >>Anything wrong? It improves speed quite a lot.
> >>
> >>Mat
> >>
> >>-----Original Message-----
> >>From: Bill McKenzie [mailto:xxxxx@compuware.com]
> >>Sent: Tuesday, March 11, 2003 3:53 PM
> >>To: NT Developers Interest List
> >>Subject: [ntdev] Re: isoch firewire listen
> >>
> >>You aren’t allocating the isoch resources with the
> >
> > RESOURCE_BUFFERS_CIRCULAR
> >
> >>flag set are you?
> >>
> >>–
> >>Bill McKenzie
> >>Compuware Corporation
> >>http://www.compuware.com/products/driverstudio/
> >>
> >>
> >>
> >>“Mathieu Routhier” wrote in message
> >>news:xxxxx@ntdev…
> >>
> >>>Hi all,
> >>>
> >>>First, is there a list dedicated solely to problems related to WDM
> >>
> >>firewire?
> >>
> >>>Well, anyway, here is a weird behavior I have noticed regarding
> >>
> >>isochronous
> >>
> >>>transfers on a WDM 1394 driver I’m working on. I have allocated
> >>
> > resources
> >
> >>>for listening on a channel and attached 2 quite big descriptors (but
> >>
> >>anyway
> >>
> >>>the size does not seem to have an effect here).
> >>>
> >>>I receive callbacks every time a descriptor has been filled with
> >>
> > incoming
> >
> >>>data. Fine. But from time to time, I get those callbacks in the wrong
> >>>order.
> >>>
> >>>More precisely: sometimes, I am notified that a buffer is filled but
> >>
> > that
> >
> >>>buffer does not correspond to the data I’m expecting (the next data
> >>
> > block
> >
> >>>count in a CIP header). It appears that some packets have been lost,
> >>
> > but
> >
> >>it
> >>
> >>>could happen, I can cope with that. But right after that, I get a
> >>
> >>callback
> >>
> >>>with the packets I thought were lost. So all the data is intact, it
> >>
> > just
> >
> >>>seems that the 1394 driver notified me in the wrong order. I have also
> >>>checked the sequential number (in the header of a packet when no
> >>
> > quadlets
> >
> >>>are stripped) and this has been inverted too.
> >>>
> >>>I was wondering if someone else has ever experienced that kind of
> thing.
> >>
> >>If
> >>
> >>>you have a fix for that, a workaround or simply some insight as to why
> >>
> > it
> >
> >>>was implemented that way.
> >>>
> >>>TIA! Mat
> >>>
> >>>
> >>>
> >>
> >>
> >>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@guillemot.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@thesycon.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Ok, you’re right, I understand what you mean. :confused:

In this particular case, I guess it is “expectable” that a driver detaches
its buffers in the callback, and it is likely that there will be the need to
attach some more buffers. Of course, that doesn’t prove anything…

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Thursday, May 22, 2003 9:48 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Thanks for the information. We will also try it that way.

In general, there is always potential for a deadlock if a driver is
called back from a callback it issued to another driver. Whether such
scenarios are allowed must be clearly stated in the documentation.
Specifying the IRQL at which a particular function call is allowed is
not sufficient. Unfortunately, the DDK docs do not say anything about
such important details.
BTW, the same questions arise for other APIs and requests too. This is
because each IRP completion routine is in fact a callback from the lower
driver.

Example for a deadlock scenario:

  • Lower driver (OHCI) enters its DPC
  • Lower driver acquires a spin lock in its device object
  • Lower driver issues descriptor completion callback to upper driver
  • Upper driver sends down a DETACH IRP
  • Lower driver acquires the spin lock in its device object
    … end of story

Note that this kind of dead lock will only occur on a multiprocessor
kernel and on a checked kernel. On a single processor free build it will
not occur. This is due to the specific implementation of a spin lock.

Udo Eberhardt
Thesycon GmbH

Mathieu Routhier wrote:

A deadlock? I don’t see why.

In any case, we do attach/detach in the callback, which is called at
DISPATCH. Never had a problem with that!

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Thursday, May 22, 2003 8:39 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Sorry for resuming this outdated thread.
We are currently faced with the same problem on WinXP SP1. The
RESOURCE_BUFFERS_CIRCULAR mode cannot be used anymore. So we have to
attach/detach buffers periodically.
The question is: Can I issue the detach/attach call from the context of
the ISOCH_DESCRIPTOR completion callback? There is potential for a dead
lock if the OHCI/bus driver holds spin locks while issuing the
descriptor callback.

Udo Eberhardt
Thesycon GmbH

>
>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 6:28 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
>
>>Anything wrong?
>
>
> Yep, Microsoft has confirmed that circular buffers is just flat
broken in a
> few different ways. I have seen exactly what you reported myself
using
> circular buffers. Callbacks were missed, hit out of order, it’s a
mess.
>
> Some folks from Microsoft have suggested not ever using this flag and
always
> handling the buffers in a linear fashion. There is no inherent
reason why
> using linear buffers and reattaching on the fly should not be every
bit as
> fast as circular buffers. In theory you should always have buffers
> attached, so the time taken to detach and reattach buffers should not
affect
> your throughput unless you just haven’t attached enough buffers to
begin
> with.
>
> I have done this for a digital video camera driver before (not using
> streaming) and it worked well there. Not sure how fast is fast for
you
> though.
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> > news:xxxxx@ntdev…
> >
> >>Well, yes.
> >>
> >>Anything wrong? It improves speed quite a lot.
> >>
> >>Mat
> >>
> >>-----Original Message-----
> >>From: Bill McKenzie [mailto:xxxxx@compuware.com]
> >>Sent: Tuesday, March 11, 2003 3:53 PM
> >>To: NT Developers Interest List
> >>Subject: [ntdev] Re: isoch firewire listen
> >>
> >>You aren’t allocating the isoch resources with the
> >
> > RESOURCE_BUFFERS_CIRCULAR
> >
> >>flag set are you?
> >>
> >>–
> >>Bill McKenzie
> >>Compuware Corporation
> >>http://www.compuware.com/products/driverstudio/
> >>
> >>
> >>
> >>“Mathieu Routhier” wrote in message
> >>news:xxxxx@ntdev…
> >>
> >>>Hi all,
> >>>
> >>>First, is there a list dedicated solely to problems related to WDM
> >>
> >>firewire?
> >>
> >>>Well, anyway, here is a weird behavior I have noticed regarding
> >>
> >>isochronous
> >>
> >>>transfers on a WDM 1394 driver I’m working on. I have allocated
> >>
> > resources
> >
> >>>for listening on a channel and attached 2 quite big descriptors (but
> >>
> >>anyway
> >>
> >>>the size does not seem to have an effect here).
> >>>
> >>>I receive callbacks every time a descriptor has been filled with
> >>
> > incoming
> >
> >>>data. Fine. But from time to time, I get those callbacks in the
wrong
> >>>order.
> >>>
> >>>More precisely: sometimes, I am notified that a buffer is filled but
> >>
> > that
> >
> >>>buffer does not correspond to the data I’m expecting (the next data
> >>
> > block
> >
> >>>count in a CIP header). It appears that some packets have been lost,
> >>
> > but
> >
> >>it
> >>
> >>>could happen, I can cope with that. But right after that, I get a
> >>
> >>callback
> >>
> >>>with the packets I thought were lost. So all the data is intact, it
> >>
> > just
> >
> >>>seems that the 1394 driver notified me in the wrong order. I have
also
> >>>checked the sequential number (in the header of a packet when no
> >>
> > quadlets
> >
> >>>are stripped) and this has been inverted too.
> >>>
> >>>I was wondering if someone else has ever experienced that kind of
> thing.
> >>
> >>If
> >>
> >>>you have a fix for that, a workaround or simply some insight as to
why
> >>
> > it
> >
> >>>was implemented that way.
> >>>
> >>>TIA! Mat
> >>>
> >>>
> >>>
> >>
> >>
> >>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@guillemot.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@thesycon.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


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

I agree, we can assume that the OHCI will expect to be called from the
context of its completion callback. But, we cannot know it. Such kind
of assumptions are part of a software interface and should be clearly
documented.

Udo Eberhardt
Thesycon GmbH

Mathieu Routhier wrote:

Ok, you’re right, I understand what you mean. :confused:

In this particular case, I guess it is “expectable” that a driver detaches
its buffers in the callback, and it is likely that there will be the need to
attach some more buffers. Of course, that doesn’t prove anything…

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Thursday, May 22, 2003 9:48 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Thanks for the information. We will also try it that way.

In general, there is always potential for a deadlock if a driver is
called back from a callback it issued to another driver. Whether such
scenarios are allowed must be clearly stated in the documentation.
Specifying the IRQL at which a particular function call is allowed is
not sufficient. Unfortunately, the DDK docs do not say anything about
such important details.
BTW, the same questions arise for other APIs and requests too. This is
because each IRP completion routine is in fact a callback from the lower
driver.

Example for a deadlock scenario:

  • Lower driver (OHCI) enters its DPC
  • Lower driver acquires a spin lock in its device object
  • Lower driver issues descriptor completion callback to upper driver
  • Upper driver sends down a DETACH IRP
  • Lower driver acquires the spin lock in its device object
    … end of story

Note that this kind of dead lock will only occur on a multiprocessor
kernel and on a checked kernel. On a single processor free build it will
not occur. This is due to the specific implementation of a spin lock.

Udo Eberhardt
Thesycon GmbH

Mathieu Routhier wrote:

>A deadlock? I don’t see why.
>
>In any case, we do attach/detach in the callback, which is called at
>DISPATCH. Never had a problem with that!
>
>Mat
>
>-----Original Message-----
>From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
>Sent: Thursday, May 22, 2003 8:39 AM
>To: NT Developers Interest List
>Subject: [ntdev] Re: isoch firewire listen
>
>Sorry for resuming this outdated thread.
>We are currently faced with the same problem on WinXP SP1. The
>RESOURCE_BUFFERS_CIRCULAR mode cannot be used anymore. So we have to
>attach/detach buffers periodically.
>The question is: Can I issue the detach/attach call from the context of
>the ISOCH_DESCRIPTOR completion callback? There is potential for a dead
>lock if the OHCI/bus driver holds spin locks while issuing the
>descriptor callback.
>
>Udo Eberhardt
>Thesycon GmbH
>
>
> >
> >
> > -----Original Message-----
> > From: Bill McKenzie [mailto:xxxxx@compuware.com]
> > Sent: Tuesday, March 11, 2003 6:28 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: isoch firewire listen
> >
> >
> >>Anything wrong?
> >
> >
> > Yep, Microsoft has confirmed that circular buffers is just flat
>broken in a
> > few different ways. I have seen exactly what you reported myself

using

> > circular buffers. Callbacks were missed, hit out of order, it’s a

mess.

> >
> > Some folks from Microsoft have suggested not ever using this flag and
>always
> > handling the buffers in a linear fashion. There is no inherent
>reason why
> > using linear buffers and reattaching on the fly should not be every
>bit as
> > fast as circular buffers. In theory you should always have buffers
> > attached, so the time taken to detach and reattach buffers should not
>affect
> > your throughput unless you just haven’t attached enough buffers to

begin

> > with.
> >
> > I have done this for a digital video camera driver before (not using
> > streaming) and it worked well there. Not sure how fast is fast for

you

> > though.
> >
> > –
> > Bill McKenzie
> > Compuware Corporation
> > http://www.compuware.com/products/driverstudio/
> >
> >
> >
> > “Mathieu Routhier” wrote in message
>> > news:xxxxx@ntdev…
>> >
>> >>Well, yes.
>> >>
>> >>Anything wrong? It improves speed quite a lot.
>> >>
>> >>Mat
>> >>
>> >>-----Original Message-----
>> >>From: Bill McKenzie [mailto:xxxxx@compuware.com]
>> >>Sent: Tuesday, March 11, 2003 3:53 PM
>> >>To: NT Developers Interest List
>> >>Subject: [ntdev] Re: isoch firewire listen
>> >>
>> >>You aren’t allocating the isoch resources with the
>> >
>> > RESOURCE_BUFFERS_CIRCULAR
>> >
>> >>flag set are you?
>> >>
>> >>–
>> >>Bill McKenzie
>> >>Compuware Corporation
>> >>http://www.compuware.com/products/driverstudio/
>> >>
>> >>
>> >>
>> >>“Mathieu Routhier” wrote in message
>> >>news:xxxxx@ntdev…
>> >>
>> >>>Hi all,
>> >>>
>> >>>First, is there a list dedicated solely to problems related to WDM
>> >>
>> >>firewire?
>> >>
>> >>>Well, anyway, here is a weird behavior I have noticed regarding
>> >>
>> >>isochronous
>> >>
>> >>>transfers on a WDM 1394 driver I’m working on. I have allocated
>> >>
>> > resources
>> >
>> >>>for listening on a channel and attached 2 quite big descriptors (but
>> >>
>> >>anyway
>> >>
>> >>>the size does not seem to have an effect here).
>> >>>
>> >>>I receive callbacks every time a descriptor has been filled with
>> >>
>> > incoming
>> >
>> >>>data. Fine. But from time to time, I get those callbacks in the
>
> wrong
>
>> >>>order.
>> >>>
>> >>>More precisely: sometimes, I am notified that a buffer is filled but
>> >>
>> > that
>> >
>> >>>buffer does not correspond to the data I’m expecting (the next data
>> >>
>> > block
>> >
>> >>>count in a CIP header). It appears that some packets have been lost,
>> >>
>> > but
>> >
>> >>it
>> >>
>> >>>could happen, I can cope with that. But right after that, I get a
>> >>
>> >>callback
>> >>
>> >>>with the packets I thought were lost. So all the data is intact, it
>> >>
>> > just
>> >
>> >>>seems that the 1394 driver notified me in the wrong order. I have
>
> also
>
>> >>>checked the sequential number (in the header of a packet when no
>> >>
>> > quadlets
>> >
>> >>>are stripped) and this has been inverted too.
>> >>>
>> >>>I was wondering if someone else has ever experienced that kind of
>>thing.
>> >>
>> >>If
>> >>
>> >>>you have a fix for that, a workaround or simply some insight as to
>
> why
>
>> >>
>> > it
>> >
>> >>>was implemented that way.
>> >>>
>> >>>TIA! Mat
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>>
>>
>>
>>
>>—
>>You are currently subscribed to ntdev as: xxxxx@guillemot.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to ntdev as: xxxxx@thesycon.de
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@guillemot.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@thesycon.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

> The question is: Can I issue the detach/attach call from the context
of

the ISOCH_DESCRIPTOR completion callback?

Surely yes.

lock if the OHCI/bus driver holds spin locks while issuing the
descriptor callback.

I don’t think MS are idiots who violate the basic rules :slight_smile:

Max

> context of its completion callback. But, we cannot know it. Such
kind

of assumptions are part of a software interface and should be
clearly
documented.

Must the things like “never divide by zero” be documented too? :slight_smile:

At least storage and USB stacks (IIRC serial too) support IoCallDriver
from the own completion routine. IIRC any stack callable from
DISPATCH_LEVEL is such, since the driver must do up-calls or
IoCompleteRequest only in a point when it is OK to be re-entered,
which usually just means - without the locks held.

Max

> - Lower driver acquires a spin lock in its device object

  • Lower driver issues descriptor completion callback to upper driver

No sane driver will make up-calls or IoCompleteRequest while holding a
spinlock, this is a very fundamental rule, and I assume all MS’s
driver developers know it.

Max

I know, the DDK docs state:
“Never call IoCompleteRequest while holding a spin lock. Attempting to
complete an IRP while holding a spin lock can cause deadlocks.”
The interesting thing here is the word “can”. For drivers that do not
expect callbacks from their completion routines it is ok to call
IoCompleteRequest while holding a lock. This will significantly simplify
driver design because you do not have to care about re-entrancy.
NT/WDM drivers are already complicated enough, aren’t they?
So, I think a better solution would be to define some more fine-granular
rules and to document implicit assumptions related to software interfaces.

BTW, I think the statement in the DDK is a great source for confusion
and creates potential for re-entrany problems in drivers. This is
because some people (especially developers with limited driver
experience) will try it to implement it that way:

AnyDriverFunction()
{
KeAcquireSpinLock

… do something

KeReleaseSpinLock
IoCompletRequest
KeAcquireSpinLock

… do something

KeReleaseSpinLock
}

At least, I saw that several times.
Of course, while releasing the lock for the IoCompleteRequest another
instance of AnyDriverFunction could run. If AnyDriverFunction is called
at DISPATCH_LEVEL this kind of re-entrancy happens on SMP machines only.

Udo Eberhardt
Thesycon GmbH

Maxim S. Shatskih wrote:

>context of its completion callback. But, we cannot know it. Such

kind

>of assumptions are part of a software interface and should be

clearly

>documented.

Must the things like “never divide by zero” be documented too? :slight_smile:

At least storage and USB stacks (IIRC serial too) support IoCallDriver
from the own completion routine. IIRC any stack callable from
DISPATCH_LEVEL is such, since the driver must do up-calls or
IoCompleteRequest only in a point when it is OK to be re-entered,
which usually just means - without the locks held.

Max


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

> "Never call IoCompleteRequest while holding a spin lock. Attempting
to

complete an IRP while holding a spin lock can cause deadlocks."
The interesting thing here is the word “can”. For drivers that do
not
expect callbacks from their completion routines it is ok to call
IoCompleteRequest while holding a lock.

Calling any outside functions in upper layers while holding a lock is
a just bad thing due to many reasons, performance, scalability and
deadlocks are some.

KeAcquireSpinLock

… do something

KeReleaseSpinLock
IoCompletRequest
KeAcquireSpinLock

… do something

KeReleaseSpinLock

Why not? This works.

Max

I just wanted to point out that the callback we were talking about in the
context of the 1394 bus driver is not an irp completion routine but a simple
function pointer.

Holding a spinlock is still possibly wrong but it’s not recommended anywhere
not to do so…

Mat

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, May 23, 2003 10:09 AM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

“Never call IoCompleteRequest while holding a spin lock. Attempting
to
complete an IRP while holding a spin lock can cause deadlocks.”
The interesting thing here is the word “can”. For drivers that do
not
expect callbacks from their completion routines it is ok to call
IoCompleteRequest while holding a lock.

Calling any outside functions in upper layers while holding a lock is
a just bad thing due to many reasons, performance, scalability and
deadlocks are some.

KeAcquireSpinLock

… do something

KeReleaseSpinLock
IoCompletRequest
KeAcquireSpinLock

… do something

KeReleaseSpinLock

Why not? This works.

Max


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

I’m afraid we are somewhat off-topic now…

>KeAcquireSpinLock
>
>… do something
>
>KeReleaseSpinLock
>IoCompletRequest
>KeAcquireSpinLock
>
>… do something
>
>KeReleaseSpinLock

Why not? This works.

This may work or may not work. Whether it works depends on the state of
your data structures when you temporarily release the lock and whether
you depend on this state after you re-acquired the lock. In short, it
depends on the driver’s design.
To give another simple example that will not work:

AnyDriverFunction()
{
KeAcquireSpinLock
… use a while loop to run through a list
element = head->Next;
while ( element!=head ) {
KeReleaseSpinLock
IoCompletRequest
KeAcquireSpinLock
element = element->Next;
}
KeReleaseSpinLock
}

If another routine of your driver is entered while you temporarily
released the lock for the IoCompletRequest and modified the list (added
or removed an element) then this code will surely not work as expected.

Of course, the problem with this example is obvious. However, you can
easy imagine more complex scenarios. If a driver uses complex data
structures then getting everything right when temporarily releasing a
lock may be difficult.

Udo Eberhardt
Thesycon GmbH

> Holding a spinlock is still possibly wrong but it’s not recommended
anywhere

not to do so…

It contradicts the common sense in fact.

You can call, say, ExFreePool under the lock, since you know that
ExFreePool is a part of the self-containing package, and will not call
any upper layers.

But we cannot call the callbacks set by the upper layers while holding
a lock, since you do know what these callbacks will do, they can do
arbitrary things. So, it is a good idea to call them only in “neutral”
context without any resources (not only locks) acquired in the lower
driver.

Max

>

AnyDriverFunction()
{
KeAcquireSpinLock
… use a while loop to run through a list
element = head->Next;
while ( element!=head ) {
KeReleaseSpinLock
IoCompletRequest
KeAcquireSpinLock
element = element->Next;

Yes, this is a very stupid window opened.

Max