Felipe Balbi wrote: > On Thu, Sep 23, 2010 at 06:35:11AM -0500, Jon Povey wrote: >> loading musb_hdrc with debug=7 shows up some suspicious differences >> when receiving a 64-byte line, some console logs below. I note that >> bits 0x3 of csr are set in the problem case. > > that's RxPktRdy and FifoFull. Yup. But I don't know enough about this driver and hardware to know what that implies. > Can you check if you have the same with 512 byte transfers ?? Yes, it looks like it. 511 is ok, 512 locks up rx and gives the below on the console. 128 chars also locks things up. cppi_interrupt 1173: CPPI IRQ Tx0 Rx1 cppi_dump_rx 378: RX DMA0/K: 0 left, csr 2003, 00000000 H00000000 S86eb78a0 C86eb78a0, B879eea00 L02000000 00000200 .. 86eb78a0 cppi_rx_scan 1046: C/RXBD 86eb78a0: nxt 00000000 buf 879ee800 off.len 00000200 opt.len d0000200 (0) cppi_dump_rx 378: RX DMA0/completed: 0 left, csr 2003, 00000000 H00000000 S86eb78a0 C86eb78a0, B879eea00 L02000000 00000200 .. 86eb78a0 musb_g_rx 763: <== ep1out, rxcsr 2003 (dma) c6efdcc0 musb_g_rx 806: RXCSR1 0003, dma off, 0003, len 512, req c6efdcc0 musb_g_giveback 143: ep1out done request c6efdcc0, 512/512 gs_read_complete: req c6efdcc0 cppi_next_rx_segment 832: RX DMA0 seg, maxp 512 onepacket bds 1 (cnt 0) dma 0x879eec00 len 512 0/512 RXBD/S 86eb78c0: nxt 00000000 buf 879eec00 off.blen 00000200 opt.plen e0000200 cppi_dump_rx 378: RX DMA0/S: 3 left, csr 0003, 00000000 H86eb78c0 S86eb78a0 C86eb78a0, B879eea00 L02000000 00000200 .. 86eb78a0 davinci_interrupt 292: IRQ 00000000 ttyGS 512 bytes to tty (c C - ... 0x2e 0x0a) musb_gadget_queue 1148: <== to ep1out request=c6efdcc0 >> musb_ep_restart 1088: <== TX/IN request c6e927c0 len 1 on hw_ep1 >> txstate 298: hw_ep1, maxpacket 512, fifo count 1, txcsr 2404 > > what's this one byte you're sending back ? I snipped the rest but it seems the tty layer was echoing back each character, individually (!) stty -F /dev/ttyGS0 -echo stopped that. I don't remember it doing this echoing by default with 2.6.34.. >> Subsequent 63-byte RX (fails to arrive at tty) >> Not quite sure what's going on here, something very different: >> >> davinci_interrupt 292: IRQ 00000001 >> musb_interrupt 1583: ** IRQ peripheral usb0000 tx0001 rx0000 > > only ep0 IRQ ?!? weird. Oh, I think was ACM traffic from the Windows app reopening the serial port when it gets a TX timeout. I stopped it doing that, now after sending a line with killer length, any subsequent line times out and there are no more console messages from usb. >> Racelogic is a limited company registered in England. Registered >> number 2743719 . Registered Office Unit 10, Swan Business Centre, >> Osier Way, Buckingham, Bucks, MK18 1TB . >> >> The information contained in this electronic mail transmission is ... > > remove this sort of footer when sending mails to the mailing list!!! I'd love to, but it's not my decision, and part of it is a legal requirement: http://www.theregister.co.uk/2006/12/21/new_web_email_regulation/ Sorry. -- Jon Povey jon.povey@xxxxxxxxxxxxxxx Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- 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
