AM335X: musb-hdrc could not flush host TX2 fifo

Hi

I get the same error with the official TI release version of the kernel, although I am building with yocto and not using the sdk directly.

SRCREV = "3639bea54a4a1e1c572a1bde78facc4e37839c12"

git://git.ti.com/processor-sdk/processor-sdk-linux.git;protocol=git;branch=processor-sdk-linux-03.00.00 

root@beaglebone:~# aplay out3.wav
[ 39.136860] random: nonblocking pool is initialized
Playing WAVE 'out3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 39.287407] hrtimer: interrupt took 198333 ns
[ 55.951846] ------------[ cut here ]------------
[ 55.956624] WARNING: CPU: 0 PID: 314 at /home/andreas/src/Langedrag-Yocto/build/tmp/work-shared/beaglebone/kernel-source/drivers/usb/musb/musb_host.c:139 musb_h_tx_flush_fifo+0xdc/0xe8 [musb_hdrc]()
[ 55.974350] musb-hdrc musb-hdrc.1.auto: Could not flush host TX2 fifo: csr: 2403
[ 55.981777] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi pruss_intc musb_dsps musb_hdrc udc_core pm33xx pru_rproc wkup_m3_ipc ti_emif_sram wkup_m3_rproc pruss omap_aes_driver omap_sham remoteproc virtio virtio_ring omap_rng rng_core musb_am335x rtc_omap omap_wdt
[ 56.007544] CPU: 0 PID: 314 Comm: aplay Not tainted 4.4.12-g3639bea54a #1
[ 56.014363] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 56.020482] Backtrace:
[ 56.022978] [<c00133a4>] (dump_backtrace) from [<c00135a0>] (show_stack+0x18/0x1c)
[ 56.030580] r7:bf07e450 r6:0000008b r5:00000009 r4:00000000
[ 56.036309] [<c0013588>] (show_stack) from [<c0299110>] (dump_stack+0x24/0x28)
[ 56.043579] [<c02990ec>] (dump_stack) from [<c0032668>] (warn_slowpath_common+0x88/0xb4)
[ 56.051714] [<c00325e0>] (warn_slowpath_common) from [<c00326cc>] (warn_slowpath_fmt+0x38/0x40)
[ 56.060449] r8:dd9d447c r7:bf08854c r6:e09dac10 r5:bf088370 r4:bf0877d0
[ 56.067254] [<c0032698>] (warn_slowpath_fmt) from [<bf07e450>] (musb_h_tx_flush_fifo+0xdc/0xe8 [musb_hdrc])
[ 56.077036] r3:bf086d74 r2:bf0877d0
[ 56.080637] r4:00002403
[ 56.083239] [<bf07e374>] (musb_h_tx_flush_fifo [musb_hdrc]) from [<bf07f54c>] (musb_cleanup_urb+0xd0/0x14c [musb_hdrc])
[ 56.094068] r10:00000001 r9:bf08854c r8:e09dac10 r7:00000000 r6:ddd32300 r5:00000000
[ 56.101966] r4:dd9d447c
[ 56.104570] [<bf07f47c>] (musb_cleanup_urb [musb_hdrc]) from [<bf07fc8c>] (musb_urb_dequeue+0x150/0x158 [musb_hdrc])
[ 56.115136] r10:00000001 r9:dde31a80 r8:00000000 r7:00020200 r6:dd9d4010 r5:a00e0093
[ 56.123033] r4:ddd32300
[ 56.125619] [<bf07fb3c>] (musb_urb_dequeue [musb_hdrc]) from [<c0487bd4>] (unlink1+0x38/0x158)
[ 56.134266] r10:dca776c8 r9:00000008 r8:a00e0093 r7:ffffff98 r6:dde61600 r5:ddd32300
[ 56.142163] r4:ddd32300 r3:bf07fb3c
[ 56.145774] [<c0487b9c>] (unlink1) from [<c0489ea4>] (usb_hcd_unlink_urb+0xa0/0xc0)
[ 56.153462] r8:a00e0093 r7:ffffff98 r6:dde72400 r5:ddd32300 r4:00000000
[ 56.160236] [<c0489e04>] (usb_hcd_unlink_urb) from [<c048aa4c>] (usb_unlink_urb+0x34/0x50)
[ 56.168534] r9:00000008 r8:dde4b000 r7:dde4a2a0 r6:dde4b3f0 r5:dde4b3ec r4:00000003
[ 56.176532] [<c048aa18>] (usb_unlink_urb) from [<bf0d79ec>] (deactivate_urbs.part.0+0x90/0xa4 [snd_usb_audio])
[ 56.186688] [<bf0d795c>] (deactivate_urbs.part.0 [snd_usb_audio]) from [<bf0d7a60>] (deactivate_urbs+0x60/0x6c [snd_usb_audio])
[ 56.198215] r9:00000008 r8:ddd6a3b8 r7:00000001 r6:dde38600 r5:dde4a000 r4:00000000
[ 56.206137] [<bf0d7a00>] (deactivate_urbs [snd_usb_audio]) from [<bf0d8bcc>] (snd_usb_endpoint_stop+0x38/0x64 [snd_usb_audio])
[ 56.217685] [<bf0d8b94>] (snd_usb_endpoint_stop [snd_usb_audio]) from [<bf0e1e3c>] (stop_endpoints+0x78/0x90 [snd_usb_audio])
[ 56.229037] r5:00000000 r4:dc98a010
[ 56.232750] [<bf0e1dc4>] (stop_endpoints [snd_usb_audio]) from [<bf0e1fb8>] (snd_usb_substream_playback_trigger+0xac/0xc8 [snd_usb_audio])
[ 56.245236] r5:c09e9a98 r4:dc98a010
[ 56.248912] [<bf0e1f0c>] (snd_usb_substream_playback_trigger [snd_usb_audio]) from [<c05ad658>] (snd_pcm_do_stop+0x58/0x5c)
[ 56.260090] r5:c09e9a98 r4:dde38600
[ 56.263704] [<c05ad600>] (snd_pcm_do_stop) from [<c05ad51c>] (snd_pcm_action_single+0x40/0x88)
[ 56.272363] [<c05ad4dc>] (snd_pcm_action_single) from [<c05ae754>] (snd_pcm_action+0xe8/0xec)
[ 56.280922] r7:00000001 r6:c09e9a98 r5:dde386bc r4:dde38600
[ 56.286642] [<c05ae66c>] (snd_pcm_action) from [<c05ae984>] (snd_pcm_drop+0x70/0xcc)
[ 56.294417] r7:dc82c000 r6:dca776c0 r5:dde72c00 r4:dde38600
[ 56.300137] [<c05ae914>] (snd_pcm_drop) from [<c05aea60>] (snd_pcm_release_substream.part.12+0x14/0xb4)
[ 56.309569] r5:ddd6a000 r4:dde38600
[ 56.313182] [<c05aea4c>] (snd_pcm_release_substream.part.12) from [<c05aebb8>] (snd_pcm_release+0x90/0x9c)
[ 56.322877] r5:ddd6a000 r4:dde38600
[ 56.326498] [<c05aeb28>] (snd_pcm_release) from [<c00fdf7c>] (__fput+0x88/0x204)
[ 56.333924] r9:00000008 r8:00000000 r7:dddc2c38 r6:ddcedf10 r5:dd0fde58 r4:dca776c0
[ 56.341745] [<c00fdef4>] (__fput) from [<c00fe150>] (____fput+0x10/0x14)
[ 56.348473] r10:00000000 r9:ddd98000 r8:c000fac4 r7:00000000 r6:c09f6234 r5:dca9b600
[ 56.356371] r4:dca9b904
[ 56.358933] [<c00fe140>] (____fput) from [<c004be50>] (task_work_run+0x78/0xa8)
[ 56.366285] [<c004bdd8>] (task_work_run) from [<c0013008>] (do_work_pending+0xbc/0xc0)
[ 56.374234] r7:00000006 r6:ddd99fb0 r5:c000fac4 r4:ddd98010
[ 56.379954] [<c0012f4c>] (do_work_pending) from [<c000f954>] (slow_work_pending+0xc/0x20)
[ 56.388165] r7:00000006 r6:00000000 r5:0004e514 r4:0004e408
[ 56.393875] ---[ end trace 4c645b43946d27be ]---

Andreas,

Can you please confirm if this only happens when finishing the audio playback and aplay is terminating? and when you repeat the same aplay command again usb-audio still works?

There is a known issue that the tx flush fifo error could happen when tearing down usb audio channel, but it does not break any usb function.

Hello Bin Liu,

The crash indeed happens when aplay is finnishing. When I repeat the same aplay, it doesn't work. I can not use USB audio again, not even if I disconnect/connect the USB soundcard. 

I can also mention that if I use the debian that is pre-installed on the beaglebone, which uses kernel 3.8.13-bone70, I can not reproduce the error.

Hello Dwarakesh

I checked and the patch 7.3b is already applied. It was applied in commit 68fe05e2a45181ce02ab2698930b37f20487bd24 (git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git) .

Andreas,

Please let me know if the following patch fix the issue for you.

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b7646fd..b5dbb3b 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2410,8 +2410,11 @@ static int musb_cleanup_urb(struct urb *urb, struct musb_qh *qh)
                 * clearing that status is platform-specific...
                 */
        } else if (ep->epnum) {
-               musb_h_tx_flush_fifo(ep);
                csr = musb_readw(epio, MUSB_TXCSR);
+               if (csr & MUSB_TXCSR_FIFONOTEMPTY) {
+                       udelay(750);
+                       musb_h_tx_flush_fifo(ep);
+               }
                csr &= ~(MUSB_TXCSR_AUTOSET
                        | MUSB_TXCSR_DMAENAB
                        | MUSB_TXCSR_H_RXSTALL

Hello,

It seems that the problem still exist with the patch included. 

I did some more tests with the device-tree.

- If I start with a pre-built image from the office SDK everything works fine, no crash.

- If I add the following line to the am335x-boneblack.dts 

&tda19988 {
status = "disabled";
}; 

I do get the crash. when playing a sound file with aplay. One thing I noted was that there is an indication on the USB sound card that indicates the sampling frequency and in the case where I get the crash, it actually indicates the wrong sampling frequency. The TDS19988 is a hdmi transmitter so I don't understand how that can affect the USB sound card? 

Andreas,

This kernel dump is a known issue which could happen sometimes while tearing down an USB TX endpoint which is actively transmitting USB packets, but we haven't found any functional impact.

Andreas Hansson64 said:

When I play a wav-file, the kernel crashes after a few seconds with the message: musb-hdrc musb-hdrc.1.auto: Could not flush host TX2 fifo:

Does this happen in the middle of the audio playback or it is to the end of the wav file? The wav file is more than a few seconds long?

After the kernel dump happens, can you hear the audio if replay the wav file?

user4846909 said:

I use a ar9271 usb wireless module in my board. If the connection of AP was dropped and do reconnect when there was data transmit on the module, sometimes i got kernel message below, and the usb moudle can not work unless i reboot the system.

Instead of reboot the system, can you reconnect the wifi after unplug and plug back the ar9271 module?

The ar9271 module is embedded in my device, it's inconvenient to do unplug and plug operation. But there is a reset pin on the module. When the warning message occured, i reset the module, and can observe unplug and plug information of ar9271 in dmesg output, but the module still can not work.

I've found something new of this problem. When i use old kernel 3.8.13, the ar9271 worked normally. So i use code bellow in 4.4.12 and do the test. The device worked fine now,  it seems that the prolem was fixed. I think the mdelay(1) have take effect.

==========
/*
* Clear TX fifo. Needed to avoid BABBLE errors.
*/
static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
{
struct musb *musb = ep->musb;
void __iomem *epio = ep->regs;
u16 csr;
u16 lastcsr = 0;
int retries = 1000;

csr = musb_readw(epio, MUSB_TXCSR);
while (csr & MUSB_TXCSR_FIFONOTEMPTY) {
if (csr != lastcsr)
dev_dbg(musb->controller, "Host TX FIFONOTEMPTY csr: %02x\n", csr);
lastcsr = csr;
csr |= MUSB_TXCSR_FLUSHFIFO | MUSB_TXCSR_TXPKTRDY;
musb_writew(epio, MUSB_TXCSR, csr);
csr = musb_readw(epio, MUSB_TXCSR);
if (WARN(retries-- < 1,
"Could not flush host TX%d fifo: csr: %04x\n",
ep->epnum, csr))
return;
mdelay(1);
}
}

Bin Liu said:

Does this happen in the middle of the audio playback or it is to the end of the wav file? The wav file is more than a few seconds long?

After the kernel dump happens, can you hear the audio if replay the wav file?

Hi Bin Liu

This happens at the end of the playback, the complete file is always played until finished. 

If I replay the wav file, sometimes it works and sometimes it doesn't.

If I replay the same file over and over again, eventuelly I will always end in a situation where I can no longer play a file.

BR
Andreas

Andreas,

Is it possible to test with any relatively new kernel from kernel.org? for example v4.4, v4.9 or v4.11?

I recently got an issue report that it seems the community v4.4 kernel doesn't have such issue, but TI Processor SDK v4.4 kernel does. I haven't got a chance to investigate this yet.

I'd like to know if the issue you have is the same, if you could try a kernel from kernel.org.

user4846909,

Can you please test the patches attached below? It basically the same - adding the 1ms delay back, but with another patch together to solve a separate issue.

musb-fifo-flush-fixes.tar.gz