Re: 1394 Async Request Rx (BUSY_X blocking)
From: Raj (r_konjeti_at_mailcity.com)
Date: 07/08/04
- Next message: Eli Aran: "looking for usb driver for palm m515"
- Previous message: Andrei: "Font antialiasing"
- In reply to: Bill McKenzie: "Re: 1394 Async Request Rx (BUSY_X blocking)"
- Messages sorted by: [ date ] [ thread ]
Date: 8 Jul 2004 13:48:09 -0700
what is the async address range that imply "no response".
I am not getting speed above 70 Mbps in async because of response
mode,
I think. This will be useful to know. AFAIK, we have to set "unified
write" request in the OHCI registers(which we dont have access to
through Microsoft driver) to avoid write response.
Thanks.
"Bill McKenzie" <bill.mckenzie@nospam.conexant.com> wrote in message news:<OTjm2uCZEHA.228@TK2MSFTNGP10.phx.gbl>...
> 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.
> >
- Next message: Eli Aran: "looking for usb driver for palm m515"
- Previous message: Andrei: "Font antialiasing"
- In reply to: Bill McKenzie: "Re: 1394 Async Request Rx (BUSY_X blocking)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
