From mboxrd@z Thu Jan 1 00:00:00 1970 From: nsekhar@ti.com (Sekhar Nori) Date: Mon, 7 Aug 2017 10:20:11 +0530 Subject: Warning dump on OMAP-L138 when g_zero module is removed In-Reply-To: References: <748a9491-e834-34cb-993f-e8c7e2538961@ti.com> <260e5199-624d-b402-5481-2d818d282ce7@baylibre.com> <7c53882e-b70b-91dc-df2f-9f67fdd3cf40@baylibre.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Alexandre, On Sunday 06 August 2017 01:37 AM, Alexandre Bailon wrote: > Hi Sekhar, > On 07/21/2017 05:18 PM, Alexandre Bailon wrote: >> Hi Sekhar, >> >> On 07/10/2017 01:00 PM, Sekhar Nori wrote: >>> On Thursday 06 July 2017 10:43 PM, Alexandre Bailon wrote: >>>> On 06/29/2017 03:50 PM, Sekhar Nori wrote: >>>>> Hi Alexandre, Bin, >>>>> >>>>> With latest linux-next, I see a warning dump when I remove g_zero[1] on >>>>> OMAP-L138 LCDK board. I am building the kernel with davinci_all_defconfig. >>>>> >>>>> It is not present in latest mainline because the warnings are introduced >>>>> with CPPI DMA getting enabled in latest -next. >>>>> >>>>> Subsequent insertion of g_ether leads to a warning too[2], although the >>>>> gadget seems to work (ping test). >>>>> >>>>> Since these are pretty annoying, it will be nice to get rid of them. I >>>>> have not been able to debug any further. But if you have >>>>> ideas/experiments to try, I can do that. >>> >>>> I got a lot of these warnings during development but it was only for the >>>> host mode. >>>> If I remember correctly, the cause was a race between the teardown >>>> function and the interrupt handler. >>>> The teardwon descriptor was pop from the queue by the interrupt handler, >>>> preventing cppi41_tear_down_chan() to get it, which will result after >>>> some retries to a couple of warnings. >>>> >>>> I will take a look to see if that is the same issue. >> That is not the same issue. Still, for some reasons, we never get the >> teardown descriptor. >> Two possibilities: >> - Like the issue I had, the teardown is pop at the wrong place. >> - The teardown doesn't complete or the descriptor is not queued. > The teardown descriptor is not queued. I have figured out the reason. > The function cppi41_dma_channel_abort() enable the teardown by setting the bit corresponding to the endpoint number. > The address of the register is USB_TDOWN but actually the address is wrong in the case of DA8xx. > Using the right address (0x1c) fix the teardown warnings. > I will work on a fix. >> I think we should eliminate the first one before to work on the second one. >> I think adding some logs to cppi41_pop_desc() could help to figure out >> what is happening. >>> >>> Thanks! I also see similar warnings under fast ping traffic and g_ether >>> inserted on LCDK. They dont come immediately though. Only after an hour >>> or so under traffic. > The fix should also fix this issue. >> I would not have expected to have them during a ping but this probably >> happens because some USB packet have timed out, which cause may a teardown. >>> >>> I can those provide logs too if its going to be helpful. >> Currently, I think we should focus on the warnings that happens during >> the rmmod as they are always reproducible. >> >> Thanks, >> Alexandre >> > Note that the teardown is not the only thing that doesn't work correctly. > I think same kind of issue should apply to the autoreq and the dma mode. > I will work on a patch that should solve all of them. Glad you found the issue. When you have a patch, I will be happy to test it out. Thanks, Sekhar