On 2016-03-03, John Ogness <john.ogness@xxxxxxxxxxxxx> wrote: >>> Using next-20160302 I can very reliably hit this warning on an >>> AM335x BeagleBone by playing a short audio file over USB-Audio: >>> >>> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE /usr/share/sounds/alsa/Front_Center.wav >>> >>> $ aplay -l >>> **** List of PLAYBACK Hardware Devices **** >>> card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] >>> Subdevices: 1/1 >>> Subdevice #0: subdevice #0 >>> >>> The audio file is part of the alsa-utils package. The USB-Audio >>> device is never disconnected. Simply playing the file triggers the >>> warning. Any hints/suggestions how I should debug this? >> >> In general, it seems this tx fifo flush error has been there for >> years, it happens when tearing down an active endpoint in some >> unknown conditions. But I haven't seen a such case in which musb >> stops working. > > Actually, I am tracking down an issue where musb _does_ stop > working. With the above "aplay" example, I can reproduce a hang with the > musb on v3.19 and v4.0. Sometimes it takes up to an hour to reproduce > the hang, so I am slowly moving to newer kernels to see how far I can > reproduce the hang. There was a lot of great work done on musb between v4.0 and v4.1. This seems to have fixed the musb hang. With v4.1 I am not able to reproduce the problem. Great job! > I have not been able to reproduce a hang with next-20160302 (yet?), > but I do get your warning and the backtrace looks very similar to what > I see in the hang situation on the older kernel versions. Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite looping and kept a log of the number of loops that were executed. For my test I am regularly seeing 3000-3200 loops (with a max so far of 3289). Since there used to be an msleep() in the loop, I never hit the warnings before. With my board, 3200 loops takes about 950us. Perhaps the msleep() should be reinserted, but with a retry count of only 3 before aborting with the warning. John Ogness -- 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
