Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)
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.
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.
Facebook
Twitter
Instagram