On Mon, Jun 29, 2009 at 04:50:38AM +0200, ext Hugo Vincent wrote: > Hi all, > > I'm still seeing a problem with musb receive DMA crashing when large > transfers happen in rapid succession. > > I've narrowed it down to this test case: Pinging the OMAP over USB > ethernet gadget, with large (64K) ping packets. At the start, the > system is otherwise idle. If the interval is set higher than the ping > time (i.e. 0.05 = 50ms in the first example), then it doesn't crash. > If I reduce the interval of these packets to 20 ms (second example > below), then start loading the system (increasing the ping time > through 20 ms), I see the crash (log below). Alternately, decreasing > the ping interval to 10 ms causes the crash after one packet. > > desktop ~$ sudo ping -i 0.05 -s 65507 192.168.2.2 > PING 192.168.2.2 (192.168.2.2) 65507(65535) bytes of data. > 65515 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=19.4 ms > 65515 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=19.4 ms > 65515 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=19.4 ms > ... > --> Does NOT crash > > desktop ~$ sudo ping -i 0.02 -s 65507 192.168.2.2 > PING 192.168.2.2 (192.168.2.2) 65507(65535) bytes of data. > 65515 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=19.5 ms > 65515 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=19.3 ms > 65515 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=19.3 ms > ... > --> Does crash, as soon as the system is loaded a bit such that the > ping time would increase beyond 20 ms. I haven't managed to make it crash, but musb rtl 1.4 has a hw problem where it can't handle simultaneous dma transfers. You have to use one channel at a time. One way to work around this issue, is to allocate channel on a per-request basis. I have some patches for that but they're not clean enough to be sent out and they probably break blackfin that has some other issues with mentor dma. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
