Re[2]: 1394: stopping a 'talk' transfer stops all transfers?

NTDEV
1

>>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

To the best of my recollection the LISTEN should be happy to wait all
day for packets to arrive.

Since you have to reallocate the isoch resource it sounds like it is
being clobbered somehow. I would start by checking your code and
making sure that the 2 isoch resource objects are truly being kept
separate. Make sure that no function is incorrectly operating on the
wrong resource.

Robert Newton

2

> But have you guys had to do independent LISTEN and TALK before? Is this

something that worked for you?

Sorry, I’ve had code that did independent LISTEN and TALK but I’ve
never had one device object doing both at the same time (and I don’t
remember issuing any STOPS on the TALK).

Robert Newton

3

I have tried simultaneous independent Listen and Talk transfers, but I have
had mixed success. One rather HUGE problem I had is that the 1394 bus
driver can stay at DISPATCH_LEVEL potentially forever. For instance, I had
a Talk and Listen going simultaneously in two different drivers on the same
machine. My transfers used frequent, fairly small packets. The Talk would
dominate the Listen such that all of the Talk packets would be received
before any of the Listen packets. Once the Talk transfer completed, I would
get all of the Listen packets if the bus driver didn’t get hosed in the
meantime. I tracked in best I could to the 1394 bus driver, not having
source, and it appears that when an interrupt occurs its DpcForIsr handles
any requests that have come in up to that point, but then inexplicably it
loops and checks for any recent requests again. If interrupts are coming in
quicker than that loop, the bus driver will stay at DISPATCH_LEVEL forever.
If my transfers were continuous, I had real problems.

I am not sure if this is applicable to this particular situation, but might
be good to know anyway.

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

“Mathieu Routhier” wrote in message news:xxxxx@ntdev…
> >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
>
>

4

My description is somewhat confusing here, I used two driver each capable of
doing a TALK or LISTEN. Additionally I had the two drivers communicating
with each other. I would see all TALKs execute in one driver before any
Listen complete callbacks would occur in the other. Further, I am not sure
that TALK was always dominant or rather whoever started first was dominant.

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

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> I have tried simultaneous independent Listen and Talk transfers, but I
have
> had mixed success. One rather HUGE problem I had is that the 1394 bus
> driver can stay at DISPATCH_LEVEL potentially forever. For instance, I
had
> a Talk and Listen going simultaneously in two different drivers on the
same
> machine. My transfers used frequent, fairly small packets. The Talk
would
> dominate the Listen such that all of the Talk packets would be received
> before any of the Listen packets. Once the Talk transfer completed, I
would
> get all of the Listen packets if the bus driver didn’t get hosed in the
> meantime. I tracked in best I could to the 1394 bus driver, not having
> source, and it appears that when an interrupt occurs its DpcForIsr handles
> any requests that have come in up to that point, but then inexplicably it
> loops and checks for any recent requests again. If interrupts are coming
in
> quicker than that loop, the bus driver will stay at DISPATCH_LEVEL
forever.
> If my transfers were continuous, I had real problems.
>
> I am not sure if this is applicable to this particular situation, but
might
> be good to know anyway.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions
> Conexant Systems, Inc.
>
>
> “Mathieu Routhier” wrote in message
news:xxxxx@ntdev…
> > >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
> >
> >
>
>
>

5

About this simultaneous listen and talk problem we had… here is what
we discovered this morning.

First, the 1394 card we use is sold by Belkin and uses “Lucent
Microelectronics FW323 (rev4)”. I have tried with a different card: an
Adaptec with “Texas Instrument TSB12LV26” and to my surprise, IT WORKED.
We did not try this before because all our XP machines had Belkin cards
and all our linux machines had Adaptec. We did not realize that, and
therefore mistakenly associated the problem to the platform. I’m afraid
we don’t have other brands of card to try at the moment.

We had a look on the web for compatibility issues with this Belkin card.
It showed that this card is apparently not working very well (for
example, it is one of the few cards that does not work on linux.
Indeed, according to our tests, this card seems to behave very bad with
TALK using the current linux 1394 drivers).

So the culprit was that darn host controller. Here it is for the
record…

Mat

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mathieu Routhier
Sent: Friday, June 04, 2004 11:44 AM
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@cvds.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> First, the 1394 card we use is sold by Belkin and uses "Lucent

Microelectronics FW323 (rev4)". I have tried with a different card: an
Adaptec with “Texas Instrument TSB12LV26” and to my surprise, IT WORKED.

This TI’s chip is an OHCI 1394 controller, and it is surely compatible with the
OHCI1394 driver from Windows.

Indeed, according to our tests, this card seems to behave very bad with
TALK using the current linux 1394 drivers).

They can be buggy in terms of OHCI spec compatibility.

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