All of lore.kernel.org
 help / color / mirror / Atom feed
From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: Warning dump on OMAP-L138 when g_zero module is removed
Date: Mon, 7 Aug 2017 10:20:11 +0530	[thread overview]
Message-ID: <c40f167d-c70d-7582-9e27-5236b052ecca@ti.com> (raw)
In-Reply-To: <f97d12c0-3aaa-b666-292d-cad9c3af54df@baylibre.com>

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

      reply	other threads:[~2017-08-07  4:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 13:50 Warning dump on OMAP-L138 when g_zero module is removed Sekhar Nori
2017-07-06 17:13 ` Alexandre Bailon
2017-07-10 11:00   ` Sekhar Nori
2017-07-21 15:18     ` Alexandre Bailon
2017-08-05 20:07       ` Alexandre Bailon
2017-08-07  4:50         ` Sekhar Nori [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c40f167d-c70d-7582-9e27-5236b052ecca@ti.com \
    --to=nsekhar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.