1394 Iso Callbacks Stop

NTDEV
1

I’ve come across a problem that I hope someone on this list has already
stumbled across or seen, or can help point me in the right direction.

Under a Multi-Processor System (does not occur in a Single Processor System)
the Callbacks that I register in the ISOCH_DESCRIPTOR stop arriving although
I can see on a FireWire Analyzer that my device is still streaming. It takes
anywhere from 5 mins - 4 hours for the streaming to stop. Which leads me to
believe it maybe a timing issue or something.

Basically, I do all of my setup for the Device (Allocate Channel, Bandwidth,
Resources, Attach Buffers etc…) and everything starts to work.

In the Callback routine, I remove the data from the Buffer, Dettach and
Reattach the buffer (I reattach it in the detach completion routine.) and
leave the callback. Errors are also checked for in the completion routines.

In terms of buffers I attach 3 buffers to the Resource Handle so when I
detach and reattach the buffers, there should still be 2 buffers in the
system for the put the data into (in Listen Mode).

When the driver stops recieving Callbacks I can see that the last Callback
did call the detach buffer routine and that the buffers were reattached to
the system (Successfully).

Originally, I had though that it was possible that maybe the Bus Driver would
stop sending out callbacks if it ran out of buffers instead of maybe
overwritting buffers or dropping data, however I changed the code to not
dettach and reattach the buffers until all of the buffers were processed
(so there was no fresh buffers for the bus driver to fill) however that did
not cause the callbacks to stop.

Additionally, I use the DESCRIPTOR_SYNCH_ON_TAG flag in ISOCH_DESCRIPTOR and
thought that maybe the Tag was getting messed up so I checked what Tag the
Camera was streaming (using the FireWire Analyzer) yet again it was sending
the correct value.

Additionally, checking to make sure that the Tag and flags value in the
Descriptor were not changed also came up empty handed.

Any Assitance or Ideas would be Greatly Appreciated.

Brad.

2

I would guess that you have a data structure that has gotten corrupted.

More than likely the data structure contains a linked list or something similar.

The data structure is probably modified by your callback routine.

You are probably not seeing any new callbacks, because one of your processors is stuck in your callback (e.g. your list is supposed to be NULL terminated, but it has gotten circularly linked).

You probably need to employ some spinlocks.

With the debugger you should be able to determine the state of each of your processors.

Duane J. McCrory
InfiniCon Systems

-----Original Message-----
From: xxxxx@jedacite.dyndns.org [mailto:xxxxx@jedacite.dyndns.org]
Sent: Friday, December 13, 2002 8:29 PM
To: NT Developers Interest List
Subject: [ntdev] 1394 Iso Callbacks Stop

I’ve come across a problem that I hope someone on this list has already
stumbled across or seen, or can help point me in the right direction.

Under a Multi-Processor System (does not occur in a Single Processor System)
the Callbacks that I register in the ISOCH_DESCRIPTOR stop arriving although
I can see on a FireWire Analyzer that my device is still streaming. It takes
anywhere from 5 mins - 4 hours for the streaming to stop. Which leads me to
believe it maybe a timing issue or something.

Basically, I do all of my setup for the Device (Allocate Channel, Bandwidth,
Resources, Attach Buffers etc…) and everything starts to work.

In the Callback routine, I remove the data from the Buffer, Dettach and
Reattach the buffer (I reattach it in the detach completion routine.) and
leave the callback. Errors are also checked for in the completion routines.

In terms of buffers I attach 3 buffers to the Resource Handle so when I
detach and reattach the buffers, there should still be 2 buffers in the
system for the put the data into (in Listen Mode).

When the driver stops recieving Callbacks I can see that the last Callback
did call the detach buffer routine and that the buffers were reattached to
the system (Successfully).

Originally, I had though that it was possible that maybe the Bus Driver would
stop sending out callbacks if it ran out of buffers instead of maybe
overwritting buffers or dropping data, however I changed the code to not
dettach and reattach the buffers until all of the buffers were processed
(so there was no fresh buffers for the bus driver to fill) however that did
not cause the callbacks to stop.

Additionally, I use the DESCRIPTOR_SYNCH_ON_TAG flag in ISOCH_DESCRIPTOR and
thought that maybe the Tag was getting messed up so I checked what Tag the
Camera was streaming (using the FireWire Analyzer) yet again it was sending
the correct value.

Additionally, checking to make sure that the Tag and flags value in the
Descriptor were not changed also came up empty handed.

Any Assitance or Ideas would be Greatly Appreciated.

Brad.

You are currently subscribed to ntdev as: xxxxx@infiniconsys.com
To unsubscribe send a blank email to %%email.unsub%%

3

On Fri, Dec 13, 2002 at 09:47:49PM -0500, McCrory, Duane wrote:

I would guess that you have a data structure that has gotten corrupted.

More than likely the data structure contains a linked list or something similar.

The data structure is probably modified by your callback routine.

You are probably not seeing any new callbacks, because one of your processors is stuck in your callback (e.g. your list is supposed to be NULL terminated, but it has gotten circularly linked).

You probably need to employ some spinlocks.

With the debugger you should be able to determine the state of each of your processors.

Sorry I guess that I should be a little bit more specific. I actually do use
Spinlocks in the Callback function and I am seeing the function actually exit.\
I guess that it is possilbe that “one” of my threads is still hanging around
in there. I was going to use KeGetCurrentProcessorNumber to figure out which
processor I was running on but that is not available in WDM and could not find
the equivalent call. But I’ll double check that the other thread is not still
working in there (although I can’t see where it would hang up at.).

Thanks for you help, I’ll double check how I’m filling the buffers but I don’t
actually use a linked list but instead use a Queue (I use InsertTailList,
RemoveHeadList.)

Thanks for your time,
Brad.

4

I just checked, InsertTailList, RemoveHeadList are not multi-processor safe. Make sure you have a controlling spinlock held or use the ExInterlocked versions.

The other possibility, especially if you have multiple spin-locks is that you have a locking order issue. Define your order (e.g. A, B, C). Once you have one, you can only acquire additional ones to the right. You can unlock in any order, but you have to drop all spinlocks to acquire one to the left.

Duane.

-----Original Message-----
From: xxxxx@jedacite.dyndns.org [mailto:xxxxx@jedacite.dyndns.org]
Sent: Friday, December 13, 2002 10:57 PM
To: NT Developers Interest List
Subject: [ntdev] RE: 1394 Iso Callbacks Stop

On Fri, Dec 13, 2002 at 09:47:49PM -0500, McCrory, Duane wrote:

I would guess that you have a data structure that has gotten corrupted.

More than likely the data structure contains a linked list or something similar.

The data structure is probably modified by your callback routine.

You are probably not seeing any new callbacks, because one of your processors is stuck in your callback (e.g. your list is supposed to be NULL terminated, but it has gotten circularly linked).

You probably need to employ some spinlocks.

With the debugger you should be able to determine the state of each of your processors.

Sorry I guess that I should be a little bit more specific. I actually do use
Spinlocks in the Callback function and I am seeing the function actually exit.\
I guess that it is possilbe that “one” of my threads is still hanging around
in there. I was going to use KeGetCurrentProcessorNumber to figure out which
processor I was running on but that is not available in WDM and could not find
the equivalent call. But I’ll double check that the other thread is not still
working in there (although I can’t see where it would hang up at.).

Thanks for you help, I’ll double check how I’m filling the buffers but I don’t
actually use a linked list but instead use a Queue (I use InsertTailList,
RemoveHeadList.)

Thanks for your time,
Brad.

You are currently subscribed to ntdev as: xxxxx@infiniconsys.com
To unsubscribe send a blank email to %%email.unsub%%