AM3517 on 2.6.32 kernel: DMA transfers from McBSP3/4 not working as expected

Problem

Using an embedded Linux kernel (based on 2.6.32), we are able to successfully read data via DMA from McBSP2. However, with the same DMA configuration applied to McBSPs 3 and 4, DMA reads from those McBSPs fail to trigger the McBSP to actually read data from the DRR register of the respective McBSP, and the kernel eventually hangs. Even though the DMA transfer has been configured to trigger on a full frame of elements (DMA4_CCR register for logical DMA channel: FS = 1, BS = 0), it's as if the DMA transfer is instead triggering on a block or packet of frames.

Configuration (same for McBSPs 2, 3, 4)

Embedded Linux kernel version: 2.6.32.
Processor: AM3517
Custom mcbsp.c file (linux-2.6.32/arch/arm/plat-omap/mcbsp.c)
Total length of request buffer passed into kernel (omap_mcbsp_recv_buffer) from userspace: 3584 bytes (896 4-byte elements)
DMA element size: 4 bytes (32 bits)
Number of elements per frame: 14 (programmed into DMA4_CEN register)
Number of frames : 896 / 14 = 64 (programmed into DMA4_CFN register).

I've confirmed that the correct HW DMA request lines are selected for the respective McBSPs and programmed into the DMA4_CCR register bits 20:19,4:0.
I've also confirmed the correct pad configuration register settings for McBSPs 2-4.
Using a scope, I've confirmed that CLKX and FSX show clock and frame sync pulses on their correct pins.

With this configuration, DMA transfers from McBSP2 DRR into a local buffer occur with no issues.
Attempted DMA transfers from McBSP3 DRR or McBSP4 DRR into a local buffer hang the kernel.

McBSP 2 registers prior to omap_start_dma method:

McBSP 4 registers prior to omap_start_dma method

Major differences between McBSP 2 and 4

Comparing IRQST between both McBSPs show that McBSP 4 is in overflow, indicating that the McBSP hasn't been triggered to read data from DRR.
Comparing RBUFFSTAT between both McBSPs: number of occupied locations in McBSP 2 RB is 895 (0x37F); number of occupied locations in McBSP 4 RB is 127 (0x07F); maybe this difference is due to RBUFFSTAT field width differences between the two McBSPs.

Workaround to prove basic McBSP functionality

Finally decided to decrease the number of frames in the DMA transfer on McBSP 4 from 64 to 9.
Using configuration from above (except for number of frames), this equates to a DMA transfer of 14 * 9 = 126 4-byte elements.
DMA transfers are successful using this configuration, however this change will not work with our current application design.

Questions

1. Am I configuring something incorrectly in the DMA transfer for syncing on a frame? If so, is there a correct way to configure the DMA?
2. Is there a known problem in the 2.6.32 kernel related to DMA transfers not working on McBSP3 and 4 of the AM3517 processor?

Any tips or suggestions are greatly appreciated.

Thanks for your time,

Tony