• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 697 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM335X: USB Driver dominating CPU time

Tim Potter
Intellectual 726 points
Part Number: PROCESSOR-SDK-AM335X

Tool/software: Linux

Our boards make use of the AM335x chip.  We have a USB device port on our boards that we use for data transfer between the board and a Windows Laptop.  We use the g_ether and rndis drivers in Linux to support IP across this connection.

When we do an SFTP transfer from Windows to the board we see that the USB driver is using a disproportionately large amount of the CPU time.  This results in other processes on the board getting deprived for time.

The question I have is, is there a way to have the usb drivers share more of the CPU time than they are? 

  • 0
    TI__Guru**** 167501 points
    Tim,

    We first need to understand what the problem is.
    What Processor SDK version do you use?
    What is the CPU load in percentage when it is high?
    Do you see the same problem if use Linux host instead of Windows?
  • 0 in reply to Bin Liu
    Intellectual 726 points
    We are using SDK 7.0. We have not tried with a Linux machine using SFTP to the board. We are only supporting Windows machines connecting to the board so we did not try this.

    This is partial output of perf. 88.19% of the time we are in the kernel.

    Samples: 22K of event 'cpu-clock', Event count (approx.): 1299282704
    - 88.19% [kernel.kallsyms]
    - usbnet_start_xmit
    - 99.36% dev_hard_start_xmit
    - sch_direct_xmit
    - 59.28% __qdisc_run
    - 99.92% net_tx_action
    __do_softirq
    + do_softirq
    + 40.72% dev_queue_xmit
    + 0.64% sch_direct_xmit
    + __do_softirq
    + do_softirq
    + irq_exit
  • 0 in reply to Tim Potter
    TI__Guru**** 167501 points

    Tim,

    SDK7.0 is too old and no longer supported by TI. Please test with the latest Processor SDK.

    If you cannot migrate to the latest SDK kernel, please ensure you have all the patches applied which are listed in the section AMSDK 07.00.00.00 and 08.00.00.00 in page .

    If the issue still exists with the patches, please try to disable the CPPI DMA with the following patch.

    diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 1ec0a4947b6b..def4dc3f18c6 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -560,7 +560,10 @@ static int cppi41_is_compatible(struct dma_channel *channel, u16 maxpacket,
        if (is_host_active(musb)) {
                WARN_ON(1);
                return 1;
+       } else {
+               return 0;
        }
+
        if (cppi41_channel->hw_ep->ep_in.type != USB_ENDPOINT_XFER_BULK)
                return 0;
        if (cppi41_channel->is_tx)
  • 0 in reply to Bin Liu
    TI__Guru*** 125430 points
    One other thought that comes to mind is if this potentially relates to the cryptographic operations (e.g. AES256, etc.) involved with SFTP. Can you check "lsmod" to see if the cryptodev module is present?
  • 0 in reply to Bin Liu
    Intellectual 726 points

    Thanks,

    Yeah I know we are at an older version ( Brad is pushing us to get to a newer one ).  We have applied all the patches in the link you provided.  I will try disabling the CPPI DMA and see how that does.  Thanks.

  • 0 in reply to Brad Griffis
    Intellectual 726 points
    Hi Brad,

    the cryptodev module is not loaded ( running normally ). We are dynamically launching sshd and sftp so I will try and see if it gets loaded when we load those.
  • 0 in reply to Tim Potter
    TI__Guru**** 167501 points
    Hi Tim,

    Have you tested with CPPI DMA disabled? What is the result?
  • 0 in reply to Bin Liu
    Intellectual 726 points
    I'm sorry, I thought I had replied to this.

    Yes, I tested with the CPPI DMA disabled and we saw a significant improvement. We are doing additional testing to be sure we have not impacted other performance due to this, but it did address the issue I originally posted. Thanks!
  • 0 in reply to Tim Potter
    TI__Guru**** 167501 points
    Tim,

    Thanks for the update, I am glad this workaround the issue.

    Just want you know that there is a kernel config option to disable CPPI DMA, you can use it instead of the patch above in your project. Please let me know if you cannot locate the config option.

    I gave the patch first only because we can continue adding kernel patches to debug the problem if disabling CPPI DMA doesn't affect the issue.