BeagleBone crashes/hangs with Ethernet gadget and Win7 RNDIS

Which version of the Beaglebone are you using?

Rev A5.

Actually, after further testing its not the PCs that are causing the problem.  Some instances of the A5 BBone are exhibiting this problem.  I've even found an A5 that will not boot into the original Arago linux dist at all, and hangs at kernel startup, but this same machine boots fine into the Angstrom dist that was on the SD card that came with the BBone.  I've read on the BeagleBoard web site that there were essentially no changes to HW between A3 and A5.  Was there some problem with the FTDI device or the USB hub?

Bruno,

This seems to be related to usb dma issue in using kernel workqueue for 8 byte transfer of ethernet gadget. please test with below change and see if this helps.

-------------- start ---------------------

---
 drivers/usb/musb/musb_gadget.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 47349ca..0a215da 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -407,7 +407,7 @@ static void txstate(struct musb *musb, struct musb_request *req)
                        /* program endpoint CSR first, then setup DMA */
                        csr &= ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);

-                       if (request_size == 0)
+                       if (request_size <= 16)
                                csr &= ~(MUSB_TXCSR_DMAENAB |
                                        MUSB_TXCSR_DMAMODE);
                        else
@@ -431,8 +431,8 @@ static void txstate(struct musb *musb, struct musb_request *req)
                         * unreliable except for the last-packet-is-already-
                         * short case.
                         */
-                       /* for zero byte transfer use pio mode */
-                       if (request_size == 0)
+                       /* for zero to 16 byte transfer use pio mode */
+                       if (request_size <= 16)
                                use_dma = 0;
                        else {
                                use_dma = use_dma && c->channel_program(
--
1.7.0.4

----------------- end-------------------------------

This change is still being evaluated and under testing and will get merged to TI's linux PSP later.

Ajay

I will try your patch and report back.

But, how is it that we see this only on some A5 BBones, and not on A3 BBones?  Is it just a matter of timing, intensity of usage, or ...?

The given patch does not fix the crash.  I will check if kworker thread is used less.

Again the question: why only one some A5s but no A3s would this occur?

The kworker CPU usage is much reduced, so the patch does its job.

I'm beginning to suspect chip version differences between A5,A3 devices, especially the whole USB hub, FTDI network, and driver incompatibilities?  I seem to remember some discussions elsewhere on the web about FTDI vendor number differences causing driver issues, for instance.