musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
On DM355 with CPPI DMA enabled, operating as gadget serial, the USB driver RX side locks up when sent a 64-byte line of text. Up to and above 64 bytes are OK, exactly 64 bytes wedges it. I see the 64-byte line come out of "cat /dev/ttyGS0", but then nothing after. The TX side still works OK, but if the other end tries to send any more, it times out. If it helps at all, a few times when testing this I have seen extra 1-byte transfers appear at the g_serial layer rather than wedging when a 64-byte packet was sent. I haven't been able to reproduce this reliably. But that is to say I was seeing: Send 64 bytes, g_serial layer gets 64-byte transfer followed by a 1-byte transfer containing garbage: always the first character of some previous line received. Send any other line size e.g. 63 bytes, g_serial layer gets a single 63-byte transfer. Disabling DMA fixes the problem, but I'd like to have DMA if possible, and help fix this. I observed this problem in a 2.6.34 based kernel, I am now running the master of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git with local board support etc. patches applied, and tried applying the 12 musb fix patches at the top of http://gitorious.org/usb/usb/commits/musb which did not help. 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. 63-byte RX (ok): cppi_interrupt 1172: CPPI IRQ Tx0 Rx1 cppi_dump_rx 377: RX DMA0/K: 0 left, csr 2000, H S873388c0 C873388c0, B86ec6c3f L003f01c1 003f .. 873388c0 cppi_rx_scan 1045: C/RXBD 873388c0: nxt buf 86ec6c00 off.len 003f opt.len d03f (0) cppi_dump_rx 377: RX DMA0/completed: 0 left, csr 2000, H S873388c0 C873388c0, B86ec6c3f L003f01c1 003f .. 873388c0 musb_g_rx 757: <== ep1out, rxcsr 2000 (dma) c6e92dc0 musb_g_rx 800: RXCSR1 , dma off, , len 63, req c6e92dc0 musb_g_giveback 143: ep1out done request c6e92dc0, 63/512 gs_read_complete: req c6e92dc0 cppi_next_rx_segment 831: RX DMA0 seg, maxp 512 onepacket bds 1 (cnt 0) dma 0x86854000 len 512 0/512 RXBD/S 873388a0: nxt buf 86854000 off.blen 0200 opt.plen e200 cppi_dump_rx 377: RX DMA0/S: 3 left, csr , H873388a0 S873388c0 C873388c0, B86ec6c3f L003f01c1 003f .. 873388c0 davinci_interrupt 292: IRQ ttyGS 63 bytes to tty (s S . ... 0x39 0x0a) musb_gadget_queue 1120: <== to ep1out request=c6e92dc0 musb_gadget_queue 1120: <== to ep1in request=c6e927c0 musb_ep_restart 1088: <== TX/IN request c6e927c0 len 1 on hw_ep1 txstate 298: hw_ep1, maxpacket 512, fifo count 1, txcsr 2404 cppi_next_tx_segment 604: TX DMA0, pktSz 512 transparent bds 1 dma 0x86854a00 len 1 cppi_next_tx_segment 658: TXBD ff32a800: nxt buf 86854a00 len 0001 opt e001 cppi_dump_tx 405: TX DMA0/S: csr 3403, H S86e71800 C86e71800 86854a01, F0002 L0001 .. 86e71800 txstate 410: ep1in TX/IN dma len 0/1, txcsr 3404, fifo 1/512 cppi_interrupt 1172: CPPI IRQ Tx1 Rx0 cppi_dump_tx 405: TX DMA0/E: csr 3404, H S86e71800 C86e71800 86854a01, F0002 L0001 .. 86e71800 cppi_interrupt 1217: C/TXBD ff32a800 n 0 b 86854a00 off 1 opt d000 musb_g_tx 430: <== ep1in, txcsr 3404 musb_g_tx 475: TXCSR1 2400, DMA off, len 1, req c6e927c0 musb_g_giveback 143: ep1in done request c6e927c0, 1/1 musb_g_tx 522: ep1in idle now 64-byte RX (wedges things, but gets to tty): cppi_interrupt 1172: CPPI IRQ Tx0 Rx1 cppi_dump_rx 377: RX DMA0/K: 0 left, csr 2003, H S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 cppi_rx_scan 1045: C/RXBD 873388a0: nxt buf 86854000 off.len 0040 opt.len d040 (0) cppi_dump_rx 377: RX DMA0/completed: 0 left, csr 2003, H S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 musb_g_rx 757: <== ep1out, rxcsr 2003 (dma) c6e92d00 musb_g_rx 800: RXCSR1 0003, dma off, 0003, len 64, req c6e92d00 musb_g_giveback 143: ep1out done request c6e92d00, 64/512 gs_read_complete: req c6e92d00 cppi_next_rx_segment 831: RX DMA0 seg, maxp 512 onepacket bds 1 (cnt 0) dma 0x86854200 len 512 0/512 RXBD/S 873388c0: nxt buf 86854200 off.blen 0200 opt.plen e200 cppi_dump_rx 377: RX DMA0/S: 3 left, csr 0003, H873388c0 S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 davinci_interrupt 292: IRQ ttyGS 64 bytes to tty (t T . ... 0x30 0x0a) musb_gadget_queue 1120: <== to ep1out request=c6e92d00 musb_gadget_queue 1120: <== to ep1in request=c6e927c0 musb_ep_restart 1088: <== TX/IN request c6e927c0 len 1 on hw_ep1 txstate 298: hw_ep1, maxpacket 512, fifo count 1, txcsr 2404 cppi_next_tx_segment 604: TX DMA0, pktSz 512 transparent bds 1 dma 0x86854a00 len 1 cppi_next_tx_segment 658: TXBD ff32a800: nxt buf 86854a00 len 0001 opt e001 cppi_dump_tx 405: TX DMA0/S: csr 3403, H S86e71800 C86e71800 86854a01, F0002 L000
Re: musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
Hi, 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. 64-byte RX (wedges things, but gets to tty): cppi_interrupt 1172: CPPI IRQ Tx0 Rx1 cppi_dump_rx 377: RX DMA0/K: 0 left, csr 2003, H S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 Can you check if you have the same with 512 byte transfers ?? cppi_rx_scan 1045: C/RXBD 873388a0: nxt buf 86854000 off.len 0040 opt.len d040 (0) cppi_dump_rx 377: RX DMA0/completed: 0 left, csr 2003, H S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 musb_g_rx 757: <== ep1out, rxcsr 2003 (dma) c6e92d00 musb_g_rx 800: RXCSR1 0003, dma off, 0003, len 64, req c6e92d00 musb_g_giveback 143: ep1out done request c6e92d00, 64/512 gs_read_complete: req c6e92d00 cppi_next_rx_segment 831: RX DMA0 seg, maxp 512 onepacket bds 1 (cnt 0) dma 0x86854200 len 512 0/512 RXBD/S 873388c0: nxt buf 86854200 off.blen 0200 opt.plen e200 cppi_dump_rx 377: RX DMA0/S: 3 left, csr 0003, H873388c0 S873388a0 C873388a0, B86854040 L004001c0 0040 .. 873388a0 davinci_interrupt 292: IRQ ttyGS 64 bytes to tty (t T . ... 0x30 0x0a) musb_gadget_queue 1120: <== to ep1out request=c6e92d00 musb_gadget_queue 1120: <== to ep1in request=c6e927c0 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 ? cppi_next_tx_segment 604: TX DMA0, pktSz 512 transparent bds 1 dma 0x86854a00 len 1 cppi_next_tx_segment 658: TXBD ff32a800: nxt buf 86854a00 len 0001 opt e001 cppi_dump_tx 405: TX DMA0/S: csr 3403, H S86e71800 C86e71800 86854a01, F0002 L0001 .. 86e71800 txstate 410: ep1in TX/IN dma len 0/1, txcsr 3404, fifo 1/512 cppi_interrupt 1172: CPPI IRQ Tx1 Rx0 cppi_dump_tx 405: TX DMA0/E: csr 3404, H S86e71800 C86e71800 86854a01, F0002 L0001 .. 86e71800 cppi_interrupt 1217: C/TXBD ff32a800 n 0 b 86854a00 off 1 opt d000 musb_g_tx 430: <== ep1in, txcsr 3404 musb_g_tx 475: TXCSR1 2400, DMA off, len 1, req c6e927c0 musb_g_giveback 143: ep1in done request c6e927c0, 1/1 musb_g_tx 522: ep1in idle now Subsequent 63-byte RX (fails to arrive at tty) Not quite sure what's going on here, something very different: davinci_interrupt 292: IRQ 0001 musb_interrupt 1583: ** IRQ peripheral usb tx0001 rx only ep0 IRQ ?!? weird. 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 remove this sort of footer when sending mails to the mailing list!!! -- balbi ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
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, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 cppi_rx_scan 1046: C/RXBD 86eb78a0: nxt buf 879ee800 off.len 0200 opt.len d200 (0) cppi_dump_rx 378: RX DMA0/completed: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 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 buf 879eec00 off.blen 0200 opt.plen e200 cppi_dump_rx 378: RX DMA0/S: 3 left, csr 0003, H86eb78c0 S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 davinci_interrupt 292: IRQ 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 0001 >> musb_interrupt 1583: ** IRQ peripheral usb tx0001 rx > > 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.po...@racelogic.co.uk 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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
Hi, On Fri, Sep 24, 2010 at 02:39:03AM -0500, Jon Povey wrote: Yup. But I don't know enough about this driver and hardware to know what that implies. it means you have a packet pending on the FIFO and the fifo is now full :-p cppi_interrupt 1173: CPPI IRQ Tx0 Rx1 cppi_dump_rx 378: RX DMA0/K: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 cppi_rx_scan 1046: C/RXBD 86eb78a0: nxt buf 879ee800 off.len 0200 opt.len d200 (0) cppi_dump_rx 378: RX DMA0/completed: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 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 buf 879eec00 off.blen 0200 opt.plen e200 cppi_dump_rx 378: RX DMA0/S: 3 left, csr 0003, H86eb78c0 S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 davinci_interrupt 292: IRQ ttyGS 512 bytes to tty (c C - ... 0x2e 0x0a) musb_gadget_queue 1148: <== to ep1out request=c6efdcc0 Sergei, do you see anything fishy wrt CPPI dma ?? -- balbi ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
Hello. Felipe Balbi wrote: cppi_interrupt 1173: CPPI IRQ Tx0 Rx1 cppi_dump_rx 378: RX DMA0/K: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 cppi_rx_scan 1046: C/RXBD 86eb78a0: nxt buf 879ee800 off.len 0200 opt.len d200 (0) cppi_dump_rx 378: RX DMA0/completed: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 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 buf 879eec00 off.blen 0200 opt.plen e200 cppi_dump_rx 378: RX DMA0/S: 3 left, csr 0003, H86eb78c0 S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 davinci_interrupt 292: IRQ ttyGS 512 bytes to tty (c C - ... 0x2e 0x0a) musb_gadget_queue 1148: <== to ep1out request=c6efdcc0 Sergei, do you see anything fishy wrt CPPI dma ?? Unfortunately, I'm not an expert in CPPI 3.0 DMA code... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
