Re: 1394 Async Request Rx (BUSY_X blocking)

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Bill McKenzie (bill.mckenzie_at_nospam.conexant.com)
Date: 07/07/04 

Date: Wed, 7 Jul 2004 09:07:16 -0500

Interesting, but not surprising. I would report this to 1394@microsoft.com
and see what they say. It might be interesting to post what they tell you
as well. 

-- 
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.
"Steve" <Steve@discussions.microsoft.com> wrote in message
news:F936AB39-CD7D-43BD-9B2E-A32D6FBD840D@microsoft.com...
> Hi there,
>
> we encountered a new problem. It is related to 1394 asynch transfers. The
situation is as follows: For some customers we realized solutions that are
based on high-bandwidth asynch transfers. Our driver creates one or more
address ranges and the device sends asynch write block requests to those
ranges. For performance reasons we use an address range that does not imply
a response packet. With this approach we can get transfer rates of about 34
Mbytes/s.
>
> One customer's setup uses transfers of about 22 Mbytes/s. On the PC there
is an application that processes the received data and writes the results to
harddisk. In this scenario we observe the problem that the ohci1394 driver
seems not to be stable if there is additional CPU load on the machine
(caused by data processing and recording).
>
> We analyzed the problem and the results are as follows: Normally, the
ohci1394 driver is able to process a high rate of asynch write block request
packets. It seems to use 4 buffers of 8KB each to receive asynch requests
from the OHCI chip (by DMA). The chip issues an interrupt if an asynch
packet is received. From its DPC the driver calls a routine that parses the
packets received in the 4 DMA buffers.
>
> When there is some CPU load, especially if there are other DPCs running on
the machine that consume CPU time, then the packet parser routine seems to
corrupt its internal data structures. Then the routine tries to read a
packet header from the DMA buffer at a location where no packet start is
present. The routine seems to do a switch/case on the TCODE first. Because
the routine tries to interpret a random DWORD as a packet header it executes
the default case which does nothing but return. As a result, the parser
hangs. No further packets will be processed. The OHCI chip fills the 4
buffers completely and then the DMA context stops. On the 1394 bus we see
that every further asynch write request is ack'ed with busy_X. This is
because the DMA context has stopped and has a FIFO overflow condition now.
>
> The problem does not go away when a bus reset occurs or if we delete and
re-create the address ranges. We have to disable/enable the OHCI devnode in
Device Manager in order to get the driver working again.
>
> We tested on XP SP1.
>

Relevant Pages

  • Re: 1394 Async Request Rx (BUSY_X blocking)
    ... It is related to 1394 asynch transfers. ... packet is received. ... From its DPC the driver calls a routine that parses the ... packets received in the 4 DMA buffers. ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: Advice on a multithreaded netisr patch?
    ... DMA of the packet data to main memory from the NIC ... Servicing of CPU cache misses to access data in main memory ... m_pulluphere ensures that the first sizeofbytes of mbuf data are ...
    (freebsd-net)
  • Re: 1394 Async Request Rx (BUSY_X blocking)
    ... I am not getting speed above 70 Mbps in async because of response ... through Microsoft driver) to avoid write response. ... > packet is received. ... From its DPC the driver calls a routine that parses the ...
    (microsoft.public.development.device.drivers)
  • Re: 1394 Async Request Rx (BUSY_X blocking)
    ... I am not getting speed above 70 Mbps in async because of response ... through Microsoft driver) to avoid write response. ... > packet is received. ... From its DPC the driver calls a routine that parses the ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: [PATCH] Jazzsonic driver updates
    ... On Wed, 15 Jun 2005, Ralf Baechle wrote: ... the sonic core to the DMA API if I'm going to adopt it for macsonic. ... >> in order to memcpy the received packet. ... chip reports the address of that packet as a pointer. ...
    (Linux-Kernel)