RE: does 1394bus.sys serialize async access from differen t drivers?

NTDEV
1

>Do you know in which situations I’ll get STATUS_IO_TIMEOUT

As far as I can remember I got STATUS_IO_TIMEOUT or STATUS_TIMEOUT if the
target device is simply too slow. At least with W2k SP4, WXp (SP1) seemed to
be more tolerant in this aspect.

Can you examine the transactions by a 1394 logger?

Regards
Volker

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of uwe kirst
Sent: Saturday, September 11, 2004 6:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] does 1394bus.sys serialize async access from
different drivers?

Maxim S. Shatskih wrote:

> No, it passes them down to OHCI1394, which creates the
DMA descriptor
>chains to service them.
>
>
So what happens if the internal descriptor processing within
OHCI1394 is
interrupted by a second write access from a different driver. Are
OHCI1394 and 1394BUS supposed to cope with this situation even if the
two accesses address different targets?

Do you know in which situations I’ll get STATUS_IO_TIMEOUT
(0xc00000b5)?
It seems I’m having a problem to access more than one firewire device
at the same time.

Thanks
Uwe

>Maxim Shatskih, Windows DDK MVP
>StorageCraft Corporation
>xxxxx@storagecraft.com
>http://www.storagecraft.com
>
>----- Original Message -----
>From: “uwe kirst”
>>To: “Windows System Software Devs Interest List”
>>Sent: Saturday, September 11, 2004 1:50 PM
>>Subject: [ntdev] does 1394bus.sys serialize async access from
>different
>>drivers?
>>
>>
>>
>>
>>>Hello,
>>>does anyone know if the 1394bus.sys serializes asynchronous reads or
>>>writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
>>>fail if submitted at the same time from different drivers (using the
>>>same ohci controller card)?
>>>
>>>I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
>>>STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
>>>Thanks
>>>Uwe
>>>
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>
>>>
>>http://www.osronline.com/article.cfm?id=256
>>
>>
>>>You are currently subscribed to ntdev as: xxxxx@storagecraft.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@gmx.de
>>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@baslerweb.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>

2

Moebius, V. wrote:

Can you examine the transactions by a 1394 logger?

No, but I can run a debugger in the attached devices. I’m getting a
timeout in the following case:
-at least one isoch stream must be running all the time.
-there are two of my devices connected to one ohci controller card (If I
connect these devices to separate controllers everything seems to work fine)
-I’m doing aync reads or writes.

From the device debug output I can see:
the RQPkt Interrupt is delayed for a very long period of time (about
about half a minute or so). The residual count in the descriptor is also
not updated before I’m getting the delayed Irq.
The packet ordering seems to be ok though (no packet is missing).
Thanks
Uwe