1394: stopping a 'talk' transfer stops all transfers?

NTDEV
1

Hi guys,

I am experiencing a specific problem in my 1394 driver and I was
wondering if this was a known problem or just something weird going on.

I am using simultaneously and independently two isochronous transfers.
The first is a LISTEN transfer, and the second is a TALK transfer. When
both transfers are running and I stop the TALK transfer, I suddenly stop
receiving callback on the LISTEN transfer, which should still be
running. I have confirmed with an analyzer that the packets are still
traveling on the bus, but the lower driver does not notify me by calling
the callback.

When this condition happens, a workaround I have found is to perform, on
the LISTEN transfer: “STOP, DETACH_BUFFER, FREE_RESOURCES ;
ALLOCATE_RESOURCES, ATTACH_BUFFER, LISTEN”. When I do this, with the
exact same parameters as before, I begin receiving callbacks again. A
simple “STOP; LISTEN” sequence is not sufficient to wake the system up.

Notice that if I am using both transfers and I stop the LISTEN transfer
instead, then the TALK transfer keeps rolling… The problem shows up
only when it is the TALK transfer that is stopped.

This is quite frightening and I wonder if this could be a bug in the
1394 lower driver even though I’d be happier to find out that this is a
problem in my own code. Is it something any of you have experienced
before? Any suggestion as to how I could better diagnose the problem?

Mathieu Routhier

2

Hi Mathieu,

I have no experience in LISTENing and TALKing simultaneously on the 1394
bus.

But I assume that you use different resource handles for both transfers?

-Volker

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mathieu Routhier
Sent: Friday, June 04, 2004 5:44 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] 1394: stopping a ‘talk’ transfer stops all transfers?

Hi guys,

I am experiencing a specific problem in my 1394 driver and I was
wondering if this was a known problem or just something weird going on.

I am using simultaneously and independently two isochronous transfers.
The first is a LISTEN transfer, and the second is a TALK
transfer. When
both transfers are running and I stop the TALK transfer, I
suddenly stop
receiving callback on the LISTEN transfer, which should still be
running. I have confirmed with an analyzer that the packets are still
traveling on the bus, but the lower driver does not notify me
by calling
the callback.

When this condition happens, a workaround I have found is to
perform, on
the LISTEN transfer: “STOP, DETACH_BUFFER, FREE_RESOURCES ;
ALLOCATE_RESOURCES, ATTACH_BUFFER, LISTEN”. When I do this, with the
exact same parameters as before, I begin receiving callbacks again. A
simple “STOP; LISTEN” sequence is not sufficient to wake the system up.

Notice that if I am using both transfers and I stop the LISTEN transfer
instead, then the TALK transfer keeps rolling… The problem shows up
only when it is the TALK transfer that is stopped.

This is quite frightening and I wonder if this could be a bug in the
1394 lower driver even though I’d be happier to find out that this is a
problem in my own code. Is it something any of you have experienced
before? Any suggestion as to how I could better diagnose the problem?

Mathieu Routhier

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

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

3

Yes, I use different resource handles. These transfers are really
independent.

Mat

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moebius, V.
Sent: Friday, June 04, 2004 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] 1394: stopping a ‘talk’ transfer stops all
transfers?

Hi Mathieu,

I have no experience in LISTENing and TALKing simultaneously on the 1394
bus.

But I assume that you use different resource handles for both transfers?

-Volker

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mathieu Routhier
Sent: Friday, June 04, 2004 5:44 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] 1394: stopping a ‘talk’ transfer stops all transfers?

Hi guys,

I am experiencing a specific problem in my 1394 driver and I was
wondering if this was a known problem or just something weird going on.

I am using simultaneously and independently two isochronous transfers.
The first is a LISTEN transfer, and the second is a TALK
transfer. When
both transfers are running and I stop the TALK transfer, I
suddenly stop
receiving callback on the LISTEN transfer, which should still be
running. I have confirmed with an analyzer that the packets are still
traveling on the bus, but the lower driver does not notify me
by calling
the callback.

When this condition happens, a workaround I have found is to
perform, on
the LISTEN transfer: “STOP, DETACH_BUFFER, FREE_RESOURCES ;
ALLOCATE_RESOURCES, ATTACH_BUFFER, LISTEN”. When I do this, with the
exact same parameters as before, I begin receiving callbacks again. A
simple “STOP; LISTEN” sequence is not sufficient to wake the system up.

Notice that if I am using both transfers and I stop the LISTEN transfer
instead, then the TALK transfer keeps rolling… The problem shows up
only when it is the TALK transfer that is stopped.

This is quite frightening and I wonder if this could be a bug in the
1394 lower driver even though I’d be happier to find out that this is a
problem in my own code. Is it something any of you have experienced
before? Any suggestion as to how I could better diagnose the problem?

Mathieu Routhier

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

You are currently subscribed to ntdev as: xxxxx@baslerweb.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@cvds.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Mathieu,

I assume you have a different isoch channel for each isoch resource.
Actually, if you don’t I think all hell will break loose so skip that.

In your work around, do you need to free and reallocate the resources?
Could you get away with just STOP DETACH ATTACH LISTEN? If resource
allocation is necessary it would seem to indicate that the resource is
getting clobbered somehow (check the code stopping the TALK transfer).

Otherwise I have no idea what the problem is (and I have not tried to
do what you are doing). I do know that if your listen buffer does not
fill with an integral number of packets you will not get your
callback.
However, I do not see how this could happen in your case unless your
stopping the TALK causes some difference to the length of packets you
receive on the LISTEN.

Robert Newton

5

Probably a silly question but you aren’t seeing any bus resets in there are
you?

–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Moebius, V.” wrote in message news:xxxxx@ntdev…
> Hi Mathieu,
>
> I have no experience in LISTENing and TALKing simultaneously on the 1394
> bus.
>
> But I assume that you use different resource handles for both transfers?
>
> -Volker
>
>
> >-----Original Message-----
> >From: xxxxx@lists.osr.com
> >[mailto:xxxxx@lists.osr.com]On Behalf Of Mathieu Routhier
> >Sent: Friday, June 04, 2004 5:44 PM
> >To: Windows System Software Devs Interest List
> >Subject: [ntdev] 1394: stopping a ‘talk’ transfer stops all transfers?
> >
> >
> >Hi guys,
> >
> >I am experiencing a specific problem in my 1394 driver and I was
> >wondering if this was a known problem or just something weird going on.
> >
> >I am using simultaneously and independently two isochronous transfers.
> >The first is a LISTEN transfer, and the second is a TALK
> >transfer. When
> >both transfers are running and I stop the TALK transfer, I
> >suddenly stop
> >receiving callback on the LISTEN transfer, which should still be
> >running. I have confirmed with an analyzer that the packets are still
> >traveling on the bus, but the lower driver does not notify me
> >by calling
> >the callback.
> >
> >When this condition happens, a workaround I have found is to
> >perform, on
> >the LISTEN transfer: “STOP, DETACH_BUFFER, FREE_RESOURCES ;
> >ALLOCATE_RESOURCES, ATTACH_BUFFER, LISTEN”. When I do this, with the
> >exact same parameters as before, I begin receiving callbacks again. A
> >simple “STOP; LISTEN” sequence is not sufficient to wake the system up.
> >
> >Notice that if I am using both transfers and I stop the LISTEN transfer
> >instead, then the TALK transfer keeps rolling… The problem shows up
> >only when it is the TALK transfer that is stopped.
> >
> >This is quite frightening and I wonder if this could be a bug in the
> >1394 lower driver even though I’d be happier to find out that this is a
> >problem in my own code. Is it something any of you have experienced
> >before? Any suggestion as to how I could better diagnose the problem?
> >
> >Mathieu Routhier
> >
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as: xxxxx@baslerweb.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>

6

Robert,

I assume you have a different isoch channel for each isoch resource.

You are right :slight_smile:

Could you get away with just STOP DETACH ATTACH LISTEN?

I forgot to mention this… Yes, I have tried this sequence and no, it
does not work. I really need to free the resource and reallocate it.

However, I do not see how this could happen in your case unless your
stopping the TALK causes some difference to the length of packets you
receive on the LISTEN.

On the analyzer, the packets still have the same size (0x32 quadlets).

One other question: if for some reason there were a couple of cycles
where there are no packets, would this be sufficient for the transfer to
be interrupted? Still it does not excuse the lower driver, but is this
possible?

Mat

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Newton
Sent: Friday, June 04, 2004 2:44 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: stopping a ‘talk’ transfer stops all
transfers?

Mathieu,

I assume you have a different isoch channel for each isoch resource.
Actually, if you don’t I think all hell will break loose so skip that.

In your work around, do you need to free and reallocate the resources?
Could you get away with just STOP DETACH ATTACH LISTEN? If resource
allocation is necessary it would seem to indicate that the resource is
getting clobbered somehow (check the code stopping the TALK transfer).

Otherwise I have no idea what the problem is (and I have not tried to
do what you are doing). I do know that if your listen buffer does not
fill with an integral number of packets you will not get your
callback.
However, I do not see how this could happen in your case unless your
stopping the TALK causes some difference to the length of packets you
receive on the LISTEN.

Robert Newton

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

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

7

>Probably a silly question but you aren’t seeing any bus resets in there
are

you?

I don’t see any… and there should not be one. Out of curiosity I have
just tried to generate a bus reset to see if it wakes the system up. It
does not.

But have you guys had to do independent LISTEN and TALK before? Is this
something that worked for you?

Mat