Hi all, I'm using linux 2.6.34.1 getting code to work with ViewSonic V210/V110 platform - pxa255/pxa250 processor. Under 2.6.34.1 for a arm pxa255 processor, was having a problem getting g_serial to work with out stalling on output lines longer than 64 bytes. Problem was that any command - like free, ls -l etc... would hang from a connected minicom session. Able to log in OK and do small commands that would send less than 64 bytes at a time. But anything over 64 bytes of output per line would hang/stall. No output to the connected computer session. (ep1in-bulk no more output). Debugging logs with additional information (list_empty and ep->stopped added to message) reported on a free command - produced this for logs. [ 652.983793] gs_write: ttyGS0 (c0456000) writing 2 bytes [ 653.000699] ttyGS0: tx len=2, 0x0d 0x0a 0x73 ... [ 653.017493] udc: ep1in-bulk queue req c04768c0, len 2 buf c0476900 list_empty 1 ep->stopped 0 [ 653.038368] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04768c0 [ 653.056191] gs_flush_chars: (0,c0456000) [ 653.093561] gs_write_room: (0,c0456000) room=8191 [ 653.111007] gs_write: ttyGS0 (c0456000) writing 71 bytes Here is the first partial line coming over. [ 653.128571] ttyGS0: tx len=64, 0x20 0x20 0x20 ... [ 653.145391] udc: ep1in-bulk queue req c04768c0, len 64 buf c0476900 list_empty 1 ep->stopped 0 write fifo - good 64 bytes [ 653.166609] udc: wrote ep1in-bulk 64 bytes/L 0 left c04768c0 [ 653.184456] ttyGS0: tx len=7, 0x62 0x75 0x66 ... [ 653.201211] udc: ep1in-bulk queue req c04768c0, len 7 buf c0476900 list_empty 1 ep->stopped 1 Problem additional 7 chars and ep->stopped - pio_irq never gets enabled after it has been disabled. After this point no more data output (ep1in-bulk) is sent. [ 653.234600] gs_write_room: (0,c0456000) room=8191 [ 653.252453] gs_write: ttyGS0 (c0456000) writing 2 bytes [ 653.270258] ttyGS0: tx len=2, 0x0d 0x0a 0x47 ... [ 653.288050] udc: ep1in-bulk queue req c0476840, len 2 buf c0476880 list_empty 0 ep->stopped 0 [ 653.309317] gs_flush_chars: (0,c0456000) [ 653.333737] gs_write_room: (0,c0456000) room=8191 [ 653.351545] gs_write: ttyGS0 (c0456000) writing 71 bytes [ 653.369767] ttyGS0: tx len=64, 0x20 0x20 0x4d ... [ 653.387546] udc: ep1in-bulk queue req c04767c0, len 64 buf c0476800 list_empty 0 ep->stopped 0 [ 653.409704] ttyGS0: tx len=7, 0x20 0x20 0x20 ... [ 653.428329] udc: ep1in-bulk queue req c0476740, len 7 buf c0476780 list_empty 0 ep->stopped 0 [ 653.458930] gs_write_room: (0,c0456000) room=8191 [ 653.477806] gs_write: ttyGS0 (c0456000) writing 2 bytes [ 653.496439] ttyGS0: tx len=2, 0x0d 0x0a 0x47 ... [ 653.515178] udc: ep1in-bulk queue req c04766c0, len 2 buf c0476700 list_empty 0 ep->stopped 0 [ 653.538072] gs_flush_chars: (0,c0456000) [ 653.564064] gs_write_room: (0,c0456000) room=8191 [ 653.583293] gs_write: ttyGS0 (c0456000) writing 45 bytes [ 653.602765] ttyGS0: tx len=45, 0x20 0x53 0x77 ... [ 653.622085] udc: ep1in-bulk queue req c0476640, len 45 buf c0476680 list_empty 0 ep->stopped 0 .... Etc .... [ 653.982333] gs_write: ttyGS0 (c0456000) writing 2 bytes [ 654.001840] ttyGS0: tx len=2, 0x23 0x20 0x47 ... [ 654.021619] udc: ep1in-bulk queue req c0476940, len 2 buf c0476980 list_empty 0 ep->stopped 0 While I don't have it recorded the /sys/kernel/debug/pxa25x_udc would show queues in ep1in-bulk something like below - this isn't the actual from the above session. ep1in-bulk max 64 pio udccs 0b irqs 18 req c04758c0 len 0/7 buf c0475900 req c0475840 len 0/2 buf c0475880 req c04757c0 len 0/64 buf c0475800 req c0475740 len 0/7 buf c0475780 req c04756c0 len 0/2 buf c0475700 req c0475640 len 0/45 buf c0475680 req c04755c0 len 0/2 buf c0475600 req c0475540 len 0/45 buf c0475580 req c04754c0 len 0/2 buf c0475500 req c0475940 len 0/2 buf c0475980 In every case a manual enable of the pio_irq 0x40600050 would release the hang/stall and process the output and all is well again until next long line after queue is processed. Also while it was hung session still active - can do commands and still working (maybe until queues or memory used up) - just no output. # devmem2 0x40600050 w /dev/mem opened. Memory mapped at address 0x40006000. Value at address 0x40600050 (0x40006050): 0xFA # devmem2 0x40600050 w 0xF8 /dev/mem opened. Memory mapped at address 0x40006000. [ 1640.173457] udc: wrote ep1in-bulk 7 bytes/L/S 0 left c04768c0 Value at address 0x40600050 (0x40006050): 0xFA [ 1640.191668] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c0476840 [ 1640.208856] udc: wrote ep1in-bulk 64 bytes/L 0 left c04767c0 [ 1640.225778] udc: wrote ep1in-bulk 7 bytes/L/S 0 left c0476740 [ 1640.242338] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04766c0 [ 1640.258716] udc: wrote ep1in-bulk 45 bytes/L/S 0 left c0476640 [ 1640.274840] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04765c0 [ 1640.290379] udc: wrote ep1in-bulk 45 bytes/L/S 0 left c0476540 [ 1640.306121] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04764c0 [ 1640.320844] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c0476940 Written 0xF8; readback 0xF8 So right or wrong after experimenting and testing the below patch in pxa25x_udc.c in function pxa25x_ep_queue fixed my problems. Both g_serial and g_ether under a pxa255 and pxa250 platforms - perform flawlessly in my testing at the moment. So... If the experts could review and look to see what really should be done or maybe already resolved... Here is what I did. Thanks, Quintin. This is against a 2.6.34.1 kernel source. --- a/drivers/usb/gadget/pxa25x_udc.c 2010-07-05 13:24:10.000000000 -0500 +++ b/drivers/usb/gadget/pxa25x_udc.c 2010-09-12 16:06:34.000000000 -0500 @@ -753,7 +753,8 @@ pxa25x_ep_queue(struct usb_ep *_ep, stru if (likely (req && ep->desc)) pio_irq_enable(ep->bEndpointAddress); - } + } else if (!ep->stopped && req && ep->desc) + pio_irq_enable(ep->bEndpointAddress); /* pio or dma irq handler advances the queue. */ if (likely(req != NULL)) -- 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
